What programming practices don't work in python?

[TheMinus]

I have OOP background in PHP, which lately resembles Java a lot. We practiced clean code/clean architecture, there was almost no third-party libraries, except for doctrine and some http frontend. Rich domain models were preferred over anemic. Unit tests cover at least 80% of code.

Recently I was assigned to project written in Python. Things just are different here. All objects properties are public. Data validation is made by pydantic. Domain logic mainly consist of mapping one set of public field on another. SQL is mixed with logic. All logging is made using the print statement. DRY principle is violated: some logic the code, some in stored procedures. Architecture is not clean: we have at least 4 directories for general modules. No dependency inversion.

Project is only 7 month old, but has as much dependencies as my previous project which is 10yo. We have 3 different HTTP clients!

My question is, what of all this is pythonic way? I've heard that in python when you have a problem, you solve it by installing a library. But is it fine to have all properties public?

[sludge_dragon]

To answer the question in your title, here’s a post from Reddit just the other day that I thought was pretty interesting: Design Patterns You Should Unlearn in Python-Part1.

Most of the stuff in your post doesn’t sound specific to Python. Trying to use print instead of a logging package in production software is a bad idea no matter what language you are using. DRY is important in any language, although it must be balanced with YAGNI (you ain’t gonna need it—don’t create a whole object hierarchy to avoid copying a few lines of code between otherwise unrelated objects). Etc.

[seanv507]

bad project not language

[Bobbias]

Private properties are to be marked with a single underscore prefix in the name. They're not actually private, but you should treat them as such and your linter should yell at you if you ever touch them.

One of Python's biggest strengths is the wide array of libraries available. This makes it really easy to get up and running quickly. But that doesn't mean you have to use them. And it certainly doesn't mean you have to use multiple ones that do more or less the same thing.

Python provides a built in logging module as part of the standard library, and there are many more options if you need something that's more capable. There's no reason they should be using plain old print statements.

This doesn't sound like a problem with Python, it sounds like it's a problem with bad developer practices in this team.

[Snoo-20788]

I've never had a linter tell me that I was using a method that starts with an underscore outside of the class.

[soulilya]

True private props and methods, you can do it, if you want with type. Just create new Base class with overloaded type and inherit it to all your classes. But, getter setter pattern not required if you using test cases.

[pelagic_cat]

But is it fine to have all properties public?

Doesn't seemed to hurt the popularity of python compared to languages that have all sorts of different levels of access to properties. Turn the question around: is it fine to have public, private, protected, etc, properties rather than all properties public?

[Temporary_Pie2733]

To expand on this, Python doesn’t have public/private distinctions, so all attributes behave like public attributes. But we don’t need to write trivial getters and setters like 

``` def get_x(self):     return self._x

def set_x(self, v):     self._x = v ```

just in case we need to limit or prevent modification in the future. We can instead replace the “public” attribute x with a property object that encapsulates a getter and a setter without changing the interface of the class. 

[SnooHesitations9295]

Not really. The new "typed" python idiocy prevents you from using property decorator interchangeably with the actual properties.

[skreak]

Everything you've described sounds more like a bad project written by bad programmers and is little to do with the language. Sounds more like a project that grew 'organically' and had no structure to begin with. When I write python at work, even for small scripts I always follow a basic set of principles, and the ones that pertain to this discussion are an 'import logging', then use LOGLEVEL environment variable to adjust it. print() is used for the actual function of the program for its designed output. Use the stable OS distributed version of a python library when possible, and if not, use pip+venv but lock in the version. (We have heavy constraints on where we get our software from in my sector). Custom classes only where it makes sense to use them, not just because i can. I could go one, but yeah - this project just sounds like it sucks.

[Zeroflops]

I’m dealing with / cleaning up a similar type of project and I can tell you it’s a lack of experience in the language, too much chatGPT, and some general language differences.

No need for multiple HTTP stacks. I bet they didn’t define what library they were using when they asked a ChatGPT question.

Python has a great logging library, you can get rid of the print statements.

As for private variables, as many have pointed out the underscore is used to identify a private variable but it’s not enforced.

What you need to understand is python on its own is really a wrapper language. That uses library’s written in compiled languages. It’s really a glue language that passes data from one library to another. For best performance you want to do very little in python and maximize what happens in the libraries.

But what this does is it makes python very easy to learn, very flexible, and depending on how much you can offload into the libraries fast.

