Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #70218 > unrolled thread

Re: Martijn Faassen: The Call of Python 2.8

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Martijn Faassen: The Call of Python 2.8 Chris Angelico <rosuav@gmail.com> - 2014-04-14 23:20 +1000
    Re: Martijn Faassen: The Call of Python 2.8 Marko Rauhamaa <marko@pacujo.net> - 2014-04-14 16:51 +0300
      Re: Martijn Faassen: The Call of Python 2.8 Chris Angelico <rosuav@gmail.com> - 2014-04-15 00:19 +1000
        Re: Martijn Faassen: The Call of Python 2.8 Marko Rauhamaa <marko@pacujo.net> - 2014-04-14 17:40 +0300
          Re: Martijn Faassen: The Call of Python 2.8 Chris Angelico <rosuav@gmail.com> - 2014-04-15 01:01 +1000
      Re: Martijn Faassen: The Call of Python 2.8 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-04-14 15:46 +0100
        Re: Martijn Faassen: The Call of Python 2.8 Pete Forman <petef4+usenet@gmail.com> - 2014-04-14 19:39 +0100
      Re: Martijn Faassen: The Call of Python 2.8 Chris Angelico <rosuav@gmail.com> - 2014-04-15 01:04 +1000
        Re: Martijn Faassen: The Call of Python 2.8 wxjmfauth@gmail.com - 2014-04-14 10:41 -0700
          Re: Martijn Faassen: The Call of Python 2.8 Ian Kelly <ian.g.kelly@gmail.com> - 2014-04-14 12:59 -0600
            Re: Martijn Faassen: The Call of Python 2.8 wxjmfauth@gmail.com - 2014-04-15 01:25 -0700
          Re: Martijn Faassen: The Call of Python 2.8 Ned Batchelder <ned@nedbatchelder.com> - 2014-04-14 15:28 -0400
      Re: Martijn Faassen: The Call of Python 2.8 Terry Reedy <tjreedy@udel.edu> - 2014-04-14 23:54 -0400
        Re: Martijn Faassen: The Call of Python 2.8 Marko Rauhamaa <marko@pacujo.net> - 2014-04-15 08:03 +0300
          Re: Martijn Faassen: The Call of Python 2.8 Terry Reedy <tjreedy@udel.edu> - 2014-04-15 04:32 -0400
          Re: Martijn Faassen: The Call of Python 2.8 Ben Finney <ben+python@benfinney.id.au> - 2014-04-15 21:33 +1000
          Re: Martijn Faassen: The Call of Python 2.8 Albert-Jan Roskam <fomcl@yahoo.com> - 2014-04-15 10:21 -0700
          Re: Martijn Faassen: The Call of Python 2.8 Terry Reedy <tjreedy@udel.edu> - 2014-04-15 15:01 -0400
          Re: Martijn Faassen: The Call of Python 2.8 Terry Reedy <tjreedy@udel.edu> - 2014-04-15 15:29 -0400
          Re: Martijn Faassen: The Call of Python 2.8 Joshua Landau <joshua@landau.ws> - 2014-04-15 22:34 +0100
          Re: Martijn Faassen: The Call of Python 2.8 Ned Batchelder <ned@nedbatchelder.com> - 2014-04-15 18:18 -0400
            Re: Martijn Faassen: The Call of Python 2.8 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-16 01:18 +0000
          Re: Martijn Faassen: The Call of Python 2.8 Andrew Berg <aberg010@my.hennepintech.edu> - 2014-04-15 17:32 -0500
            Re: Martijn Faassen: The Call of Python 2.8 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-16 01:21 +0000
              Re: Martijn Faassen: The Call of Python 2.8 Andrew Berg <aberg010@my.hennepintech.edu> - 2014-04-16 02:32 -0500
                Re: Martijn Faassen: The Call of Python 2.8 Rustom Mody <rustompmody@gmail.com> - 2014-04-16 01:07 -0700
                Re: Martijn Faassen: The Call of Python 2.8 Steven D'Aprano <steve@pearwood.info> - 2014-04-16 08:13 +0000
              Re: Martijn Faassen: The Call of Python 2.8 Chris Angelico <rosuav@gmail.com> - 2014-04-16 18:02 +1000
              Re: Martijn Faassen: The Call of Python 2.8 Andrew Berg <aberg010@my.hennepintech.edu> - 2014-04-16 03:42 -0500
          Re: Martijn Faassen: The Call of Python 2.8 Joshua Landau <joshua@landau.ws> - 2014-04-16 00:11 +0100
          Re: Martijn Faassen: The Call of Python 2.8 Ned Batchelder <ned@nedbatchelder.com> - 2014-04-15 20:39 -0400
          Re: Martijn Faassen: The Call of Python 2.8 Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-04-15 17:42 -0700
          Re: Martijn Faassen: The Call of Python 2.8 Joshua Landau <joshua@landau.ws> - 2014-04-16 03:27 +0100
      Re: Martijn Faassen: The Call of Python 2.8 Ben Finney <ben+python@benfinney.id.au> - 2014-04-15 16:08 +1000
      Re: Martijn Faassen: The Call of Python 2.8 Terry Reedy <tjreedy@udel.edu> - 2014-04-15 04:33 -0400
        Re: Martijn Faassen: The Call of Python 2.8 Steven D'Aprano <steve@pearwood.info> - 2014-04-15 09:41 +0000
      Re: Martijn Faassen: The Call of Python 2.8 Chris Angelico <rosuav@gmail.com> - 2014-04-15 19:05 +1000
      Re: Martijn Faassen: The Call of Python 2.8 Terry Reedy <tjreedy@udel.edu> - 2014-04-15 15:48 -0400
        Re: Martijn Faassen: The Call of Python 2.8 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-04-16 02:52 +0000
          Re: Martijn Faassen: The Call of Python 2.8 Chris Angelico <rosuav@gmail.com> - 2014-04-16 16:22 +1000
            Re: Martijn Faassen: The Call of Python 2.8 wxjmfauth@gmail.com - 2014-04-15 23:30 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#70301

