One of the great benefits I had for learning Python is that I was able to learn it under supervision from colleagues. I was pretty much left to my devices as far as the codebase went, but when I needed to discuss something, there was always somebody to discuss it with, to bounce ideas around.
Another benefit was that the colleagues that I was working with were quite diverse in their knowledge, each knowing certain regions of the language a bit better than the rest. So occasionally, somebody would come along with a "Did you know that you can ...?". This is one of the best ways of learning.
An even better way of learning comes when a colleague comes to you with a question: "Do you know how I can ...?". Ideally, they ask you a question that you do not know the answer to (after all, your colleagues are just as awesome as you are—if not even more awesome). In that case, you should make sure you can learn from that question. Do not answer "I do not know.", instead, say "I do not know, yet.". Make sure you find out if it is or is not possible. If it's possible, find out at least 3 possible ways to do it, and find argumentation why one of those 3 ways is the way to do it.
But I disgres. The point is that by having the possibility for discussing the language (and using it!) easily helps with learning a language.
Before I continue, let me state the following: I do not proclaim that PHP is a terrible language. Sure, it has its confusing parts, some parts are quite surprising, its design has some areas that make me think less of it. But it is in no way impossible to write good code in PHP. It just takes more effort.
However, C, Haskell, Java and other languages have less of a 'bad design' vibe than PHP. So why is it that I know Python best? I think it is because of it being a well-constructed language, with very few special cases and simple rules. Changes to the syntax and semantics are very few, and thought out quite nicely.
Let me just name some of the things I think are awesome in Python.
Context managers. A way of elegantly hooking into actions when a scope ends, somewhat giving you the same power as what C++ gives you with RAII but in a less optimal way.
Decorators. This allows you to wrap classes and functions with some generic code (like, permission checking, registering with URL routing, wrapping it in a cache).
Protocol methods (or dunder methods, magic methods). Nearly all pieces of syntax gets mapped to function-calls. The syntax a[b] gets (overly simplified!) interpreted as a.__getitem__(b). Also, len(a) becomes a.__len__(). The iterator protocol, for example, is based on the dunder method __iter__. The contextmanager protocol on __enter__ and __exit__.
The descriptor protocol. Used to implement decorators such as property, classmethod and staticmethod, but also heavily used by the Django ORM.
Metaclasses. Metaclasses give you a way clean way to hook into definition of classes, allowing you to re-map attributes on the fly. Metaclasses are also one of the implementation details of the Django ORM.
There are probably a few more of the niceties I missed in this enumeration here.
Sure, this semantics has some corner cases, but mostly this all works out. By really knowing how the interpreter works, you can hook into pretty much anything. You can move a lot of complexity towards the libraries, building a simple API around complex interactions.
One of the things in which Python really excels over PHP is its standard library. PHP has an extensive standard library, but it is not really consistent. The Python standard library is also quite extensive, but has a lot less inconsistencies you keep running into. This standard library also showcases a lot of the semantics from the previous point.
The nice thing about Python is that a great part of the standard library is written in Python itself. You can literally read the source-code of the methods you are calling, and it is in the same language that you are writing.
Ok, the same argument would probably also hold if you are writing C. But that's all compiled, so it is more rare for me to look up the code of a C function I'm calling (like, the source code of sprintf). Now I occasionally do that for C as well, but for Python it is really easy.
But, I also read the C code of CPython. It is generally well laid out, clearly documented, and very readable. Yes, you do need to understand C a bit, but in most cases you should be able to make it out quite clearly even if you do not know C that well.
I really recommend browsing through the ceval.c file which implements the evaluation loop. It has some really interesting points, including a workaround for C compilers which do not understand large switch statements.
One thing that helped me a lot was actually trying to figure out what parts I would need to change in order to change a bit of Python semantics. Now I have not tried to do this very often, but in the times I have, it's really a great learning experience. Especially when introducing syntax changes as well, you have to take care of modifying the grammar, enhancing the parser, the symbol table creator, the bytecode compiler, and finally the evaluator loop.
Now, I can already tell you that your proposed syntax change is most likely not going in, but it is a good idea to at the very least try and build a patch for it yourself. If only because of the fact that it helps you better understand the CPython interpreter.
Python ships with a REPL (read-evaluate-print-loop) by default. PHP does not, or at least I did not find out how to use it properly. Playing around in a REPL is a great way of experimenting with a language. A way in which you can easily learn a lot. I think it is partially due to the extremely quick feedback loop. The fast feedback loop allows for even a higher rate of experimentation, which easily translates in more lessons learned.
When I started my career as a professional programmer, I did not yet have experience with automated testing, let alone Test-driven development. I do not anymore know how I got introduced to unit-testing and Test-driven development, but I do know it now is an important part of my development style.
However, I never really experienced doing unit-tests in PHP, but I now have plenty of experience with unit-testing in Python.
The systems I built in PHP were fairly complicated, but were also part of a framework already laid out for me. I had to make some 'minor' code-changes, but nothing much. The things I built in private were also not quite complicated.
The Python project I had to maintain, however, was just as complicated, but I was able to make quite a lot of refactorings which greatly improved the design of the project, and also improved the testability of parts. Precisely this refactoring requires you to understand the ins and outs of a language, and will help you understand more when you find out you broke it.
Another point is that the complication in the Python project also required me to venture out into epoll: edge-triggered polling on sockets. This in itself is quite complicated, but also requires you to understand the strengths and limitations of the language you are working in.
I think that in the end, the reason that I know Python better than PHP is partially due to the difference between the language, but also due to a difference between the environments in which I used the languages. I was able to learn Python in an environment which was really conductive to learning the language properly: I had a great, complicated project on which to learn Python, and the team I was working in also provided me with enough opportunities to learn, either directly or indirectly.