Hacker News new | past | comments | ask | show | jobs | submit login

Yes, and you can do it with import hooks as well.

The reason you don't see it in python much is more a matter of culture: we don't like too much magic nor DSL.

With the new generation of coders incomming, it may change though.

Hope not, as most devs are terrible at designing magic or languages and equally terrible at admitting they are.

It took a decade for the trend of monkey patching things in ruby and js to disapear and I don't regret that time one bit. Bad habits die hard.




Probably not so much a matter of culture, but more that the mechanism is a) garbage b) high effort.

I bet if either of those two weren't true, you'd see a lot more of it.


I think you might be putting the cart before the horse so to speak. The culture of python doesn't value these things so the only mechanism is high effort garbage.


There is truth in that, but also a bit of "he who can't do what he wants must want what he can do". The only reason python still matters (more than ruby) is because of its dominance in ML/datascience. And this ecosystem is full of nasty syntactic hacks.


I can't speak for other people but the only reason I still use Python is because of it's syntax (but the "one way to do it" is slowly changing). You get much better concurrency with Golang and even better parallelism with Julia.

It is dominant in data science but still some people use it for other things because the syntax is so simple (Scheme is a close second for me).


If you mean the pseudo-code like quality that (sadly) remains a distinguishing feature, I completely agree.

Simplicity, as in terms of specifying the grammar though? Python's grammar is exceedingly gnarly by now and I'm pretty sure Go, Lua, Prolog, Smalltalk and pretty much every Wirth language are massively simpler, syntactically.


Yes, I meant the pseudo-code quality of Python (I wish Wikipedia would use Python as it's pseudocode :)).

I completely agree that Python is pretty hard to implement. Perhaps you have heard that simple doesn't mean easy ? I could easily implement a Forth (or assembly) interpreter. But it isn't that easy to understand a big complex Forth program (compared to Python). Simple languages like Forth and assembly are too unstructured for me.


I'm sceptical of the idea that the good things about python make it hard to implement. Compared to forth – sure! But most of the non-simplicity beyond what's attributable to not being an ultra-bare bones languages comes from organic growth and bad design decisions.

From the top of my head, here's a list of things that were awesome in python's design:

1. Clean and concise syntax (whitespace, slices, rest and kwargs, multiline and raw strings, although both badly designed were ahead of the time)

2. good default builtin datatypes, with decent API (cf garbage like cons cells or STL)

3. in particular strings as immutable vector of bytes, no seperate character type (this got screwed up in python3 of course)

4. comparison on compound datatypes works out of the box

5. relative uniformity no value vs reference type; objects mostly just dicts, modules as well

6. repr and repl (both gimped, compared to lisp, but good enough to be super helpful in development), good tracebacks

7. anti-footgun conventions (notably: mutating functions return None convention; mutable -> no __hash__ convention; slicing copies convention)

Nothing in this list seems particularly hard on the implementor, but it's of course hardly exhaustive or unbiased. What things that you really like about python do you think are rather hard to implement?


Implementing a minimal Python is pretty easy (even with the huge standard library) but implementing a complete Python implementation is a herculean task. And even after that there is no guarantee that every Python library will run on your implementation (Pypy).

I don't know about you but I would rather make hundreds of Scheme and Forth implementations then one Python interpreter. But I don't really see that as a downside. I mean who decides on a language based on how easy it is to implement ?


Well, all things being equal a cleaner and more understandable language is going to be easier to implement, so I don't think difficulty of implementation should be dismissed so easily. Especially when the difficulty of implementation is not due to advanced features such as a fast runtime, resumable exceptions, proper tail calls, multi-method dispatch, pattern matching, powerful concurrency abstractions, SMP...




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

Search: