4 ms·

In the very typical for Python community way, an effort was made to put more training wheels on a bicycle that already has like six pairs of them. 1. This is n

In the very typical for Python community way, an effort was made to put more training wheels on a bicycle that already has like six pairs of them. 1. This is not a real problem (this only affects completely inexperienced users for whom everything is a problem anyways). 2. The real reason for a problem is the existence of multiple syntactical forms for import. To solve the problem one would have to remove the unnecessary import forms (but, come on, there isn't really a problem, so nothing needs to be done). 3. Modules historically struggled to be "real" objects in Python. So, another direction this could've taken is giving up on making them real objects. Just make them a syntactic convention (like packages in Java). But, again, there's no real problem here, so nothing needs to be done.

pdonis 3y ago
> this only affects completely inexperienced users I'm not sure that's true. It doesn't seem to me that all of the users who encounter the mpmath issue described in the article are inexperienced users. They just aren't experts on the internals of Python, nor should they need to be. > The real reason for a problem is the existence of multiple syntactical forms for import. I don't see how removing the "unnecessary" forms (I don't agree that they're unnecessary, but I'm putting that aside here for the sake of argument) would help. Can you elaborate? > giving up on making them real objects PEP 562 already moved in the opposite direction, towards making them real objects (or more precisely, towards exposing more of their real object interface at the Python level).
- crabbone 3y ago
  You need to be at the level where you understand the difference between import x and from x import. This comes after couple months of training. And if after that you accidentally mistype it -- well, you'll know where to look for a potential error. It is not a problem for anyone with significant Python experience. > "unnecessary" forms The from x import is unnecessary and so is import as. Both can be written like so: import x.y y = x.y # from import x y = x # as So, they aren't necessary. You can write any program that uses them without them. > PEP 562 already moved in the opposite direction, towards making them real objects Who cares? We had dozens of nonsense PEPs, and will have hundreds more. Python isn't known for good planning nor for execution. I'm talking about what should've been done. The nonsense Python does is way over there when it comes to what it should be doing.
rjmill 3y ago
Python is a common choice for "first programming language." Whats the problem with making it more friendly/helpful to beginners? I'm more worried that this PEP will make things more confusing for beginners. I see this PEP as a removal of some training wheels. It opens the door for much weirder behavior than warnings/error messages. Whenever I've reached for this feature, it's been to do something "clever" that I probably shouldn't have been doing in the first place. Sure, some people will do wonderful/helpful things with this feature. But lunatics like me will use this to do some absolutely unhinged things. I hope this PEP gets accepted, but I understand if the maintainers decide it's a bridge too far.
- crabbone 3y ago
  That's not making it friendly for beginners. What this PEP suggests is yet another clutch for advanced users. It will allow advanced users to screw with module properties in all sorts of unpredictable ways. Beginners will be just a little bit more screwed if this feature is added. But they are already in such a deep hole if they started with Python... I don't know how to help them except by suggesting they use a different language.
jimmytucson 3y ago
There are more inexperienced users than experienced ones, so if it really does disproportionately affect inexperienced users, it’s an even bigger problem!
- codexb 3y ago
  I think the point is that this issue is occurring because of bad conventions and api designs that are pervasive in one area of the python community. It seems a bit like the tail wagging the dog to change the design and implementation of the language for the singular purpose of guarding against confusing import statements that most of the community would recommend not to use in the first place.
PurpleRamen 3y ago
> 1. This is not a real problem (this only affects completely inexperienced users for whom everything is a problem anyways). To be fair, mostly nothing in python is a "real problem", it's all just syntactic sugar to make coding more comfortable. > 3. Modules historically struggled to be "real" objects in Python. So, another direction this could've taken is giving up on making them real objects. No, go the opposite. Just make them first class objects. There is valuable comfort in this. Python is multi-paradigm anyway.
- crabbone 3y ago
  [flagged]
deleted 3y ago
[deleted]

pdonis 3y ago

> this only affects completely inexperienced users I'm not sure that's true. It doesn't seem to me that all of the users who encounter the mpmath issue described in the article are inexperienced users. They just aren't experts on the internals of Python, nor should they need to be. > The real reason for a problem is the existence of multiple syntactical forms for import. I don't see how removing the "unnecessary" forms (I don't agree that they're unnecessary, but I'm putting that aside here for the sake of argument) would help. Can you elaborate? > giving up on making them real objects PEP 562 already moved in the opposite direction, towards making them real objects (or more precisely, towards exposing more of their real object interface at the Python level).

crabbone 3y ago
You need to be at the level where you understand the difference between import x and from x import. This comes after couple months of training. And if after that you accidentally mistype it -- well, you'll know where to look for a potential error. It is not a problem for anyone with significant Python experience. > "unnecessary" forms The from x import is unnecessary and so is import as. Both can be written like so: import x.y y = x.y # from import x y = x # as So, they aren't necessary. You can write any program that uses them without them. > PEP 562 already moved in the opposite direction, towards making them real objects Who cares? We had dozens of nonsense PEPs, and will have hundreds more. Python isn't known for good planning nor for execution. I'm talking about what should've been done. The nonsense Python does is way over there when it comes to what it should be doing.

rjmill 3y ago

Python is a common choice for "first programming language." Whats the problem with making it more friendly/helpful to beginners? I'm more worried that this PEP will make things more confusing for beginners. I see this PEP as a removal of some training wheels. It opens the door for much weirder behavior than warnings/error messages. Whenever I've reached for this feature, it's been to do something "clever" that I probably shouldn't have been doing in the first place. Sure, some people will do wonderful/helpful things with this feature. But lunatics like me will use this to do some absolutely unhinged things. I hope this PEP gets accepted, but I understand if the maintainers decide it's a bridge too far.

crabbone 3y ago
That's not making it friendly for beginners. What this PEP suggests is yet another clutch for advanced users. It will allow advanced users to screw with module properties in all sorts of unpredictable ways. Beginners will be just a little bit more screwed if this feature is added. But they are already in such a deep hole if they started with Python... I don't know how to help them except by suggesting they use a different language.

jimmytucson 3y ago

There are more inexperienced users than experienced ones, so if it really does disproportionately affect inexperienced users, it’s an even bigger problem!

codexb 3y ago
I think the point is that this issue is occurring because of bad conventions and api designs that are pervasive in one area of the python community. It seems a bit like the tail wagging the dog to change the design and implementation of the language for the singular purpose of guarding against confusing import statements that most of the community would recommend not to use in the first place.

PurpleRamen 3y ago

> 1. This is not a real problem (this only affects completely inexperienced users for whom everything is a problem anyways). To be fair, mostly nothing in python is a "real problem", it's all just syntactic sugar to make coding more comfortable. > 3. Modules historically struggled to be "real" objects in Python. So, another direction this could've taken is giving up on making them real objects. No, go the opposite. Just make them first class objects. There is valuable comfort in this. Python is multi-paradigm anyway.

crabbone 3y ago
[flagged]

deleted 3y ago

[deleted]