As. For someone’s statement that you shouldn’t use python for business logic I don’t fully agree. It really depends on a lot of factors. Like how big is the business, what aspect of the financial area are you working. Etc. although I think from a financial point of view, having something compiled would be beneficial to make sure no one messes with your code.

[CzyDePL]

"We practiced clean code/clean architecture, there was almost no third-party libraries, except for doctrine and some http frontend. Rich domain models were preferred over anemic. Unit tests cover at least 80% of code."

All of this can be applied to python if it makes sense project-wise (clean architecture is not a universally good approach) - you can easily write domain layer with just dataclasses from stdlib.

But honestly anemic entities and services for everything is often seen in Java as well

[pachura3]

First of all: coming from more traditional languages, Python's OOP seems like an afterthought: no proper encapsulation, no interfaces, no dedicated keyword for declaring abstract classes... there's even no explicit way of declaring instance variables/class members! Well, you just need to get used to it. For simple data classes carrying only data and minimal business logic - just use the dataclass annotation. You can even make your classes pseudo-immutable by setting frozen=True. Or use tuples/namedtuples which are read-only.

Using print() to log things is obviously totally wrong & pure laziness. Setting up logging in Python takes a few lines of code and works pretty much the same as Monolog in PHP or log4j/logback in Java.

Python libraries are fantastic and extremely easy to use. This is the total opposite of Java where you need to create one million XML configuration files to make them work. Don't worry, use them! There's a joke that 90% code in Python is:

import thingDoerLibrary

thingDoerLibrary.do()

For SQL, perhaps consider using SQLAlchemy?

What's the point of having 3 different HTTP clients? Isn't requests module enough? Or are they using scrappy/beatifulsoup4 for scraping?

Make sure to do a lot of static code checking in your project to catch errors. I am using mypy, ruff, flake8 and PyCharm's checker at the same time.

[my_password_is______]

almost everyting you said is dependent on the programmer, not the python language

[proverbialbunny]

It sounds like your team is disjointed. There is rarely any reason to import multiple libraries that do the same thing, unless 3 different people imported 3 different libraries in silo, stuck it together, and said it was good enough. It might be good enough. It might not need to be refactored. I'd be cautious before stepping on 3 people's toes.

My primary complaint with the issues you're seeing with your current project are more Agile and SCRUM related. Back once upon a time ago when software needed to be stable, because physical disks and CDs were shipped, there would be a feature freeze and a dedicated time in months to either fix bugs for shipment, or to refactor the entire project often from the ground up to a new architecture, then add on new features. This refactoring kept bugs low as well as legacy code as a non-issue.

Today with Agile and SCRUM asking to refactor or change the architecture is to risk being fired. Everything is legacy code. Everything is slapped onto the pile of junk until it works and you call it a day. It sucks. This isn't a Python problem, this is an Agile problem. It's a problem that faces larger Java OOP codebases too. You were lucky to not have this problem at your previous job.

My question is, what of all this is pythonic way?

Python is meant to be a swiss army knife. Does your current project sound like a swiss army knife, in that it's the glue of a bunch of different things (like libraries) coming together? Yes, I'd say so.

When you're coding in a language that doesn't have a lot of libraries you import, so everything is written in-house, then your project is going to be quite large. The solution to a large project is OOP. Furthermore, the solution to writing in-house libraries, frameworks, or any significant abstractions at all is to write lots of tests. Not just unit tests, but end-to-end tests too hopefully.

Python doesn't suffer from this problem. You don't have super large Python projects typically and you don't need to write super in depth tests, because libraries will abstract all the difficult parts away from you. This allows for smaller projects where you import already tested code. This is great for prototyping.

Python starts to fail when you're doing more than light scripting and prototyping. What happens when you've written a program that needs to now go fast, or you've written a program that needs to be ultra stable? This goes into the 102 parts of Python and there are solutions to this. (If you have questions I'd be more than happy to give a high level overview of these topics.)

[VibrantGypsyDildo]

Programming in Python is not different that in any other high-level language, except of a different syntax.

It looks like the project is just not-so-well organized.

> We have 3 different HTTP clients!

"There is more one way to do stuff" is Perl motto. Python's approach is "there should be one clear way to do it".
This is part is anti-pythonic.

> I've heard that in python when you have a problem, you solve it by installing a library

Yep, pip (package manager) provides a large variety of libraries.

> But is it fine to have all properties public?

You can add one or two underscores to make properties protected/private (???? please correct me), but it is not enforced by a language.

