Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boring Python: Code quality

b-list.org

Post reply on HN
Print view View original

91–100 of 232 posts

Re: Boring Python: Code quality

#91

Post by Flex247A »

modeopfer wrote: post #74

What's the current state of the art of managing multiple virtual environments, running tests and running your application? On Ubuntu and Windows I use Poetry [0], and it works, although it has (had?) some quirks during the installation on Windows. I liked its portability and lockfile format though. A few years ago I used conda [1], which was nice because it came batteries included especially for Deep Learning stuff.…

If you feel that Anaconda is too heavy, try Miniconda [0]. The base environment is a standard Python 3.9 environment without any additional packages.

[0] https://docs.conda.io/en/latest/miniconda.html

Re: Boring Python: Code quality

#92

Post by drcongo »

gjulianm wrote: post #81
drcongo wrote: post #34

Earlier quoted context omitted.

> it doesn't work with tabs What do you mean by this? Are you indenting Python with tabs?

Yes. The code started as being indented by tabs, so changing it now is a mess. Also, not to start a flamewar, but I've always preferred tabs to spaces in any language, I find them more reliable, easier to use...

Not going to argue about your personal preference, but in Python spaces for indentation isn't just a personal preference - you'll run into a fair amount of issues with that, this one being just the tip of the iceberg.

Re: Boring Python: Code quality

#93

Post by ReflectedImage »

bombolo wrote: post #87
ReflectedImage wrote: post #71

Earlier quoted context omitted.

"The claim that untyped code has fewer bugs is completely bonkers" There are plenty of academic sources that will tell you that the number of bugs in a program is directly proportional to the number of lines in the program and static typing has no effect on this. https://stackoverflow.com/questions/2898571/basis-for-claim-... Additionally, statically typed code involves large amounts of boilerplate code in the form o…

Please don't reply multiple times to the same thing. > Actual Python houses typically don't use static typing. If you had ever developed python professionally, you'd know this to be untrue. Also your "paper" points to a 404 page.

I have developed in a lot of Python houses.

Given that type hints are a new language feature in Python, please explain to me how these Python houses used static typing when type hints didn't exist?

I'm all ears.

Re: Boring Python: Code quality

#94

Post by MrJohz »

bombolo wrote: post #67
throwawaaarrgh wrote: post #63

Earlier quoted context omitted.

> So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. Any team of developers who aren't using the exact same environment are going to run into conflicts. At the very least, there must be a CI job that runs quality gates in a single environment in a PR and refuses to merge until the code is correct. The simplest way is to just fail the build if the job results in…

> Any team of developers who aren't using the exact same environment are going to run into conflicts. You've never done any open source development I guess? Do you think all the kernel developers run the same distribution, the same IDE, the same compiler version? LOL. Same applies for most open source projects.

A lot of modern open source projects include a lock file or some other mechanism that ensures that all contributors use the same versions of certain key tools. Obviously there are still going to be some differences in the environment, but for things like formatting, linting, etc, it's generally fairly easy to lock down a specific version.

In Python, the easiest way to achieve this is using Poetry, which creates a lock file so that all developers are using a consistent set of versions. In other languages, this is generally the default configuration of the standard package manager.

Re: Boring Python: Code quality

#95

Post by BerislavLopac »

bombolo wrote: post #7

> I recommend using two tools together: Black and isort. Black formats things differently depending on the version. So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth. isort's completely random… For example the latest version I tried decided to alphabetically sort all the imports, regardless if they are part of standard library or 3rd party. This is a big change…

> So a project with 2 developers, one running arch and one running ubuntu, will get formatted back and forth.

You should never develop using the system Python interpreter. I recommend pyenv [0] to manage the installed interpreters, with a virtual environment for the actual dependencies.

[0] https://github.com/pyenv/pyenv

Re: Boring Python: Code quality

#96

Post by bombolo »

ReflectedImage wrote: post #93
bombolo wrote: post #87

Earlier quoted context omitted.

Please don't reply multiple times to the same thing. > Actual Python houses typically don't use static typing. If you had ever developed python professionally, you'd know this to be untrue. Also your "paper" points to a 404 page.

I have developed in a lot of Python houses. Given that type hints are a new language feature in Python, please explain to me how these Python houses used static typing when type hints didn't exist? I'm all ears.

> Given that type hints are a new language feature in Python, please explain to me how these Python houses used static typing when type hints didn't exist?

They've existed since 2015… please explain me how 2015 is "new"?

Re: Boring Python: Code quality

#97

Post by bombolo »

ReflectedImage wrote: post #90
bombolo wrote: post #86

Earlier quoted context omitted.

That seems to completely forget the fact that libraries exist, that A LOT of bugs can happen calling libraries, and that you're not really supposed to unit test libraries, they are supposed to have their own tests.

Unit tests test the parts of the library that are in use implicitly. As does integration testing, user acceptance testing and whole system testing (QA engineers, frontend testing, etc.) Nothing has been forgotten. Python isn't Java, nor should you develop your Python code as if it were Java. Python has it's own software development practices that take advantage of the language's strengths including dynamic typing. It…

> It you don't know how to work with a dynamically typed language properly, that's on you. And I guarantee you will get poor results pretending it's a statically typed language.

Insulting me won't make you a better developer nor a better person :)

Getting started with type hints is not easy, but it can be done incrementally and it is worth it.

If you haven't used them, please learn before insulting people who are more experienced than you.

Re: Boring Python: Code quality

#98

Post by bombolo »

MrJohz wrote: post #94
bombolo wrote: post #67

Earlier quoted context omitted.

> Any team of developers who aren't using the exact same environment are going to run into conflicts. You've never done any open source development I guess? Do you think all the kernel developers run the same distribution, the same IDE, the same compiler version? LOL. Same applies for most open source projects.

A lot of modern open source projects include a lock file or some other mechanism that ensures that all contributors use the same versions of certain key tools. Obviously there are still going to be some differences in the environment, but for things like formatting, linting, etc, it's generally fairly easy to lock down a specific version. In Python, the easiest way to achieve this is using Poetry, which creates a loc…

Using lock files is a good way to make sure your software never ends up in a distribution and in the hands of users.

Re: Boring Python: Code quality

#99

Post by ReflectedImage »

bombolo wrote: post #96
ReflectedImage wrote: post #93

Earlier quoted context omitted.

I have developed in a lot of Python houses. Given that type hints are a new language feature in Python, please explain to me how these Python houses used static typing when type hints didn't exist? I'm all ears.

> Given that type hints are a new language feature in Python, please explain to me how these Python houses used static typing when type hints didn't exist? They've existed since 2015… please explain me how 2015 is "new"?

Python has been around since 1991. I'm little bit more experienced than you.

Re: Boring Python: Code quality

#100

Post by gjulianm »

drcongo wrote: post #92
gjulianm wrote: post #81

Earlier quoted context omitted.

Yes. The code started as being indented by tabs, so changing it now is a mess. Also, not to start a flamewar, but I've always preferred tabs to spaces in any language, I find them more reliable, easier to use...

Not going to argue about your personal preference, but in Python spaces for indentation isn't just a personal preference - you'll run into a fair amount of issues with that, this one being just the tip of the iceberg.

Apart from isort not knowing how to deal with tabs, and changing the defaults "spaces" to "tabs" in the tools (along with line length too, because for some reason the 80 character limit is set in stone even though it's absolutely outdated) I haven't had many issues. And this has been running for years already.
Post reply on HN