Live data from Hacker News

Python past, present, and future with Guido van Rossum [audio]

talkpython.fm

121–130 of 151 posts

Re: Python past, present, and future with Guido van Rossum [audio]

#121

I've made a living of Python since 2.4 and hitting the 3.6, here is my take on it: The Python team does an incredible job at making the language evolve. This is a 20+ years old language, with billions of lines written in the world, and allowing a huge number of paradigms. It still matures, steals ideas, makes hard compromise on growth vs compat, etc. I know very few other techs that can even compare to this level of…

> The problem is, there are very few tutorials showing you the current best practices.

As someone looking to expand from simple Python scripts to serious Python projects, this is my primary issue. Do you have any recommendations?

Re: Python past, present, and future with Guido van Rossum [audio]

#122
post #112
post #96

Earlier quoted context omitted.

In the UK, algebra is first introduced using the equality operator, often with pictures of weight scales and weights, which students are asked to balance. Then they are introduced to a concise notation for this, e.g.: 1 + x = 3 Simplification comes later; and it often involves moving terms from one side of the relation to the other, which isn't possible with an assignment operator. I have no doubt that beginners soon…

"but why reuse the operator in the first place? Is it really making it "easier" for the beginner" That's a different question than "Has it confused a whole lot of high school students?" "The misuse of the equality operator is only one minor detail, but if people care so little about such details, how can they be trusted to look after the more important ones?" Assuming by "more important ones" you mean more important…

You sound very defeatist. There is world of difference between how much useful mathematics there is in Haskell compared to Python.

Re: Python past, present, and future with Guido van Rossum [audio]

#123
post #105

Earlier quoted context omitted.

You type in 'sudo apt-get install build-essentials' and you have it. I don't what the process on Windows these days but you used to have to find visual studio install media, install it, and reboot two or three times.

I don't what the process on Windows these days 1) Go to visualstudio.com 2) click Downloads if you want the full IDE: 3) choose between downloading free version of a trial of the professional version if you just want the command line tools 3) scroll down until you find C++ Build Tools and download that 4) double click the file you just downloaded. 5) Done

Yeah, visual studio now installs decently.

Uninstall or upgrade is still a nightmare, but installing it on a PC which has never had it isn't bad.

Re: Python past, present, and future with Guido van Rossum [audio]

#124

I've made a living of Python since 2.4 and hitting the 3.6, here is my take on it: The Python team does an incredible job at making the language evolve. This is a 20+ years old language, with billions of lines written in the world, and allowing a huge number of paradigms. It still matures, steals ideas, makes hard compromise on growth vs compat, etc. I know very few other techs that can even compare to this level of…

> The problem is, there are very few tutorials showing you the current best practices. As someone looking to expand from simple Python scripts to serious Python projects, this is my primary issue. Do you have any recommendations?

I like to brag and say the best blog I know about Python is mine. But it's in french so you will have to take my word for it. Yet it has more than 300 articles about Python and covering at length stuff from decorators to metaclass and even a fat 8 parts manual on OOP. Maybe google translate can help.

Re: Python past, present, and future with Guido van Rossum [audio]

#125
post #115
post #78

Earlier quoted context omitted.

Having used Scala I can't stand to go back to Python. Almost as lightweight (more lightweight in some places - case classes and "_ lambdas" are things I really missed in Python, though attrs maybe solves the first), but a whole lot safer, which makes it much easier to refactor, which makes it possible to maintain a much higher quality standard in a long-lived codebase. And the whole library/build ecosystem works a lo…

I've been programming python 15 or so years, and packaging seems very much a solved problem to me. I'm sorry its difficult for others, I just can't see the problem myself. I guess I understand them all at this point, and it all seems easy... pytest and tox is a dream. It's so quick, I can modify some code and switch to my test window, and I already have the results... It is not unrealistic to author several thousands…

Scala gets great, SBT stays awful. Avoid it if you can.

Once you get used to working with the type system you'll need tests a lot less - the cycle becomes edit/save/look at IDE "problems" tab, and that catches the overwhelming majority of issues, so you only resort to running the tests every couple of hours. It takes a while to make the transition though.

Re: Python past, present, and future with Guido van Rossum [audio]

#126
post #104

Earlier quoted context omitted.

Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited: every project uses the same source directory layout, every project uses the same release tag format, every project uses the same unit test layout, and so you can immediately jump into any project and be productive. When you want to run random code in your build p…

>Seriously. For anything more than a single developer maven is the best build system I've ever used by a long way, because its customizability is so limited That, along with its horrible XML markup abortion, was exactly what I hated about it. Any behavior that was even moderately unusual was a monumental pain to implement. Build scripts by their very nature need to be turing complete because the need for customizatio…

> Build scripts by their very nature need to be turing complete.

They really don't. The build process should be simple and the same for every project; any actual logic can go in first-class code, that's what it's for (whereas finding out that a file somehow wasn't built, or got substituted before being built, makes for an extremely unpleasant surprise when investigating an issue). I find Turing-complete build systems end up with an analogue of https://martinfowler.com/bliki/SnowflakeServer.html - the "snowflake build", where every module builds slightly differently.

Re: Python past, present, and future with Guido van Rossum [audio]

#127
post #62

Earlier quoted context omitted.

Try PyCharm if you need that kind of support. I'm usually happy with just pyflakes and linters.