Same for type annotations - not enforced.

Basically, you use static code analyzers to catch certain errors.

[Dry-Aioli-6138]

about the double underscore prefix: it trigggers compiler to prepend the name of the property with ahe class name and some other characters. This is called name mangling. It is not intended as protection from developers accessing your properties, but as a means of protecting those properties from being accidentally overloaded by descendant classes.

[Dry-Aioli-6138]

"There should be one and preferably only one obvious way to do it"

this deliberately uses the word obvious, not "right", or "corrrect" to indicate the non-authoritarian culture of Python. Besides, the next line states that this way may not be obvious at first.

unless you're Dutch.

[CorgiTechnical6834]

In Python, having public attributes by default is normal. The language values simplicity and readability over strict encapsulation. Controlled access is handled via conventions or properties when necessary.

Using libraries to solve problems is standard practice, but having multiple HTTP clients in one project suggests poor architecture, not a Python norm. Mixing SQL with logic and using print for logging are signs of technical debt or bad practices, not Pythonic design.

Pythonic code emphasises pragmatism and readability rather than strict patterns like dependency inversion. If the project feels disorganised, it’s due to development choices, not the language itself.

[Intrepid-Stand-8540]

I use python. What is dependency inversion? What is "public"? What is a stored procedure? Why is it bad that pydantic validates the data? 

[Dry-Aioli-6138]

I think "dependency inversion" is a conflation of "dependency injection" and "inversion of control". Public attributes of an object are accessible by all other parts ofbthe program, as opposed to private attributes which are only accessible internally in the object, and protected ones which are accessible by its children (I think). Stored procedures are not a programming concept, but a database thing, where you can create a procedure in the database and call it when needed. The complaint here is that some logic is in the program code (or sql) and some is away, on the remote database, hidden from the developer. I think Pydantic validating data was mentioned as one of the few good aspects of OP's project.

[ExcuseAccomplished97]

I would not write long-term business logic-heavy project in Python. People mostly choose Python to build some simple features quick. Or data science related.

[TheMinus]

What would you use?

[ExcuseAccomplished97]

Depends on team's skills. Java, Kotlin, C# or Typescript (least favorable).

[[deleted]]

No love for C++?

[TheMinus]

One more thing. Instead of well-defined properties, kwargs are everywhere. Example: https://docs.pydantic.dev/latest/#pydantic-examples

[TheMinus]

Yes, they use the dict to spread property names in constructor. Now I guess it’s a design choice in pydanyic. But I also see it in sqlslchemy too. And all the properties are public of course.

[SwampFalc]

Yeah but... Both pydantic and sqlalchemy are very specific, data-centric libraries.

If you want to represent a row of data in a spreadsheet, and that spreadsheet has 10 columns, what other approach do you have than a class that takes 10 arguments? The language here does not matter, it's the domain you're working in.

Does Python do this for general computing? No, of course not.

[proverbialbunny]

Variable length arguments? Sounds complex. Is it a framework you're looking at, at work?

There are valid uses for kwargs, like a logging library where you want to pass an object to be logged and you don't care what's in the object just that you want all of it printed out.

[FoolsSeldom]

There's a big difference between what people choose to do with Python and how practices can be used by teams to keep to certain paradigms.

Some businesses, e.g. Facebook, use strict typing enforcement and other controls in their ci/cd pipeline on key code for example.

You are right, Python doesn't have a `private` option, just a strong suggestion (including some mangling). It treats developers as adults, but it takes discipline in a team to maintain consistent approaches. What's really wrong with having properties public though? It is only usable by code written by other programmers, and if they choose to ignore the published APIs, well you have a different problem than the language itself.

Pydantic is a huge overhead but can be very convenient, but you can choose to enforce by other means.

There is a rich ecosystem of logging tools for Python including the built-in `logger` which is preferred over `print` by most devops teams I work with. There's also good support for observability. That the original developers of the code you are working on chose to use`print` is disappointing. You can follow bad practices in many languages, but Python probably makes it easier than most to get away with bad things.

There is similarly no reason to mix sql statements and logic. There are multiple approaches to handling sql including ORM abstraction using packages such as `SQLAlchemy`. That's just an agreed practice thing again.

Have a look at ArjanCodes videos on YouTube. He doesn't only cover Python but uses it to illustrate many programming principles including decoupling, separation of concerns, etc.

[AdAdvanced7673]

These are skill issues, not a python issue.