On 4/15/14 5:34 PM, Joshua Landau wrote:
> On 15 April 2014 06:03, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Terry Reedy <tjreedy@udel.edu>:
>>
>>> Any decent system should have 3.4 available now.
>>
>> Really, now? Which system is that?
>
> Arch is on 3.4 *default*.
>
>      $> python
>      Python 3.4.0 (default, Mar 17 2014, 23:20:09)
>      [...]
>

Yeah, that's the wrong way to do it, and they shouldn't have done that. 
  "python" needs to mean Python 2.x for a long time.

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#70310

On Tue, 15 Apr 2014 18:18:16 -0400, Ned Batchelder wrote:

> On 4/15/14 5:34 PM, Joshua Landau wrote:
>> On 15 April 2014 06:03, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> Terry Reedy <tjreedy@udel.edu>:
>>>
>>>> Any decent system should have 3.4 available now.
>>>
>>> Really, now? Which system is that?
>>
>> Arch is on 3.4 *default*.
>>
>>      $> python
>>      Python 3.4.0 (default, Mar 17 2014, 23:20:09) [...]
>>
>>
> Yeah, that's the wrong way to do it, and they shouldn't have done that.
>   "python" needs to mean Python 2.x for a long time.

That's a matter of opinion :-)

But Arch is considered pretty gung-ho in this matter, even by people 
(like me) who want "python" to mean "the latest version" rather than 
"something old and decrepit". I recall jokes back when Arch first moved 
to Python 3 as their system Python, that Arch was the bleeding-edge Linux 
distro for those who found Slackware too tame and unadventurous.

For the avoidance of doubt: Python 2.7 is not "old and decripit". Yet. 
But some day it will be. When that time comes, I want "python" to mean 
Python 3.6 or 3.7 or 4.2, or whatever is the most recent version, not 2.7 
or 1.5.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#70303

On 2014.04.15 17:18, Ned Batchelder wrote:
> Yeah, that's the wrong way to do it, and they shouldn't have done that. 
>   "python" needs to mean Python 2.x for a long time.
Or maybe explicit is better than implicit:

# python
zsh: command not found: python
# which python2.7
/usr/local/bin/python2.7
# which python3.4
/usr/local/bin/python3.4

-- 
CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0

[toc] | [prev] | [next] | [standalone]

#70311

On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote:

> On 2014.04.15 17:18, Ned Batchelder wrote:
>> Yeah, that's the wrong way to do it, and they shouldn't have done that.
>>   "python" needs to mean Python 2.x for a long time.
> Or maybe explicit is better than implicit:
> 
> # python
> zsh: command not found: python
> # which python2.7
> /usr/local/bin/python2.7
> # which python3.4
> /usr/local/bin/python3.4

If you really meant that, you would have typed "/usr/bin/which2.16 
python" (or whatever the location and version of which on your system).




-- 
Steven

[toc] | [prev] | [next] | [standalone]

#70321

On 2014.04.15 20:21, Steven D'Aprano wrote:
> On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote:
> 
>> On 2014.04.15 17:18, Ned Batchelder wrote:
>>> Yeah, that's the wrong way to do it, and they shouldn't have done that.
>>>   "python" needs to mean Python 2.x for a long time.
>> Or maybe explicit is better than implicit:
>> 
>> # python
>> zsh: command not found: python
>> # which python2.7
>> /usr/local/bin/python2.7
>> # which python3.4
>> /usr/local/bin/python3.4
> 
> If you really meant that, you would have typed "/usr/bin/which2.16 
> python" (or whatever the location and version of which on your system).
Are you sure about that?
# which which
which: shell built-in command
Unless I'm forgetting some more explicit way of calling a command built into the shell.

-- 
CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0

[toc] | [prev] | [next] | [standalone]

#70324

On Wednesday, April 16, 2014 1:02:00 PM UTC+5:30, Andrew Berg wrote:
> On 2014.04.15 20:21, Steven D'Aprano wrote:
> 
> > On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote:
> 
> > 
> 
> >> On 2014.04.15 17:18, Ned Batchelder wrote:
> 
> >>> Yeah, that's the wrong way to do it, and they shouldn't have done that.
> 
> >>>   "python" needs to mean Python 2.x for a long time.
> 
> >> Or maybe explicit is better than implicit:
> 
> >> 
> 
> >> # python
> 
> >> zsh: command not found: python
> 
> >> # which python2.7
> 
> >> /usr/local/bin/python2.7
> >> # which python3.4
> >> /usr/local/bin/python3.4

> > If you really meant that, you would have typed "/usr/bin/which2.16 
> > python" (or whatever the location and version of which on your system).
> 
> Are you sure about that?
> # which which
> which: shell built-in command
> Unless I'm forgetting some more explicit way of calling a command built into the shell.

Not out here:

$ which which
/usr/bin/which
$ ls -l /usr/bin/which 
lrwxrwxrwx 1 root root 10 Jul 28  2013 /usr/bin/which -> /bin/which

Though there is no evidence of which-versionitis which is what Steven is implying??

[toc] | [prev] | [next] | [standalone]

#70326

On Wed, 16 Apr 2014 02:32:00 -0500, Andrew Berg wrote:

> On 2014.04.15 20:21, Steven D'Aprano wrote:
>> On Tue, 15 Apr 2014 17:32:57 -0500, Andrew Berg wrote:
>> 
>>> On 2014.04.15 17:18, Ned Batchelder wrote:
>>>> Yeah, that's the wrong way to do it, and they shouldn't have done
>>>> that.
>>>>   "python" needs to mean Python 2.x for a long time.
>>> Or maybe explicit is better than implicit:
>>> 
>>> # python
>>> zsh: command not found: python
>>> # which python2.7
>>> /usr/local/bin/python2.7
>>> # which python3.4
>>> /usr/local/bin/python3.4
>> 
>> If you really meant that, you would have typed "/usr/bin/which2.16
>> python" (or whatever the location and version of which on your system).
> Are you sure about that?
> # which which
> which: shell built-in command
> Unless I'm forgetting some more explicit way of calling a command built
> into the shell.

I've tried it on two different systems:

steve@runes:~$ which which
/usr/bin/which


although I see you are running as root:

steve@runes:~$ su - 
Password: 
root@runes:~# which which
/usr/bin/which


Nope, that makes no difference. In any case, you're missing my point, 
which is not *where* the which binary lives, but the fact that you're 
calling some specific version, located in some specific place (even if 
that place is a virtual place inside the shell) implicitly rather than 
explicitly. Which is usually (but not always!) what we want for an 
interactive shell. Who wants to be typing out explicit paths to versioned 
binaries *all the time*?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#70323

