RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20130724/140e87e3/attachment.html below:

<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 24, 2013 at 5:12 AM, Bohuslav Kabrda <span dir="ltr"><<a href="mailto:bkabrda@redhat.com" target="_blank">bkabrda@redhat.com</a>></span> wrote:<br>

in recent days, there has been a discussion on fedora-devel (see thread [1]) about moving to Python 3 as a default.<br>
I'd really love to hear opinions on the matter from the upstream, mainly regarding these two points (that are not that clearly defined in my original proposal and have been formed during the discussion):<br>
<br>
- Should we point /usr/bin/python to Python 3 when we make the move?<br>
I know that pep 394 [2] deals with this and it says that /usr/bin/python may refer to Python 3 on some bleeding edge distributions - supposedly, this was added to the pep because of what Arch Linux did, not the other way round.<br>

As the pep says, the recommendation of pointing /usr/bin/python to Python 2 may be changed after the Python 3 ecosystem is sufficiently mature. I'm wondering if there are any more specific criteria - list of big projects migrated/ported or something like that - or will this be judged by what I'd call "overall spirit" in Python community (I hope you know what I mean by this)?<br>

In Fedora, we have two concerns that clash in this decision - being "First" (e.g. actively promote and use new technologies and also suggest them to our users) vs. not breaking user expectations. So we figured it'd be a good idea to ask upstream to get more opinions on this.<br>

<br>

- What should user get after using "yum install python"?<br>
There are basically few ways of coping with this:<br>
1) Just keep doing what we do, eventually far in the future drop "python" package and never provide it again (= go on only with python3/python4/... while having "yum install python" do nothing).<br>
2) Do what is in 1), but when "python" is dropped, use virtual provide (*) "python" for python3 package, so that "yum install python" installs python3.<br>
3), 4) Rename python to python2 and {don't add, add} virtual provide "python" in the same way that is in 1), 2)<br>
5) Rename python to python2 and python3 to python at one point. This makes sense to me from the traditional "one version in distro + possibly compat package shipping the old" approach in Linux, but some say that Python 2 and Python 3 are just different languages [3] and this should never be done.<br>

All of the approaches have their pros and cons, but generally it is all about what user should get when he tries to install python - either nothing or python2 for now and python3 in future - and how we as a distro cope with that on the technical side (and when we should actually do the switch).<br>

Just as a sidenote, IMO the package that gets installed as "python" (if any) should point to /usr/bin/python, which makes consider these two points very closely coupled.<br></blockquote><div><br></div><div>A similar discussion broke out when Arch Linux switched python to point to python3. This led toÂ <a href="http://www.python.org/dev/peps/pep-0394/">http://www.python.org/dev/peps/pep-0394/</a>Â which says have python2/python3, and have python point at whatever makes the most sense to you based on your users and version uptake (option 3/4). The key, though, is adding python2 and getting your code to use that binaryÂ Â specifically so that shifting the default name is more of a convenience than something which might break existing code not ready for the switch.</div>

</div></div></div>

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4