[issue35779] Print friendly version message in REPL

[Eric Snow]

Eric Snow  added the comment:

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. :)

--
components: +Interpreter Core
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35779] Print friendly version message in REPL

[Ma Lin]

Ma Lin  added the comment:

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35779] Print friendly version message in REPL

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> 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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35779] Print friendly version message in REPL

[Eric Snow]

Eric Snow  added the comment:

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/

--
nosy: +eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35779] Print friendly version message in REPL

[Ma Lin]

Ma Lin  added the comment:

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35779] Print friendly version message in REPL

[Steven D'Aprano]

Steven D'Aprano  added the comment:

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:

> 9a3ffc0492git 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.

--
nosy: +steven.daprano

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35779] Print friendly version message in REPL

[Ma Lin]

New submission from Ma Lin :

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.
9a3ffc0492git 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()

--
messages: 334026
nosy: Ma Lin
priority: normal
severity: normal
status: open
title: Print friendly version message in REPL
type: enhancement
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com