Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It is shocking how much vodoo magic there is in a programming language marketed as "easy to learn and use".

And with the recent addition of new syntax, I would hardly call Python easy.



Python is easy, not because it prevent people from doing complicated things, but because with only a few simple things, you are productive.

Most python programmer use 10% of the language, the same 10% that is described in most tutorial, because that's enough, and they don't even know the rest exist.

This makes for a very smooth, but long learning curve which allow you to enjoy python in the early years, yet keep getting a kick out of it after 15 years.

I hear a lot of people raising the same kind of concern you do in comments, but in the field, I never do with people actually using the language.


That "smooth learning curve" applies when you are learning the language, use it by yourself or work in the ML/Data science industry.

Once you get thrown in a big project that makes heavy use of type hinting (plus the whole environment of it, mypy et all), Object Oriented design and all those hidden things...you realize how much you really don't know.

And that 10% is way too small. To be productive in Python, you need to know at least 50%, or you will be reinventing a lot of existing things. Poorly.


Using a different language isn't going to stop the vertigo of being thrown into the deep end of an existing project without a mentor to guide you through it.


If you make a big project, you will have to use that many things with every langagues. If the language is rich, you'll learn the language. If not, you'll learn the project patterns. It's not specific to python.

But 99.9999999% projects won't implement metaclasses.

Most won't event implement decorators, context managers or generators. Use them, sure.


The REAL power comes from the libraries. In the Olden Days, we would call these 'subroutines' -- libraries contain the gussied-up subroutines that make it possible to do amazing things in Python with that "10% of the language" we use.


Python already has a bunch of built-in libraries that make it a full-fledged scripting language. Basically, it is Node.js on steroids.

In the olden days, programmers would have to make 90% of that, alone.

Maybe this is the reason why everyone and their grandma can call themselves programmers these days.


Yes. And all this fancy 'metaprogramming' is just syntactic sugar for how one calls subroutines.

I agree: Python has Batteries Included. But additional Batteries are Optional.


> It is shocking how much vodoo magic there is in a programming language marketed as "easy to learn and use".

But that's exactly what that expression means?

A car with an automatic transmission is "easy to learn and use", but an automatic transmission is way more complicated to construct than a manual one.


I wouldn't call subclasses, metaclasses and decorators easy to use, let alone learn to use correcly.

The comparison makes no sense.


What? Decorators are easy to use, subclasses are easy to use, and you don't need metaclasses.


I read your "vodoo magic in a programming language" to mean "behind the scenes in the implementation of the programming language", not "for a programmer to understand while using the programming language".


Ran into this face-first, just yesterday. I'm converting a rather old, rather big API (~400 endpoints) from Python 2.7 into 3, and apparently in Python 2, _hasattr(something, someattribute)_ just returns False if attribute access throws an exception! Specifically, if you have

  class A():
    @property
    def a(self): 
      raise Exception('go away')

  a = A()
 
then hasattr(a, 'a') will return False in Python 2.7 (and throw as expected in Python3)

A true WTF moment, the tests and the API have been slightly broken for years, without anyone noticing.


This is a rather unusual problem and I would call this design flawed. Defining useless methods that only exist to raise an exception is in my opinion a waste of space, both virtual and textual.


obv, this is just a minimal demo (i don't name my classes A!); in actual codebase, there's a complicated calculation that throws up under some circumstances


What an odd thing to say. This article is not for beginner Python programmers, and you don’t need to know anything in this article to use Python. I know people who refuse to use decorators because they seem difficult, and yet they are able to make very useful applications.


I’ve been writing Python professionally for over 20 years, and I’ve needed to use the things here once. It was highly encapsulated inside one module of an ORM-type project, where other code wanted to use it without having to know anything about its implementation details.

You can do these things in the extremely rare cases that you must, but other than that you shouldn’t.


I’m surprised to hear your opinion on this. I have around 12 years of python experience and I find metaprogramming to be, by far, the most important part of Python. Without the extensive ability to rewrite underlying functionality in a way that was approachable to both novice and adept users, I don’t think we’d have seen a widespread adoption of the language to begin with.


I was referring particularly to metaclasses. Decorators, etc.? All the time.


I guess I don’t often touch metaclass either, although after reading this article it gave me some ideas on how I might better implement object validation patterns. That being said, I also have recently become acquainted with pydantic, which does take care of some of that.


Pydantic’s a great example of a good use of metaclasses. I’ve seen them abused in places where there were far simpler ways to accomplish the same goal, and promptly ripped that code out.


For a language that is actually "easy to learn and use", look at Lua[1].

It's so easy to learn & use that children manage to be productive with it (the Roblox community).

It's still powerful though. With few enough primitives to remain simple & understandable, it has just enough primitives to build anything. People have written web frameworks, window managers and video games in Lua.

It's got less pitfalls, "voodoo magic" and advanced weirdness than any other language I know. You can learn 90% of the language from its Wikipedia page. Every time I encounter some of Python's internal weirdness, I wish Lua had been the scripting language of the 2000s instead. Unfortunately Python has a vast collection of libraries available that keep us using it instead.

[1]https://www.lua.org/pil/contents.html


That's not uncommon, when you make something easy* to learn and use you obfuscate certain things that are more "advanced" to streamline the onboarding experience, and then when you want to break out of the streamlining you gotta learn to circumvent those "stops" somewhat, which often end up being pretty non ergonomic. It compounds as well because the ones developing the language will have a bias towards what it currently offers and the "unorthodox" side keeps getting set aside.

*and by easy there I mean streamlined and more intuitive on most expected "common" tasks than the alternatives


Most Python programmers never need to worry about the "voodoo magic". But for writing tools and libraries that can nicely encapsulate a desired behavior and make it simple for other programmers, Python's "voodoo magic" is great.


You consider python full of vodoo magic? Go learn guile for a week and let me know what you think then :-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: