The current version message in REPL is too complicate for official release.

Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 

tags/v3.7.2   git tag is superfluous.
9a3ffc0492    git commit id may scare junior users.
23:09:28      quite meaningless.
win32         "I'm using a 64 bit Windows, why call it win32?"

IMO, we can simply print this message for official release:
Python 3.7.2 (64 bit, Dec 23 2018) on Windows

How about this logic?

if version in git_tag and "dirty" not in commit_id:
    print_simplified_message()
else:
    print_current_message()

The version message doesn't look "too complicated" to me. It looks no more complicated as that which Python has always displayed, going back to Python 1.5 (the oldest version I still have access to).

Python 1.5.2 (#1, Aug 27 2012, 09:09:18)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2

Python 2.7.2 (default, May 18 2012, 18:25:10)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux2


You say:

> 9a3ffc0492    git commit id may scare junior users.

I think that's quite patronising towards juniors. Any junior who doesn't know what that means will likely just ignore it. Besides, Python isn't designed solely for junior users, and they will never cease to be junior users if we dumb everything down least it "scare" them.

> 23:09:28      quite meaningless.

Its a time stamp, and it goes with the date. There can easily be two or more commits on a single day, having the time visible is useful.


> win32         "I'm using a 64 bit Windows, why call it win32?"

*shrug* Ask Microsoft.

https://duckduckgo.com/?q=I%27m+using+a+64+bit+Windows%2C+why+call+it+win32



I don't think anything here needs to change. We've been printing the same information going back to 1.5. Giving too much information hasn't been a problem, the usual problem is trying to get beginners to supply *sufficient* information. Having them copy and paste the startup message is useful for diagnosing problems. Don't dumb it down.

It's interesting to see the a Python 1.5.2 from April 1999 :)

Thanks for your opinion, let me explain:

We only print simplified message in official binary release, any Linux/private builds still using the current message. We know enough information about official binary release.

Junior users are people such as students learning programming in middle school, I think git information will confuse them, maybe many of them will never know git knowledges.

In recent versions, there is a "tags/" prepend to git tag, make the line longer. Just concatenating the string provided by git/compiler is a bit ugly IMO.

Python 3.6.1 (v3.6.1:69c0db5, Mar 21 2017, 17:54:52) [MSC v.1900 32 bit (Intel)] on win32
Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)] on win32

Another problem is indicating 32bit or 64bit build, IMHO this is an useful information.
64bit machine did not exist in 1999, but now there are many kinds platforms, desktop, IOT, Raspberry Pi. This seems another topic.

Hi Ma Lin!  Thanks for the suggestion.  We appreciate your interest in making Python better.

It's unclear from your messages what is motivating your request.  You mentioned middle school students, but that didn't sound like your actual motivator.  Knowing what problems the current message has caused will help us identify the appropriate solution (including potentially the one you've suggested).  So would you mind clarifying what would be the concrete value of simplifying the initial version message printed by the REPL?

As Steven noted, there are several valid reasons to keep the message as-is:

* it's pretty much the same as it's always been (this matters because, for better or worse, sometimes people rely on the format)
* the full information can be useful when a user submits a bug report here
* the code that produces that version string is simpler (granted, the maintenance burden wouldn't change much)
* any change introduces churn (though this wouldn't cause much, it's still something)
* "status quo wins a stalemate" [1]

Also note that the REPL version messages (along with `sys.version`) aren't particularly useful for programatically dealing with the Python version.  Here are better options for that:

* python3 --version
* sys.version_info

Finally, I'd strongly recommend that you submit a pull request to go along with this issue.  If we've done a good job then you should find the experience rewarding, even if the PR is rejected.  The change should be fairly small and localized to one place in one file.  Don't forget to add yourself to the Misc/ACKS file. :)  If you'd like some help then check out the "core mentorship" resources. [2]  The mailing list is a great place to start.  We'd love to add you to our growing list of contributors.


[1] https://www.curiousefficiency.org/posts/2011/02/status-quo-wins-stalemate.html
[2] https://www.python.org/dev/core-mentorship/

> We only print simplified message in official binary release, any 
> Linux/private builds still using the current message. We know enough 
> information about official binary release.

Who is "we" in this sentence?

Are you saying that the Python.org binary releases here:

https://www.python.org/downloads/release/python-372/

for example don't print the same information as source releases? I 
don't have either Windows or Mac and so cannot test it for myself.

> Junior users are people such as students learning programming in 
> middle school, I think git information will confuse them, maybe many 
> of them will never know git knowledges.

Why is this important? Surely they won't be tested on their 
understanding of the git tag information printed at startup. They can 
just ignore the information.

If you are really going to push this idea that the information currently 
printed at startup is confusing to beginners, then we can ask educators 
like Raymond Hettinger and others who have been teaching Python for many 
years and see what their experience has been.

But for what it is worth, in 15+ years of asking questions from 
beginners on various mailing lists, I don't believe I have ever seen 
anyone ask about that information. If it happens, it happens rarely.

> Another problem is indicating 32bit or 64bit build, IMHO this is an 
> useful information.

And that information is currently printed at startup.

Hi, thanks for your replies.

To be honest, the reason is I fell it's a bit ugly, this line is very long at REPL startup. And the information is not very clear [1].

I'm not strongly pushing this idea, just raise my feeling, keep it easy. :)

Yes, after this discussion, I suppose simplified message only printed in Windows/Mac official binary releases. Just print at REPL startup, don't change sys.version.

Python 3.7.2 (64 bit, Dec 23 2018) on Windows
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.version
'3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 23:09:28) [MSC v.1916 64 bit (AMD64)]'


[1] How do I determine if my python shell is executing in 32bit or 64bit mode on OS X?
[1] https://stackoverflow.com/questions/1405913/how-do-i-determine-if-my-python-shell-is-executing-in-32bit-or-64bit-mode-on-os

Thanks for clarifying, Ma Lin.  At this point there just isn't enough strong justification for making any change here.  So I'm closing the issue.

Also, making a PR for this likely wouldn't be the best use of your time.  However, if you're interested in contributing to Python there are plenty of interesting problems to solve in open tracker issues.  I'd be glad to help you get started if you're interested. :)