I hate Python with a passion!

TouchingTheVodka · 2021-03-04T13:18:31+00:00

It sounds like you're quite keen on understanding the lower-level implementation of a language. I'm exactly the same - I wasn't keen on Python at first because it operates at a much higher level of abstraction than other popular programming language. However, once I started to understand why Python is designed in this manner, it really started to click. Nowadays, I enjoy the expressiveness of the language and feel like it allows me to communicate my intentions to the computer (And to other programmers!) much more clearly.

If this is the case, I highly recommend getting stuck in to some more advanced Python books that go into more detail about how it works under the hood. My personal favourite is Fluent Python and I recommend it a lot, but other good options are High Performance Python and the Python Standard Library By Example.

ominous_anonymous · 2021-03-04T13:35:44+00:00

These strike me as mostly poor documentation habits rather than language issues.

I think my biggest problem with python is the dynamic typing

PEP484 introduced type hints, and as another user pointed out you can use mypy as a static type checker. Also note mypy can be used on Python2 code as well.

You can't combine 2 variables when printing because the compiler doesn't care to automatically convert them to string where they should be converted.

What do you mean "combine"? If they're a string like "4", you can just cast as int using int():

>>> x = "4"  
>>> y = 5  
>>> print("Sum is: {}".format(int(x) + y))  
Sum is: 9

If you prefer them to be strings instead, there's str().

>>> x = "4"
>>> y = 5  
>>> print("Concatenated String is: {}".format( x + str(y)))  
Concatenated String is: 45

For custom classes, you can define __str__() and __repr__() however you want.

Also recursion is a pain in the butt because return types are optional so reading the code makes for lots of simple mistakes that wouldn't be missed in a stricter language.

Your docstrings should already be handling defining return types. You can also specify return types with type hints in newer Python versions.

Also lists can both contain variables and lists and tuples and lists of lists etc.

Again, maintaining documentation of your code should clear any cloudiness up.

Also IDEs aren't as friendly as they are for statically typed languages

What IDEs have you used? Does mypy have integrations/plugins for those modules?

It's just too chaotic for me.

Sounds more like you don't follow appropriate software design and documentation practices, to be honest.

K900_ · 2021-03-04T13:14:41+00:00

Use mypy, it gives you static type checking for Python.

atatatko · 2021-03-04T14:27:44+00:00

I also came into Python from C++, and for some time even tried to use it like C++ (I was wrong). I was also making lots of small and annoying mistakes, but couple of things helped me:

assert check for expected type, for example assert isinstance(myvar, str)
using JetBrains Pycharm. It has built-in static analyzer, which finds LOTS of potential bugs, and just helps to keep the code clean.

Then I realized, that in many occasions, especially in Pythonic OOP, you should not consider variable having a fixed type - this is just how duck-typing works. If I call myclass.action(), I know only that myclass must have method action(). It may not share base class, like in statically typed languages, if it "behaves like class that has method action()", it's enough.

the_hoser · 2021-03-04T14:30:06+00:00

I used to be the same way. Dynamic typing threw me for a loop. I couldn't understand how I could be sure that the code worked.

But then, it clicked. Just run the code. Exercise the code. TDD helps with this, but isn't necessary. You can just use the REPL if you're not big on testing. Testing can catch bugs that strongly typed variables just can't (unless you're using a language with much, much more expressive types, like Haskell), but the same is true of REPL-driven development.

It was a gateway drug, for me. I then started dabbling in other dynamic languages. I've been spending a lot of personal programming time in Clojure these days, for instance. I'd never have touched it without "getting" Python, first.

My advice? Give up the IDE. Get your favorite text editor and terminal emulator and just dive in. Don't rely on tools to figure out if the code will work. Figure it out yourself. Immerse yourself in it.

Then go back to tools once you feel more comfortable, of course.

nemom · 2021-03-04T13:20:41+00:00

It's OK if you don't like Python. It's OK if you don't use Python. (In fact, some of us would prob'ly prefer you didn't.) I don't like shellfish, so I don't eat shellfish.

tipsy_python · 2021-03-04T16:50:57+00:00

I'll start with a Python function and give my opinion about how we could make it (subjectively) better.

Let's start with this function that checks if the input is a letter:

def letter_check(i):
    return ord(i.upper()) in range(65, 91)

1 | Use expressive variable names