On Wed, Apr 16, 2014 at 5:32 PM, Andrew Berg
<aberg010@my.hennepintech.edu> wrote:
>> If you really meant that, you would have typed "/usr/bin/which2.16
>> python" (or whatever the location and version of which on your system).
> Are you sure about that?
> # which which
> which: shell built-in command
> Unless I'm forgetting some more explicit way of calling a command built into the shell.

Hmm, interesting. That's not the case for me:

rosuav@sikorsky:~$ which which
/usr/bin/which

Debian Wheezy.

ChrisA

[toc] | [prev] | [next] | [standalone]

#70327

On 2014.04.16 03:02, Chris Angelico wrote:
> Hmm, interesting. That's not the case for me:
> 
> rosuav@sikorsky:~$ which which
> /usr/bin/which
That's because bash either does not have a builtin which or it is not enabled by default. I switched to zsh a while ago. I do still, of
course, have a system which, which is at /usr/bin/which, and which is the which that a shell which does not have a builtin which will use.

-- 
CPython 3.4.0 | Windows NT 6.2.9200 / FreeBSD 10.0

[toc] | [prev] | [next] | [standalone]

#70304

On 15 April 2014 23:18, Ned Batchelder <ned@nedbatchelder.com> wrote:
> On 4/15/14 5:34 PM, Joshua Landau wrote:
>> Arch is on 3.4 *default*.
>>
>>      $> python
>>      Python 3.4.0 (default, Mar 17 2014, 23:20:09)
>>      [...]
>>
> Yeah, that's the wrong way to do it, and they shouldn't have done that.
> "python" needs to mean Python 2.x for a long time.

Why?

The only things that break are things outside of the official repos,
and the vast majority of the user repository works flawlessly. If I
get something from the source, I normally run it explicitly ("python
the_thing") and on the very rare occasion it breaks (when it's 2.x and
uses "python" to mean "python2") I can trivially patch or wrap it, and
file a bug report.

The python = python3 choice of Arch is not what takes up maintenance
time, and it's good to prepare developers ahead of time. That's what
rolling release is all about: getting the best and preparing the rest.

[toc] | [prev] | [next] | [standalone]

#70306

On 4/15/14 7:11 PM, Joshua Landau wrote:
> On 15 April 2014 23:18, Ned Batchelder <ned@nedbatchelder.com> wrote:
>> On 4/15/14 5:34 PM, Joshua Landau wrote:
>>> Arch is on 3.4 *default*.
>>>
>>>       $> python
>>>       Python 3.4.0 (default, Mar 17 2014, 23:20:09)
>>>       [...]
>>>
>> Yeah, that's the wrong way to do it, and they shouldn't have done that.
>> "python" needs to mean Python 2.x for a long time.
>
> Why?
>
> The only things that break are things outside of the official repos,
> and the vast majority of the user repository works flawlessly. If I
> get something from the source, I normally run it explicitly ("python
> the_thing") and on the very rare occasion it breaks (when it's 2.x and
> uses "python" to mean "python2") I can trivially patch or wrap it, and
> file a bug report.
>
> The python = python3 choice of Arch is not what takes up maintenance
> time, and it's good to prepare developers ahead of time. That's what
> rolling release is all about: getting the best and preparing the rest.
>

The problem is files that use shebang lines:

     #!/usr/bin/python

or:

     #!/usr/bin/env python

If these are Python 2 files, they now don't work.  Keep in mind, these 
might not be files that you have written, they may have been installed 
as part of another package, or written long ago.

For the official statement on "python" meaning Python 2, and more on 
why, see PEP 394: 'The "python" Command on Unix-Like Systems': 
http://legacy.python.org/dev/peps/pep-0394/

-- 
Ned Batchelder, http://nedbatchelder.com

[toc] | [prev] | [next] | [standalone]

#70307

On Tue, Apr 15, 2014 at 4:11 PM, Joshua Landau <joshua@landau.ws> wrote:
> On 15 April 2014 23:18, Ned Batchelder <ned@nedbatchelder.com> wrote:
>> On 4/15/14 5:34 PM, Joshua Landau wrote:
>>> Arch is on 3.4 *default*.
>>>
>>>      $> python
>>>      Python 3.4.0 (default, Mar 17 2014, 23:20:09)
>>>      [...]
>>>
>> Yeah, that's the wrong way to do it, and they shouldn't have done that.
>> "python" needs to mean Python 2.x for a long time.
>
> Why?
>
> The only things that break are things outside of the official repos,

Yes. Software included in Arch, and programs installed via distutils,
will both work correctly under Arch. However, it breaks any 2.x code
that is expected to run without being installed via distutils and
doesn't use the "python2" executable. Which used to be any 2.x
program, since "python2" originally didn't even exist in many OSes. It
also, at the time of introduction, broke all installed software that
wasn't part of Arch itself.

I have a few problems with what they did. I don't like how Arch
created a situation where it was impossible to support Arch and Debian
at the same time with standalone Python 2.x programs (due to a missing
python2 and differing python in Debian). I don't like how the
migration was not communicated sufficiently clearly to users[*], so
that when they saw weird Python errors, they came to the Python
community instead of to Arch, overwhelming #python (if not other
places) with support requests. (We had to temporarily ban Arch
questions to stop people from asking.)  I don't like how their new and
unusual executable naming scheme forced into existence a PEP [1] to
figure out how to bring Python and Debian into line, and I don't like
how Debian was forced to do extra work to make life easier for Python
2.x developers and resolve problems that only existed because of what
Arch did.

They caused a lot of grief, and for what? As far as I can tell, it's
was a marketing gimmick -- Arch gets to look cool by being "bleeding
edge", and everyone else pays the price.

It's worth stating clearly: there is actually no technical benefit to
changing what the python symlink points to. If we want to do such a
thing, it is for cultural reasons, and there is no urgency to it. It
can be done over an extremely long period of time.

[*] One might also ask why they didn't do a phase where python2 was
python 2.x, python3 was python 3.x, and python was 2.x but also gave a
warning to upgrade your stuff because the meaning of the symlink was
changing. There is no good reason. The stated reason was that warnings
are annoying -- so they broke everything instead of giving warnings. [2]

[1] http://legacy.python.org/dev/peps/pep-0394/
[2] https://mail.python.org/pipermail/python-dev/2010-November/105299.html

-- Devin

[toc] | [prev] | [next] | [standalone]

#70312

On 16 April 2014 01:42, Devin Jeanpierre <jeanpierreda@gmail.com> wrote:
> Yes. Software included in Arch, and programs installed via distutils,
> will both work correctly under Arch. [...]
>
> I don't like how Arch
> created a situation where it was impossible to support Arch and Debian
> at the same time with standalone Python 2.x programs (due to a missing
> python2 and differing python in Debian).

Let the developers aim at Debian and other mainstream distros and Arch
will clean it up for its own use. Isn't that how it normally works?

This did, however, quickly result in "python2" symlinks, which I think
is extremely good in the long run to have ingrained in people's
habits.

>  I don't like how the
> migration was not communicated sufficiently clearly to users[*], so
> that when they saw weird Python errors, they came to the Python
> community instead of to Arch

That's not expected Arch user behaviour ;).

> I don't like how their new and
> unusual executable naming scheme forced into existence a PEP [1] to
> figure out how to bring Python and Debian into line, and I don't like
> how Debian was forced to do extra work to make life easier for Python
> 2.x developers and resolve problems that only existed because of what
> Arch did.

I don't agree entirely. Arch was early, perhaps earlier than
reasonable, but "python2" was going to be needed soon anyway,
especially since it significantly aids adoption of the
version-prepended names.

> It's worth stating clearly: there is actually no technical benefit to
> changing what the python symlink points to. If we want to do such a
> thing, it is for cultural reasons, and there is no urgency to it. It
> can be done over an extremely long period of time.

This is Arch. The fact that it *can* be done over a long period of
time falls far behind the "cultural reasons" in level of importance.

> [*] One might also ask why they didn't do a phase where python2 was
> python 2.x, python3 was python 3.x, and python was 2.x but also gave a
> warning to upgrade your stuff because the meaning of the symlink was
> changing. There is no good reason. The stated reason was that warnings
> are annoying -- so they broke everything instead of giving warnings. [2]
>
> [2] https://mail.python.org/pipermail/python-dev/2010-November/105299.html

Thanks for the read; I found it rather entertaining. Apologies about
the #python grief.

I disagree with you about the warnings. Arch is made to move fast and
this is made abundantly clear:

@https://wiki.archlinux.org/index.php/The_Arch_Way
> This user-centric design necessarily implies a certain "do-it-yourself" approach to using the Arch distribution. Rather than pursuing assistance or requesting a new feature to be implemented by developers, Arch Linux users have a tendency to solve problems themselves and generously share the results with the community and development team – a "do first, then ask" philosophy. This is especially true for user-contributed packages found in the Arch User Repository – the official Arch Linux repository for community-maintained packages.

If people want to run Arch but don't want the Arch way, then there's
not much we can do about it. Arch isn't going to compromise its
demographic because a different demographic is also using it.

[toc] | [prev] | [next] | [standalone]

#70249

Terry Reedy <tjreedy@udel.edu> writes:

> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
> already so old that it is off bugfix maintenance. Any decent system
> should have 3.4 available now.

I think you mean “… should have Python 3.3 available now”, yes?

-- 
 \     “I wish there was a knob on the TV to turn up the intelligence. |
  `\          There's a knob called ‘brightness’ but it doesn't work.” |
_o__)                                             —Eugene P. Gallagher |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#70260

On 4/15/2014 2:08 AM, Ben Finney wrote:
> Terry Reedy <tjreedy@udel.edu> writes:
>
>> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
>> already so old that it is off bugfix maintenance. Any decent system
>> should have 3.4 available now.
>
> I think you mean “… should have Python 3.3 available now”, yes?

??? why would you think that??? My installed 3.4.0 for Windows is dated 
March 16.


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#70267

On Tue, 15 Apr 2014 04:33:24 -0400, Terry Reedy wrote:

> On 4/15/2014 2:08 AM, Ben Finney wrote:
>> Terry Reedy <tjreedy@udel.edu> writes:
>>
>>> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
>>> already so old that it is off bugfix maintenance. Any decent system
>>> should have 3.4 available now.
>>
>> I think you mean “… should have Python 3.3 available now”, yes?
> 
> ??? why would you think that??? My installed 3.4.0 for Windows is dated
> March 16.


Was it provided by Microsoft as part of the OS?

Terry, while enthusiasm for the latest and greatest version of Python is 
a good thing, stability is also a good thing. Not everyone has the luxury 
of being able to jump on the upgrade treadmill and stay on it. If I 
recall correctly, Python 2.6 has just received its last security update 
from Python, but it will continue to receive them from Red Hat for a few 
more years. (Python 2.4 is still receiving security updates from Red Hat, 
and 2.7 will be receiving them until 2024.)

That stability is very valuable to some people -- that's why people use 
(e.g.) Debian, with its promises of multi-year stability, instead of 
Ubuntu, which goes through major version changes three times a week (or 
so sometimes it seems...) That failure to support 3.4 in the OS-provided 
system is not a mistake, it is a feature.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#70263

On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 4/15/2014 2:08 AM, Ben Finney wrote:
>>
>> Terry Reedy <tjreedy@udel.edu> writes:
>>
>>> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
>>> already so old that it is off bugfix maintenance. Any decent system
>>> should have 3.4 available now.
>>
>>
>> I think you mean “… should have Python 3.3 available now”, yes?
>
>
> ??? why would you think that??? My installed 3.4.0 for Windows is dated
> March 16.

Debian's current stable (Wheezy) was released 2013/05/04, and the
latest version release of it (7.4) was 2014/02/08. Both those dates
precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you
don't even get 3.3, presumably because its launch date of 2012/09/29
missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current
testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3.

Stable OSes won't necessarily be jumping onto 3.4 instantly upon
availability. Debian Squeeze (oldstable, still supported) doesn't even
ship 3.2, all you get is 3.1.3. If you want Arch Linux, you know where
to find it :) And of course, that very stability is what makes it easy
to just "apt-get build-dep python3" and spin up one from source,
possibly even a 3.5-with-except-expressions for the purpose of testing
:)

ChrisA

[toc] | [prev] | [next] | [standalone]

#70295

On 4/15/2014 5:05 AM, Chris Angelico wrote:
> On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>> On 4/15/2014 2:08 AM, Ben Finney wrote:
>>>
>>> Terry Reedy <tjreedy@udel.edu> writes:
>>>
>>>> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
>>>> already so old that it is off bugfix maintenance. Any decent system
>>>> should have 3.4 available now.
>>>
>>>
>>> I think you mean “… should have Python 3.3 available now”, yes?
>>
>>
>> ??? why would you think that??? My installed 3.4.0 for Windows is dated
>> March 16.
>
> Debian's current stable (Wheezy) was released 2013/05/04, and the
> latest version release of it (7.4) was 2014/02/08. Both those dates
> precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you
> don't even get 3.3, presumably because its launch date of 2012/09/29
> missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current
> testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3.

There are three things a distribution can do with a new Python version:
1. Push it on people.
2. Allow people who need it to easily get it.
3. Actively hide it and discourage its use.

I happen to think 2) is generally the right answer.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#70314

On Tue, 15 Apr 2014 15:48:06 -0400, Terry Reedy wrote:

> On 4/15/2014 5:05 AM, Chris Angelico wrote:
>> On Tue, Apr 15, 2014 at 6:33 PM, Terry Reedy <tjreedy@udel.edu> wrote:
>>> On 4/15/2014 2:08 AM, Ben Finney wrote:
>>>>
>>>> Terry Reedy <tjreedy@udel.edu> writes:
>>>>
>>>>> The 'mistake' is your OS, whatever it is, not providing 3.3. It is
>>>>> already so old that it is off bugfix maintenance. Any decent system
>>>>> should have 3.4 available now.
>>>>
>>>>
>>>> I think you mean “… should have Python 3.3 available now”, yes?
>>>
>>>
>>> ??? why would you think that??? My installed 3.4.0 for Windows is
>>> dated March 16.
>>
>> Debian's current stable (Wheezy) was released 2013/05/04, and the
>> latest version release of it (7.4) was 2014/02/08. Both those dates
>> precede 2014/03/16, so you don't get 3.4 in Wheezy. (Actually, you
>> don't even get 3.3, presumably because its launch date of 2012/09/29
>> missed the Wheezy feature freeze in mid-2012.) Debian Jessie (current
>> testing) ships 3.3 and 3.4, with the 'python3' package giving you 3.3.
> 
> There are three things a distribution can do with a new Python version:
> 1. Push it on people.
> 2. Allow people who need it to easily get it. 
> 3. Actively hide it and discourage its use.
> 
> I happen to think 2) is generally the right answer.

How would they do #3? Patch all the web browsers to fake a 404 Not Found 
when you go to the Python website and try to download it?

I'm actually asking a serious question. How does a distro "actively hide" 
something publicly available on the Internet? Note that, on Linux (when 
you talk about "distributions", you probably don't mean OS X or Windows) 
all the compiler tools needed to install from source are readily 
available, so anyone who wants to install a Python version not supported 
by their distro can do so. Many people don't wish to install anything 
outside of their distro's supported packages, but that's their choice, 
not the distro imposing anything on them.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#70319

On Wed, Apr 16, 2014 at 12:52 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> I'm actually asking a serious question. How does a distro "actively hide"
> something publicly available on the Internet? Note that, on Linux (when
> you talk about "distributions", you probably don't mean OS X or Windows)
> all the compiler tools needed to install from source are readily
> available, so anyone who wants to install a Python version not supported
> by their distro can do so. Many people don't wish to install anything
> outside of their distro's supported packages, but that's their choice,
> not the distro imposing anything on them.

I'd say it's not so much "actively hide" as just "abandon people to
their own devices". It's all very well to say "well hey, just go and
compile it from source"; this assumes two things:

1) The available source code will compile on your platform
2) The user knows how to compile code.

The first is true of the platforms supported by python.org, but that's
not the OS/distribution helping you to get Python - that's Python
helping you to get Python. The second... that's where things like
"apt-get build-dep" come in, but mainly there's a general
understanding among end users that compiling code is haaaaaaard. Some
cultures have this more strongly than others... sometimes for good
reason. (I had stupid amounts of trouble trying to get a C compiler
going on OS X. A non-programmer, doing the same job, might well give
up, and I wouldn't argue.) Compiling from source without a package
manager fetching all the appropriate libraries means an iterative
process of "compile or build, see what the error is, figure out what's
missing, fetch it, GOTO 10". For me, that's life; that's something
I've done on a number of different systems, and I know lots of the
clues and/or the tools for figuring things out. For many
non-programmers, though, if there's no binary package, they won't use
the software.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web