Pycharm tries really hard to paper over the lack of static typing in Python. Variable/function refactoring works mostly, code completion is acceptable (especially if you're inside a specially supported-framework like Django) and sometimes it'll show up a type error before your tests fail, saving you the time it takes up setup the test db, run the tests etc... I love Pycharm, and I think people who go without IDE supp…

Typing is now available in recent versions of the language.

Re: Python past, present, and future with Guido van Rossum [audio]

#128

Earlier quoted context omitted.

> The problem is, there are very few tutorials showing you the current best practices. As someone looking to expand from simple Python scripts to serious Python projects, this is my primary issue. Do you have any recommendations?

I like to brag and say the best blog I know about Python is mine. But it's in french so you will have to take my word for it. Yet it has more than 300 articles about Python and covering at length stuff from decorators to metaclass and even a fat 8 parts manual on OOP. Maybe google translate can help.

linky?

Re: Python past, present, and future with Guido van Rossum [audio]

#129
post #78

Earlier quoted context omitted.

Having used Scala I can't stand to go back to Python. Almost as lightweight (more lightweight in some places - case classes and "_ lambdas" are things I really missed in Python, though attrs maybe solves the first), but a whole lot safer, which makes it much easier to refactor, which makes it possible to maintain a much higher quality standard in a long-lived codebase. And the whole library/build ecosystem works a lo…

I used Scala for a few years. I actually prefer python to it though. My reasons are: 1) Compile time. In a tight dev loop, you can run Unit tests in say 2 seconds in Python, vs 15, 30, 60, 90 seconds in Scala (depending on code base size) 2) Django. Play is ok, but for web stuff I think Django does a little better job. 3) Ease to find help. Finding someone to write scala is hard. Usually means hire a Java or a Haskel…

> 1) Compile time. In a tight dev loop, you can run Unit tests in say 2 seconds in Python, vs 15, 30, 60, 90 seconds in Scala (depending on code base size)

True, but 95%+ of the issues you'd catch with unit testing in Python you catch during compilation in Scala, and that can be an incremental compile rather than a full compile. So once you have a properly set up dev environment the feedback loop takes less than 2 seconds in practice, though the one-off setup to reach that point is a lot fiddlier than for Python.

> 2) Django. Play is ok, but for web stuff I think Django does a little better job.

Heh, I don't like either, I'm a huge fan of Wicket (the one time I had to use Django I wrapped it in a Wicket-like layer I called smoff, which I think might even still be out there). Django is too page/request-oriented for my liking, I think a component-oriented library leads to much better design when you're making actual UIs. For REST endpoints spray is the best thing I've ever used, in any language: having your route definition look more-or-less like a route definition but being regular code that you can refactor in all the regular ways is amazing, especially when you get to the point of wanting to use e.g. custom directives and you can just click through to the standard directives and they're just ordinary code that you can adapt the same way as any other code.

> 4) Easier to metaprogram. Sometimes, metaprogramming is awesome. Don't do it nonstop, but sometimes it is amazing. Reflection and macros and all of that exists, but it gets seriously awful to deal with.

I think if you can't do it with Shapeless it's probably not worth doing. The typeclass-derivation stuff is more boilerplate than it should be, but it does work well apart from that, and always leaves you with something more-or-less understandable. Whereas some of the Python metaclass tricks I've seen have just been completely crazy.

> 5) Code readability. I read scala fine, but it can still take a while to parse a file to know what is going on. Trying to think through crazy scalaz or something can hurt your head, even if you get it.

I think you have to remember to compare code that does the same amount, not code that's the same length. Like, sometimes there will be a 1-liner in Scala that I'll have to mentally expand out to 6 lines to understand - but in Python the same code would have been 6 lines in the first place. And I think there's a huge benefit to being able to see a whole class definition on a single page, so I'd rather have the "compressed" single-line version even if it takes slightly longer to read in isolation than the "expanded" six-line version.

> 6) No SBT

Agreed. Can't stand it, have no idea why it's popular. I just use maven.

Re: Python past, present, and future with Guido van Rossum [audio]

#130
post #129

Earlier quoted context omitted.

I used Scala for a few years. I actually prefer python to it though. My reasons are: 1) Compile time. In a tight dev loop, you can run Unit tests in say 2 seconds in Python, vs 15, 30, 60, 90 seconds in Scala (depending on code base size) 2) Django. Play is ok, but for web stuff I think Django does a little better job. 3) Ease to find help. Finding someone to write scala is hard. Usually means hire a Java or a Haskel…

> 1) Compile time. In a tight dev loop, you can run Unit tests in say 2 seconds in Python, vs 15, 30, 60, 90 seconds in Scala (depending on code base size) True, but 95%+ of the issues you'd catch with unit testing in Python you catch during compilation in Scala, and that can be an incremental compile rather than a full compile. So once you have a properly set up dev environment the feedback loop takes less than 2 se…

> True, but 95%+ of the issues you'd catch with unit testing in Python you catch during compilation in Scala, and that can be an incremental compile rather than a full compile. So once you have a properly set up dev environment the feedback loop takes less than 2 seconds in practice, though the one-off setup to reach that point is a lot fiddlier than for Python.

Not sure I agree with either of those. Compiler catches different types of error compared to Unit tests. Lots of ways especially when dealing with external libs or APIs where compile can't catch anything.

> Django wicket etc

To each their own. I despise SPAs, and neither code them nor use them if I can help it. DRF is really good for rest endpoints though.

> Meta programming

meh, different levels of it. Look at using Django ORM for some queries, vs say Slick. Slick is a bit gross.

> 1 liner vs 6 liner

Meh. In practice, Python is very terse also. Java vs Scala is a big line of code difference. I have not found Scala vs Python is that different.

Post reply on HN