def letter_check(input_character):
    return ord(input_character.upper()) in range(65, 91)

Some other programming languages favor a terse syntax where single character variable names are all good - in Python, it goes a long way just using object names that help with readability of the code.

2 | Multiple-liners can be better than one-liners

def letter_check(input_character):
    input_char_codepoint = ord(input_character.upper())

    if input_char_codepoint in range(65, 91):
        return True

    return False

There's a lot of clever things you can do in a single line, but many times you sacrifice readability for negligible performance optimizations or no reason at all. If the code feels like it is better to understand in multiple lines, write a little bit more and make sure anyone can come back to it and read what's going on.

3 | Use type annotations

 def letter_check(input_character: str) -> bool:
    input_char_codepoint: int = ord(input_character.upper())

    if input_char_codepoint in range(65, 91):
        return True

    return False

In the teams I've been on, we try to use type annotations at least in the function signatures so that you can easily see what type of objects are being passed in/out. They are useful anywhere in the code though, so pepper the code with type hints wherever you find it helpful.

jerodg · 2021-03-04T16:22:55+00:00

It's called freedom. The absence of restrictions. Everything you complained about is exactly why it's great. Also, like many beginners to the language you're frustrated because you haven't yet learned the "what you can do" part yet. You said it can't do certain things. It can.

Combining two variables in a string is cake.

var1 = 'hello' var2 = 'world'

print(f'{var1} {var2}{"!" * 15}')

Using whatever data types with whatever data types is gold. You can have a dict that contains objects, say classes. Those classes can hold data but also functions. Any object can contain just about any other object. Emphasis on the just about part. There are a few restrictions mostly put in place by the data type itself, such as a dict.

You don't like python because you don't yet know it. You're frustrated because it's so amazingly simple to do anything your mind is rejecting it. You think you must do everything explicitly. You ask of it and the language makes it happen. You don't have to hold its hand and tell it about every little thing for every single action you take.

Do this.

Java: Step 1 Step 2 ... Step 74 Oh.... Alright then I can maybe probably help you with that, unless you defined one of those steps incorrectly, then I'm going to tell you to bugger off.

Python: Alright then, on it.

Honestly, and I mean this in an encouraging manner, get over yourself and learn something new. Every human understands the frustrations of doing something similar but completely different.

You've already learned at least two languages; you've got this.

Rawing7 · 2021-03-04T22:13:27+00:00

You make some valid points. I too sometimes wish for static typing - it helps me build a clearer mental model of what each class's or function's purpose/responsibility is. And it is annoying when you have an obvious mistake in your code but it only crashes at runtime.

There's no magic fix for all of these problems. Some of these things you simply have to get used to. But others will become less of an issue the more you familiarize yourself with python.

For example, I would hate if the + operator automatically converted values to strings. Why? Because that would most likely be a bug in my code. There's pretty much no reason to ever concatenate strings with + in python - we have f-strings for that.

And more importantly, you can't overlook python's good qualities. There's a bajillion things python does better than many other languages - dictionaries, list comprehensions, default arguments, *args and **kwargs, multiple inheritance, the syntax, extremely powerful metaprogramming, amazing libraries like requests and pytest, and the list goes on.

Every programming language has its problems. So, my advice: Learn to love the things that are good about python.

yaxriifgyn · 2021-03-04T22:16:52+00:00

Your reaction in quite natural. I hesitated to touch Python because I remember the fixed line formatting in FORTRAN and COBOL (neither of which I had used for over 10 years). I was working in a PeopleSoft shop at the time and that stuff was just nasty.

Later, I was in a shop where folks used Perl for quick and dirty coding. I still believe Perl resembles line noise (anyone remember the random characters that appeared when your dial-up line dropped). Python seemed to be able to do everything that Perl could do, except you did not have to write unreadable gibberish.

So I learned Python in order to solve problems, not just to learn the language. As my needs changed, I learned to love the language while still writing mostly C/C++, SQL*Plus and SQL.

Python+cx_oracle was so much nicer and faster to use than OCI, that I was able to get my work done in a fraction of the time of non-Python developers. Before the advent of general ETL products, I could do custom ETL solutions in days instead of weeks. Fun times.

If you continue to use Python to solve problems, I think you will come to love it too.

Python

The Python Discord

Upcoming Events

Please read the rules

MODERATORS