You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`
This also happens when running in a program, not only in the REPL. Nothing should be printed when a module is imported, especially when not running interactively.
This is quite rude behaviour by a library to self-advertise like this. End-users have no interest in what module is use and those are the ones who will complain or find annoying, the most. The use-case for pygame in our project is small but rather than helping pygame it fosters the opposite attitude and increases the likelihood I will replace pygame with something else.
Please reconsider having this, no other library does this and it would be ridiculous if every Python module import advertised to stdout.
If you wish to foster support, you could ask for it. I know that I personally would gladly do that on any project I was going to distribute. But I agree, having to manually disable the ad print (which forces a console to appear!) is somewhat annoying. Great work though, please keep it up!
We do ask, fairly regularly in social media places, and there are various pages on getting involved over on the official pygame wiki and a contributing discord channel. Yet still we have yet to finish creating pygame 2, so every little helps.
Honestly, I feel the most important part of the welcome message now is the string of version information printed. Historically the majority (vast majority?) of our users are people beginning their programming journey rather than power users who care about a clean console - and it smooths the path to diagnosing these user's problems when every one of them can swiftly tell us what version of pygame and SDL they have running on their system.
I also feel that the small minority of users who care about the console message are exactly the sort of users who are equipped to add a single line of code to their scripts to disable it.
While it's rare for a library to do this (usually only interactive programs print non-error messages), but it might be a good idea to guard imports of third party libraries from printing warning anyway.
I don't like to complain about the decisions of other open-source projects, but this silly message breaks in a non-obvious way a tool I rely on intermittently.
Frankly, it's rude and unexpected to print stuff on import. Imagine if every library did that!
The diagnostics in the message are so far still very useful for quickly gathering information and diagnosing problems from one of pygame's main audiences of young people learning programming. They often have trouble describing information like this usefully and having it ready to go at a glance saves lots of man hours of back and forth trying to explain and extract it from them. I suspect it's more likely that we might expand the message to add more platform information at this point than scrap it. I used this message today in fact in one of my classes to quickly figure out an issue in a student's code - every library is different. Pygame's nature as a graphics library, and its long development, also makes it prone to lots of platform and underlying library version specific issues that not all libraries share.
So far it is simply far less work for us to tell the occasional disgruntled 'power user' to use the environment variable for their use case than it is to try and extract platform & version information from thousands of fresh young programmers. If anyone feels strongly about the direction of pygame then the best way to change it is to become involved in the project as a regular contributor and engage with the community - including all those students using pygame as one of their first game programming experiences.
Issue №1468 opened by jayeye at 2019-10-29 23:00:26
`
`
This also happens when running in a program, not only in the REPL.
Nothing should be printed when a module is imported, especially when not running interactively.
Comments
# # guidopetri commented at 2019-10-30 00:17:51
It's intentional in order to foster support for pygame.
If you really hate it, you can block it by setting the
PYGAME_HIDE_SUPPORT_PROMPT
environment variable. Here's the relevant line of code:https://github.com/pygame/pygame/blob/6cf4d1fdf2a14d739da5d593fb69967c0604600b/src_py/__init__.py# L355
(also, a simple google search would have sufficed)
# # illume commented at 2019-10-30 04:59:20
Thanks @charlesoblack.
Yeah. You can edit the pygame source code, or set the environment variable.
# # cas-- commented at 2019-12-13 17:38:09
This is quite rude behaviour by a library to self-advertise like this. End-users have no interest in what module is use and those are the ones who will complain or find annoying, the most. The use-case for pygame in our project is small but rather than helping pygame it fosters the opposite attitude and increases the likelihood I will replace pygame with something else.
Please reconsider having this, no other library does this and it would be ridiculous if every Python module import advertised to stdout.
# # Kyllingene commented at 2020-09-28 14:58:31
If you wish to foster support, you could ask for it. I know that I personally would gladly do that on any project I was going to distribute. But I agree, having to manually disable the ad print (which forces a console to appear!) is somewhat annoying. Great work though, please keep it up!
# # MyreMylar commented at 2020-09-28 15:15:30
We do ask, fairly regularly in social media places, and there are various pages on getting involved over on the official pygame wiki and a contributing discord channel. Yet still we have yet to finish creating pygame 2, so every little helps.
Honestly, I feel the most important part of the welcome message now is the string of version information printed. Historically the majority (vast majority?) of our users are people beginning their programming journey rather than power users who care about a clean console - and it smooths the path to diagnosing these user's problems when every one of them can swiftly tell us what version of pygame and SDL they have running on their system.
I also feel that the small minority of users who care about the console message are exactly the sort of users who are equipped to add a single line of code to their scripts to disable it.
# # McSinyx commented at 2020-09-28 15:16:03
Note that for projects that wishes to silent the message can use
While it's rare for a library to do this (usually only interactive programs print non-error messages), but it might be a good idea to guard imports of third party libraries from printing warning anyway.
# # MyreMylar commented at 2020-09-28 15:21:09
Or for just pygame:
In case anyone wants a cut-n-paste from googling this issue without following the other links.
# # codenotworking commented at 2021-01-24 21:32:32
The fact it gets installed and used, already means its fostering support. You know, just like all other third-party modules.
Thanks @MyreMylar.
NOTE: "True" has to be a string, not boolean value. Otherwise an error is thrown. At least it did for me on Windows 10.
It would be great if this was a property that can be set, for example
pygame.init(SUPPORT_PROMPT=False)
# # rlamy commented at 2021-05-06 12:58:05
I don't like to complain about the decisions of other open-source projects, but this silly message breaks in a non-obvious way a tool I rely on intermittently.
Frankly, it's rude and unexpected to print stuff on import. Imagine if every library did that!
# # MyreMylar commented at 2021-05-06 19:42:14
As was stated above if you need to disable the support message for your use case then:
Will do it for you. This is documented with the other environment variables here: https://www.pygame.org/docs/ref/pygame.html
The diagnostics in the message are so far still very useful for quickly gathering information and diagnosing problems from one of pygame's main audiences of young people learning programming. They often have trouble describing information like this usefully and having it ready to go at a glance saves lots of man hours of back and forth trying to explain and extract it from them. I suspect it's more likely that we might expand the message to add more platform information at this point than scrap it. I used this message today in fact in one of my classes to quickly figure out an issue in a student's code - every library is different. Pygame's nature as a graphics library, and its long development, also makes it prone to lots of platform and underlying library version specific issues that not all libraries share.
So far it is simply far less work for us to tell the occasional disgruntled 'power user' to use the environment variable for their use case than it is to try and extract platform & version information from thousands of fresh young programmers. If anyone feels strongly about the direction of pygame then the best way to change it is to become involved in the project as a regular contributor and engage with the community - including all those students using pygame as one of their first game programming experiences.
# # Wolf-SO commented at 2021-09-06 08:07:00
The solution suggested repeatedly,
os.environ['PYGAME_HIDE_SUPPORT_PROMPT'] = True
, doesn't work, at least not for me, it leads to the following errorsince environment variables have to be of type
str
which would be satisfied by the following:# # ghost commented at 2021-09-24 18:14:57
Still an issue and still annoying.
# # Kyllingene commented at 2021-09-25 04:07:25
This is a stale issue, and you brought nothing to the table. Let dead dogs lie.
# # guidopetri commented at 2021-09-27 12:06:50
@ maintainers, can we please lock this issue?
The text was updated successfully, but these errors were encountered: