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

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

Noob in Python. Problem with fairly simple test case

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

Contents

  Noob in Python. Problem with fairly simple test case "Jason P." <suscricions@gmail.com> - 2015-07-15 04:44 -0700
    Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-15 22:11 +1000
      Re: Noob in Python. Problem with fairly simple test case Larry Hudson <orgnut@yahoo.com> - 2015-07-15 20:01 -0700
        Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-16 13:11 +1000
          Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-15 20:33 -0700
            Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-16 13:44 +1000
              Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-16 13:03 -0700
                Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-17 06:11 +1000
                  Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-16 13:30 -0700
                    Re: Noob in Python. Problem with fairly simple test case Emile van Sebille <emile@fenx.com> - 2015-07-16 14:27 -0700
                    Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-17 09:24 +1000
                      Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-16 17:30 -0700
                        Re: Noob in Python. Problem with fairly simple test case Steven D'Aprano <steve@pearwood.info> - 2015-07-17 12:44 +1000
                          Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-17 13:01 +1000
                            Re: Noob in Python. Problem with fairly simple test case Steven D'Aprano <steve@pearwood.info> - 2015-07-17 16:47 +1000
                              Re: Noob in Python. Problem with fairly simple test case wxjmfauth@gmail.com - 2015-07-17 02:15 -0700
                              Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-17 20:57 +1000
                          Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-16 21:15 -0700
                            Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-17 15:16 +1000
                            Re: Noob in Python. Problem with fairly simple test case Steven D'Aprano <steve@pearwood.info> - 2015-07-17 16:38 +1000
                              Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-17 10:57 -0700
                                Re: Noob in Python. Problem with fairly simple test case Laura Creighton <lac@openend.se> - 2015-07-17 22:38 +0200
                                  Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-18 14:12 -0700
                                Re: Noob in Python. Problem with fairly simple test case Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-07-17 23:03 +0100
                            Re: Noob in Python. Problem with fairly simple test case Terry Reedy <tjreedy@udel.edu> - 2015-07-17 18:45 -0400
                              Re: Noob in Python. Problem with fairly simple test case wxjmfauth@gmail.com - 2015-07-18 00:30 -0700
                              Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-18 16:18 -0700
                                Re: Noob in Python. Problem with fairly simple test case Laura Creighton <lac@openend.se> - 2015-07-19 11:09 +0200
                                  Re: Noob in Python. Problem with fairly simple test case Rick Johnson <rantingrickjohnson@gmail.com> - 2015-07-19 10:25 -0700
                                    Re: Noob in Python. Problem with fairly simple test case MRAB <python@mrabarnett.plus.com> - 2015-07-19 18:45 +0100
                                    Re: Noob in Python. Problem with fairly simple test case Laura Creighton <lac@openend.se> - 2015-07-19 19:50 +0200
                                    Off-topic: Europe [was Re: Noob in Python. Problem with fairly simple test case] Steven D'Aprano <steve@pearwood.info> - 2015-07-20 12:30 +1000
                            Re: Noob in Python. Problem with fairly simple test case Emile van Sebille <emile@fenx.com> - 2015-07-17 16:15 -0700
                          Re: Noob in Python. Problem with fairly simple test case Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-07-17 08:26 -0400
          Re: Noob in Python. Problem with fairly simple test case Larry Hudson <orgnut@yahoo.com> - 2015-07-16 20:49 -0700
      Re: Noob in Python. Problem with fairly simple test case "Jason P." <suscricions@gmail.com> - 2015-07-21 10:38 -0700
        Re: Noob in Python. Problem with fairly simple test case Chris Angelico <rosuav@gmail.com> - 2015-07-22 03:48 +1000

Page 1 of 2  [1] 2  Next page →

#93868 — Noob in Python. Problem with fairly simple test case

Hi all!

I'm working in a little Python exercise with testing since the beginning. So far I'm with my first end to end test (not even finished yet) trying to:

1) Launch a development web server linked to a demo app that just returns 'Hello World!'

2) Make a GET request successfully

I can't understand very well what's happening. It seems that the main thread gets blocked listening to the web server. My intent was to spawn another process for the server independent of the test. Obviously I'm doing something wrong. I've made several guesses commenting pieces of code (tearDown method for example) but I didn't manage to solve the problem(s).

I'm running the test through PyCharm. Python version = 3.4.3



Here it's the code:


test_forecast_end_to_end.py
===========================

import unittest
from tests.end_to_end.forecastserver import ForecastServer
import src.forecast.webservice as webservice
import requests


class TestForecastEndToEnd(unittest.TestCase):

    def setUp(self):
        # Start the forecast server
        self.server = ForecastServer()
        self.server.start(webservice.app)

    def tearDown(self):
        # Stop the forecast server
        self.server.stop()

    def test_webservice_receives_a_request(self):
        response = requests.get('http://localhost:8000')
        print(response.text)


if __name__ == '__main__':
    unittest.main()



forecastserver.py
=================

from wsgiref.simple_server import make_server
import multiprocessing


class ForecastServer:

    def __init__(self):
        self._httpd_process = None

    def start(self, webservice):
        if not self._httpd_process:
            httpd = make_server('localhost', 8000, webservice)
            self._httpd_process = multiprocessing.Process(
                target=httpd.serve_forever)
            self._httpd_process.start()

    def stop(self):
        if self._httpd_process:
            self._httpd_process.join()
            self._httpd_process.terminate()

        del self._httpd_process



webservice.py
=============

def app(environ, start_response):
    status = '200 OK'
    headers = [('Content-type', 'text/plain')]
    start_response(status, headers)

    return ['Hello World!']

[toc] | [next] | [standalone]

#93870

On Wed, Jul 15, 2015 at 9:44 PM, Jason P. <suscricions@gmail.com> wrote:
> I can't understand very well what's happening. It seems that the main thread gets blocked listening to the web server. My intent was to spawn another process for the server independent of the test. Obviously I'm doing something wrong. I've made several guesses commenting pieces of code (tearDown method for example) but I didn't manage to solve the problem(s).
>

When you find yourself making guesses to try to figure out what's
going on, here are two general tips:

1) Cut out as many pieces as you can. Test one small thing at a time.
2) If In Doubt, Print It Out! Stick print() calls into the code at key
places, displaying the values of parameters or the results of
intermediate calculations - or just saying "Hi, I'm still here and I'm
running!".

For #1, I would recommend first just trying to get the web service
going. Can you connect (using an external program) on port 8000 and
receive a text/plain HTTP response saying "Hello World!"? Never mind
about the test for the moment.

And for #2, judicious placement of console output will help you figure
out things you're not sure about. For instance, you're suspecting that
the main thread is getting blocked handling the web server. Easy way
to check:

    def setUp(self):
        # Start the forecast server
        self.server = ForecastServer()
        self.server.start(webservice.app)

Just before you construct the server, print something out. After
you've constructed it but before you call start(), print something
out. And after starting it, print something out. Then run the program.
If you see the first line and no other, then it's blocking during the
construction. Other deductions I'm sure you can figure out.

One small point: Probe even things that you think are trivial. In the
above example, I cannot see any reason why constructing
ForecastServer() could possibly block, because its init does nothing
but set a flag. But you can get surprised by things sometimes - maybe
the problem is actually that you're not running the code you think you
are, but there's some other ForecastServer kicking in, and it's
synchronous rather than subprocess-based.

End-to-end testing is all very well, but when something goes wrong,
the key is to break the program down into smaller parts. Otherwise,
all you have is "it doesn't work", which is one of the most useless
error reports ever. If someone comes to python-list saying "it doesn't
work", we'll be asking him/her to give a lot more details; if your
aunt asks you for help printing out a document because "it doesn't
work", you'll probably have to go over and watch her attempt it; and
it's the same with your test cases - you make them tell you more
details.

Hope that helps! The techniques I'm offering are completely
problem-independent, and even language-independent. IIDPIO debugging
works in anything that gives you a console, which is pretty much
everything - maybe it won't be print() but logging.debug(), but the
same technique works.

ChrisA

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

#93890

On 07/15/2015 05:11 AM, Chris Angelico wrote:
> On Wed, Jul 15, 2015 at 9:44 PM, Jason P. <suscricions@gmail.com> wrote:
>> I can't understand very well what's happening. It seems that the main thread gets blocked listening to the web server. My intent was to spawn another process for the server independent of the test. Obviously I'm doing something wrong. I've made several guesses commenting pieces of code (tearDown method for example) but I didn't manage to solve the problem(s).
>>
>
> When you find yourself making guesses to try to figure out what's
> going on, here are two general tips:
>
> 1) Cut out as many pieces as you can. Test one small thing at a time.
> 2) If In Doubt, Print It Out! Stick print() calls into the code at key
> places, displaying the values of parameters or the results of
> intermediate calculations - or just saying "Hi, I'm still here and I'm
> running!".
>
In addition to using print(), in some places I like using input() instead, as in:
     input('x={}, y={} --> '.format(x, y))
Then the program stops at that point so you can study it.
To continue just press <Enter>, or Ctrl-C to abort.

      -=- Larry -=-

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

#93891

On Thu, Jul 16, 2015 at 1:01 PM, Larry Hudson via Python-list
<python-list@python.org> wrote:
> On 07/15/2015 05:11 AM, Chris Angelico wrote:
>>
>> On Wed, Jul 15, 2015 at 9:44 PM, Jason P. <suscricions@gmail.com> wrote:
>>>
>>> I can't understand very well what's happening. It seems that the main
>>> thread gets blocked listening to the web server. My intent was to spawn
>>> another process for the server independent of the test. Obviously I'm doing
>>> something wrong. I've made several guesses commenting pieces of code
>>> (tearDown method for example) but I didn't manage to solve the problem(s).
>>>
>>
>> When you find yourself making guesses to try to figure out what's
>> going on, here are two general tips:
>>
>> 1) Cut out as many pieces as you can. Test one small thing at a time.
>> 2) If In Doubt, Print It Out! Stick print() calls into the code at key
>> places, displaying the values of parameters or the results of
>> intermediate calculations - or just saying "Hi, I'm still here and I'm
>> running!".
>>
> In addition to using print(), in some places I like using input() instead,
> as in:
>     input('x={}, y={} --> '.format(x, y))
> Then the program stops at that point so you can study it.
> To continue just press <Enter>, or Ctrl-C to abort.

That's a neat trick, as long as you actually do have a console. IIDPIO
is extremely general (works across languages, across frameworks (eg a
web server), etc), but these kinds of extensions are pretty handy when
they make sense.

ChrisA

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

#93892

On Wednesday, July 15, 2015 at 10:11:43 PM UTC-5, Chris Angelico wrote:
> That's a neat trick, as long as you actually do have a console.

Well if you don't have a console, another option is to use the 
dialogs of the "batteries included GUI" named Tkinter. 

from tkMessageBox import showinfo # Syntax == Python < 3.0

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

#93893

On Thu, Jul 16, 2015 at 1:33 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Wednesday, July 15, 2015 at 10:11:43 PM UTC-5, Chris Angelico wrote:
>> That's a neat trick, as long as you actually do have a console.
>
> Well if you don't have a console, another option is to use the
> dialogs of the "batteries included GUI" named Tkinter.
>
> from tkMessageBox import showinfo # Syntax == Python < 3.0

A GUI is another form of console. Not all programs are run in a
situation where this makes sense. Also, please don't post Py2-only
code when the OP clearly stated that 3.4.3 was being used...

ChrisA

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

#93960

On Wednesday, July 15, 2015 at 10:45:12 PM UTC-5, Chris Angelico wrote:
> A GUI is another form of console. 

And a blindingly obvious association is another form of
patronizing! What's next, are you going to tell us that a
Volvo is a street-legal Scandinavian version of an armored
personal carrier? Or perhaps you'll *WOW* us with your
knowledge that a penis is merely another form of editable
sausage? OBVIOUSLY YOUR "SAUSAGE" WAS CANNED IN VIENNA!

> Not all programs are run in a situation where this makes
> sense.

Really? I thought every situation was exactly the same. How
foolish am i? Oh please enlighten us with more of your wisdom!

> Also, please don't post Py2-only code when the OP clearly
> stated that 3.4.3 was being used...

Chris i hate to burst you're little naive "vajayjay bubble",
but a vast majority of the Python community is currently
using, and will for many years continue using, Python<3.0.
Just because they don't participate here => in your private
self-aggrandizing blog <= does not mean they don't exist!

See, unlike you, we didn't start writing Python code a few
years ago. No, we skipped the "pike detour" through the
intellectual ghetto, and we've been writing Python code for
many years. And we have millions of lines of code in our
repos!

And we're not about to risk "exception hell" just so we can
get a few "meager" new features and a "kewel" new print
function. Besides, most of the new features have long ago been
patched by creative programmers or are available via the: 

  from __future__ import KEWEL_NEW_FEATURE

I have a statement about what you can do with your print
function, but executing that statement might result in this
fine group throwing an IntegrityError. Therefor, i'll leave 
the "interpretation" of my statement as an academic exercise 
for all the Usenet eyeball-parsers.

sys.exit(0)

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

#93961

On Fri, Jul 17, 2015 at 6:03 AM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> but a vast majority of the Python community is currently
> using, and will for many years continue using, Python<3.0.

Where's the latest survey results? I think the numbers don't agree
with you any more.

ChrisA

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

#93964

On Thursday, July 16, 2015 at 3:11:56 PM UTC-5, Chris Angelico wrote:
> Where's the latest survey results? I think the numbers don't agree
> with you any more.

What? You think the handful of regulars on this list in any
way shape or form somehow represents the multitude of *REAL*
python programmers who work day in and day out in the
trenches? ON THE FRONT LINES! 

Heck you're more naive than the BDFL: who gets a woody
simply from gawking at that atrociously inaccurate TIOBI
index! 

 Oooh. Oooh. Python is moving up the list!

Yeah, it's not just Python that's moving up. Besides, 
everybody knows his bots are out there manipulating the 
numbers!

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

#93965

On Thursday, July 16, 2015 at 3:11:56 PM UTC-5, Chris Angelico wrote:

> Where's the latest survey results? I think the numbers don't agree
> with you any more.

Not that there's a source for that info, but a quick survey of yahoo 
results certainly continues to show more v2 activity.

--anytime--
python v3 -- 1430000
python v2 -- 1890000

--Past month--
python v3 -- 386000
python v2 -- 554000

Emile

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

#93969

On Fri, Jul 17, 2015 at 7:27 AM, Emile van Sebille <emile@fenx.com> wrote:
> On Thursday, July 16, 2015 at 3:11:56 PM UTC-5, Chris Angelico wrote:
>
>> Where's the latest survey results? I think the numbers don't agree
>> with you any more.
>
>
> Not that there's a source for that info, but a quick survey of yahoo results
> certainly continues to show more v2 activity.
>
> --anytime--
> python v3 -- 1430000
> python v2 -- 1890000
>
> --Past month--
> python v3 -- 386000
> python v2 -- 554000

Yes, and this is skewed somewhat by the Linux distros that ship Python
2 as the system Python, which leads to automatic use of Py2 in various
places. Even if you don't correct for that, these figures show *at
most* 30-50% more Py2 usage than Py3, which hardly justifies Rick's
statement that the "vast majority" of Python is 2.x. Different metrics
differ in the exact figures, but none show a 99:1 ratio or even 90:10
for any recent stats. The most skewed I can find puts Py2 at about
90%, of which a significant slab is 2.6, and 3.4 didn't exist yet:

https://alexgaynor.net/2014/jan/03/pypi-download-statistics/

(There are some 3.4 downloads in the stats, but they come from beta
users; when that blog post was written, 3.4 final was still several
months away.)

And the post makes several caveats about repeated downloads from eg
continuous integration systems, which naturally will tend to be skewed
heavily toward the old stable version. No, the "vast majority" of
Python is no longer on a single version.

ChrisA

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

#93974

On Thursday, July 16, 2015 at 6:24:21 PM UTC-5, Chris Angelico wrote:

Any attempt to translate downloads into *REAL* usage
statistics is doomed to be unreliable. Chris, you're smarter
than this!

(1) for instance: Python2.x coders have been around long
enough that they don't need to download as much from PyPi
anymore. Whereas, Python3.x coders are more recent, therfor
they will be downloading the majority of packages these
days.

(2) Also. Old and stable code bases do not change as much as
new unstable code bases tend to do. Therfor, less Python2.x
downloads

(3) The numbers are falsified even more by 3.0 packages that
are downloaded, but never actually used. Maybe the package
was not what the downloaded expected it to be. I have
downloaded many packages from PyPi and never used the
majority of them.

> 
> Even if you don't correct for that, these figures show *at
> most* 30-50% more Py2 usage than Py3, which hardly
> justifies Rick's statement that the "vast majority" of
> Python is 2.x.
> 

I think I've dispelled the validity of your assertion and
the weakness inherent in your mental heuristic. As my
logical reasoning demonstrates, your percentages of 30%-50%
are, at best, on the *LOW* end of the real percentages of
Python2.x usage.

And i'm not talking about downloads. I'm talking about
*REAL* code out in the wild. I talking about real
applications out in the wild, or living on hard drives doing
*REAL* work. That's the *REAL* litmus test of Python!

Not some false download statistics that can easily be
tainted by a large number of 2.x coders downloading and
"playing" with 3.0 source and packages, but never releasing
or even creating anything substantial. 

Where is the substantial amount of Python3000 applications,
code, and libraries? Sure you can point to PyPi, as it does
contain 3.0 compatible code, but that code is sitting around
doing nothing?

But more importantly than *WHERE* -> *WHAT* are they doing?

Are they making peoples lives better? Are they solving
problems? Or are they just toys written to satisfy some
childish need to play, before getting bored and moving on to
real life projects?

The fact is, the *REAL* code that is doing *REAL* work that
is solving *REAL* problems, is doing it in Python2.x That's
a fact Chris. And your smoke and mirror parlor tricks are
not going to change that one bit.

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

#93977

It amuses me that this discussion started because the OP stated explicitly
that he uses Python 3, and Rick gave an answer for Python 2. Rather than
accept his mistake, Rick's defence is that practically nobody uses Python
3. (Presumably he means "apart from the guy who actually asked the
question".)

More comments below:


On Fri, 17 Jul 2015 10:30 am, Ranting Rick wrote:

> On Thursday, July 16, 2015 at 6:24:21 PM UTC-5, Chris Angelico wrote:
> 
> Any attempt to translate downloads into *REAL* usage
> statistics is doomed to be unreliable. Chris, you're smarter
> than this!
> 
> (1) for instance: Python2.x coders have been around long
> enough that they don't need to download as much from PyPi
> anymore. Whereas, Python3.x coders are more recent, therfor
> they will be downloading the majority of packages these
> days.

Translation: "It's only old dinosaurs that use Python 2! Newcomers to the
language are moving straight to Python 3!".


> (2) Also. Old and stable code bases do not change as much as
> new unstable code bases tend to do. Therfor, less Python2.x
> downloads

Translation: "Python 2 code is abandoned and no longer being actively
maintained. If you want code that's actually being worked on, Python 3 is
the place to go."


> (3) The numbers are falsified even more by 3.0 packages that
> are downloaded, but never actually used. Maybe the package
> was not what the downloaded expected it to be. I have
> downloaded many packages from PyPi and never used the
> majority of them.

Translation: "I don't use many libraries outside of what's in the standard
library."


I don't necessarily agree with *any* of these things, except for the initial
comment that it's difficult to tell exactly how many people are using any
specific version of Python. That at least is true. But:

- I think it is ridiculous to suggest that just because somebody has been
using Python for many years, they no longer need to download packages from
PyPI.

- While it's true that old stable code doesn't change, most heavily used
code is under active development for security updates, bug fixes, and new
features. This is *particularly* true now that Python 3 is in the picture.
The great majority of non-abandoned packages on PyPI have been, or are in
the process of being, updated to support Python 3.

- It's a dishonest argument to suggest that people download Python 3
packages but never use them, without acknowledging that the same applies to
Python 2 packages. By default, pip installs Python 2 packages, so if
anything the rate of "downloaded but not used" errors will be slightly
higher for Python 2 than Python 3. (It's easy for somebody to accidentally
download an unwanted Python 2 version of a package, but hard to download an
unwanted Python 3 version.)


>> Even if you don't correct for that, these figures show *at
>> most* 30-50% more Py2 usage than Py3, which hardly
>> justifies Rick's statement that the "vast majority" of
>> Python is 2.x.
>> 
> 
> I think I've dispelled the validity of your assertion and
> the weakness inherent in your mental heuristic. As my
> logical reasoning demonstrates, your percentages of 30%-50%
> are, at best, on the *LOW* end of the real percentages of
> Python2.x usage.

I believe Rick has misunderstood Chris' comment. Chris is not saying that
30-50% of Python users are using Python 2. He's saying that there are
30-50% *more* Python 2 users than Python 3, that is, for each Python 3 user
there are 1.3 to 1.5 Python 2 users, i.e. about 40% Python 3 versus 60%
Python 2.

I think that undercounts two sorts of users:

- those who are behind corporate or government firewalls;

- and those using only packages available via their Linux distro's package
management (yum, apt-get, etc)

neither of whom will be represented well by PyPI downloads, and both of
those will be mostly using Python 2. In other words, I think Chris is
overcounting Python 3 users.

My sense is that:

- A lot of newcomers to Python are starting with Python 3; quite a few
schools and colleges which teach Python now start with Python 3. From the
evidence I've seen on the tutor mailing list, I'd estimate that newcomers
are probably 40% Python 3.

- Established Python users of the sort who spend a lot of time talking about
Python on the Internet (e.g. here, on Reddit, Stackoverflow, blogging) tend
to be relatively early adopters of Python 3. Reddit, for example, is
extremely (and sometimes obnoxiously so) pro-Python 3. My estimate is that
there's probably about 60% Python 3 usage.

- Government and corporate users tend to be the opposite of early adaptors,
more like late or never adaptors. The majority of them won't upgrade to 3
until the last possible minute. Some will never upgrade -- there are still
people using Python 2.3 and even 1.5 who have no intention of upgrading to
2.7, let alone 3.x. My guess -- and this really is a plucked-from-thin-air
guess -- is that probably 5% or less are using Python 3. I think that this
group of users are the only ones where Rick's "vast majority" is plausible.

- Scientists are heavy users of Python, and the majority of them will still
be using Python 2. Although both numpy and scipy support Python 3, and so
does IPython, scientists tend to be almost as conservative as government
and corporate users. (They often *are* government and corporate users.) My
guestimate is that there's probably about 15% Python 3 take-up.

My take from all this is that overall, Python 3 take-up is probably around
10% of all Python users, but it's the most influential 10%: newbies
learning Python 3 at school, the people chatting about Python on the
Internet, writing blog posts and answering questions on Stackoverflow.
Furthermore, there's probably another 30% who *want* to use Python 3 but
cannot due to company policy. In my day job, I fall into that category: the
company I work for use Python as their main language for our flagship
application, and by policy we're stuck with using the default Python on
Debian jessie, which is 2.6. The numbers of people actively hostile to
Python 3 is probably less than 10%.

The take-up rate of Python 3 is about where we would expect after less than
seven years: 

- the majority of popular third-party libraries and frameworks now support
Python 3;

- one or two Linux distros have Python 3 as their system Python;

- most of the big distros (Red Hat, Fedora, Centos, Debian, Ubuntu) are well
into their preparation to do the same;

- educators are well into the move to Python 3;

- and popular awareness of Python 3 is high and mostly positive.



-- 
Steven

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

#93981

On Fri, Jul 17, 2015 at 12:44 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> My take from all this is that overall, Python 3 take-up is probably around
> 10% of all Python users...

Really? That low? Wow. I guess 90% could count as Rick's declared
"vast majority", although that term does imply more like 99%.

> Furthermore, there's probably another 30% who *want* to use Python 3 but
> cannot due to company policy. In my day job, I fall into that category: the
> company I work for use Python as their main language for our flagship
> application, and by policy we're stuck with using the default Python on
> Debian jessie, which is 2.6.

Jessie's default should be 2.7, at least. Wheezy shipped 2.7, too;
it's only Squeeze (now out of support) that didn't ship any 2.7.x
Python. Are you sure you can't at least upgrade to 2.7?

But yes, that's still not 3.x.

ChrisA

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

#93994

On Fri, 17 Jul 2015 01:01 pm, Chris Angelico wrote:

> On Fri, Jul 17, 2015 at 12:44 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> My take from all this is that overall, Python 3 take-up is probably
>> around 10% of all Python users...
> 
> Really? That low? Wow. 

Well, that's based on a guess that for every Python programmer you see
talking on the Internet, on Stackoverflow, Usenet, etc. there are probably
ten or so who are invisible to us. They work a nominally 9 to 5 government
or corporate job programming in Python, are forbidden to install packages
which aren't approved by IT, and don't even have access to Stackoverflow
let alone have time to chew the fat here. Those folks, I expect, are almost
all using Python 2.6 or 2.7, with a small minority on even older versions.

Some small percentage of them will still be using Python 2 in 20 years time,
just as there are a small minority of people still using Python 1.5 today.


> Jessie's default should be 2.7, at least. Wheezy shipped 2.7, too;
> it's only Squeeze (now out of support) that didn't ship any 2.7.x
> Python. Are you sure you can't at least upgrade to 2.7?

I'm not sure, I'm not actively involved in that specific project. All I know
is that the guys are always complaining about Jessie, and that they're
using 2.6.



-- 
Steven

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

#93999

- Unfortunately Python 3 just becomes a disaster.
- Unusable for serious work.
- Still a very nice toy.

jmf

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

#94003

On Fri, Jul 17, 2015 at 4:47 PM, Steven D'Aprano <steve@pearwood.info> wrote:
>> Jessie's default should be 2.7, at least. Wheezy shipped 2.7, too;
>> it's only Squeeze (now out of support) that didn't ship any 2.7.x
>> Python. Are you sure you can't at least upgrade to 2.7?
>
> I'm not sure, I'm not actively involved in that specific project. All I know
> is that the guys are always complaining about Jessie, and that they're
> using 2.6.

Huh. Then maybe it's the other way: Jessie no longer ships or supports
2.6, so if 2.7 breaks the code, then so will Jessie. But I'm looking
over the 2.7 What's New page, and it honestly doesn't jump out at me
screaming "Your code will break!". Strange.

Anyway, the specifics don't matter. What matters is that there *are*
people who are using the system-provided Python, and that (so far)
that's Py2 for the majority of Linux distros. But that's definitely
changing; Ubuntu and Debian are both aiming toward a state of "ship
Python 3 by default, but if you want 2.7, you'll have to download it",
which implies that all system scripts will be ported to 3.x. Once that
happens, I expect that all Debian-derived distros will follow pretty
quickly (it's easy to transition if someone else has already done the
vast majority of the work, by which I clearly mean about 87.4%), and
non-Debian distros can probably take advantage of the prior work too,
to some extent. That'll shift the balance on Linux from "mostly Py2"
to "mostly Py3", and that'll have knock-on effects on Windows and Mac
OS too, as third-party script developers will find it advisable [1] to
write their code to match the predominantly available version.

> My guess is, the rate of Python 3 adoption is going to hit the tipping point
> in 2 or 3 years, after which time it will be *very* rapid.

Yep, I'd agree with that estimate. Debian Stretch (9) may or may not
switch; I'd be very surprised if Debian Buster (10) didn't have Py3 by
default.

ChrisA

[1] The question is, what did the archbishop find?

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

#93985

On Thursday, July 16, 2015 at 9:44:56 PM UTC-5, Steven D'Aprano wrote:
> [...] My take from all this is that overall, Python 3
> take-up is probably > around 10% of all Python users,

All that rambling just to agree with me? My educated guess
is a minimum of 75% still using Python2.x. But i'll take
your 90% because it makes my argument stronger! O:-D

> but it's the most influential 10%: newbies learning Python
> 3 at school, the people chatting about Python on the
> Internet, writing blog posts and answering questions on
> Stackoverflow. Furthermore, there's probably another 30%
> who *want* to use Python 3 but cannot due to company
> policy. In my day job, I fall into that category: the
> company I work for use Python as their main language for
> our flagship application, and by policy we're stuck with
> using the default Python on Debian jessie, which is 2.6.
> The numbers of people actively hostile to Python 3 is
> probably less than 10%.

Well i'm not "actively hostile" to py3 by any means, i just
can't risk the upgrade at this time. Perhaps in another five
years or so i might change my mind. But then, in another
five years, something more interesting might come along and
sweep me off my feet. Who knows, I'm a sucker for romance.

> The take-up rate of Python 3 is about where we would
> expect after less than seven years:

Well, that's one way of coping with it. I know a lot of
folks worked hard to get Python3 up and running, but they
need to realize that these sort of transitions take time.
Heck, there is always the possibility that Python3 never
gets any real traction. Until it's usage reaches 50%, it's
only spinning tires in the mud, digging a deeper hole.

Not to mention the elephant in the room: We have been moving
towards mobile and cloud ubiquity, and this trend is not
going to stop. If Python wants to survive it had better
start adapting, and adapting fast. If not, it shall become
just another forgotten language relegated to obscurity
within the dark corners of academia.

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

#93990

On Fri, Jul 17, 2015 at 2:15 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Thursday, July 16, 2015 at 9:44:56 PM UTC-5, Steven D'Aprano wrote:
>> [...] My take from all this is that overall, Python 3
>> take-up is probably > around 10% of all Python users,
>
> All that rambling just to agree with me? My educated guess
> is a minimum of 75% still using Python2.x. But i'll take
> your 90% because it makes my argument stronger! O:-D

You said "vast majority". That's not 75:25, which is just a 3:1 ratio.

> Well, that's one way of coping with it. I know a lot of
> folks worked hard to get Python3 up and running, but they
> need to realize that these sort of transitions take time.
> Heck, there is always the possibility that Python3 never
> gets any real traction. Until it's usage reaches 50%, it's
> only spinning tires in the mud, digging a deeper hole.

Given how easily the two coexist, I would say that demanding 50%
before giving Py3 any respect at all is a bit presumptuous. Py3 has
already gained very real traction; it just hasn't achieved a majority
of usage.

> Not to mention the elephant in the room: We have been moving
> towards mobile and cloud ubiquity, and this trend is not
> going to stop. If Python wants to survive it had better
> start adapting, and adapting fast. If not, it shall become
> just another forgotten language relegated to obscurity
> within the dark corners of academia.

Mobile is just how people access things. Usually there has to be a
server on the back end. "Cloud" also implies some sort of server. What
languages are people using on servers? Python is right up there among
them. The basic notion of client-server infrastructure has been around
for three parts of forever, and it isn't going anywhere.

Thank you for your FUD. Allow me to offer my preferred alternative.

https://www.youtube.com/watch?v=6e1hZGDaqIw

ChrisA

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

#93993

On Fri, 17 Jul 2015 02:15 pm, Rick Johnson wrote:

> On Thursday, July 16, 2015 at 9:44:56 PM UTC-5, Steven D'Aprano wrote:
>> [...] My take from all this is that overall, Python 3
>> take-up is probably > around 10% of all Python users,
> 
> All that rambling just to agree with me? My educated guess
> is a minimum of 75% still using Python2.x. But i'll take
> your 90% because it makes my argument stronger! O:-D

75% or 90% is not a "vast majority". Vast majority implies more than 99%.

But regardless of the precise meaning of "vast", if you want to dismiss one
in four people (25%) or one in ten (10%) as inconsequential, then you've
got some serious issues.


[...]
> Well i'm not "actively hostile" to py3 by any means, i just
> can't risk the upgrade at this time.

You can't "risk" the upgrade?

What precisely are you afraid of?


>> The take-up rate of Python 3 is about where we would
>> expect after less than seven years:
> 
> Well, that's one way of coping with it. I know a lot of
> folks worked hard to get Python3 up and running, but they
> need to realize that these sort of transitions take time.

Rick, you're being patronising.

Before even a single line of code was written for Python 3, Guido and the
core developers knew that there would be a long migration path from 2 to 3.
Hence the parallel versions, and the long transition plan:

* Python 2.6 and Python 3.0 came out more or less together, and 2.6 was
explicitly designed as a transitional version with a number of Python 3
features available via __future___ imports;

* Python 2.7 has an extended maintenance period; instead of the usual 2-3
years, 2.7 will be maintained for 10 years (until 2020);

* there will also be at least three more years of commercial third-party
maintenance available from companies like Red Hat.

The core developers don't need to be told that "these sort of transitions
take time". They predicted almost from the beginning that it would take 10
years for the transition. They didn't commit to a long period of parallel
versions because they *like* having twice as much work to do.


> Heck, there is always the possibility that Python3 never
> gets any real traction. Until it's usage reaches 50%, it's
> only spinning tires in the mud, digging a deeper hole.

That's nonsense. Spinning tires implies no forward motion. Python 3 usage is
*certainly* moving forward: we've gone from the situation in 2008 of nobody
using it, to the current situation where there's lots of activity around
it: students learning on Python 3, books about it, the avant-garde and
early adopters have already moved to Python 3, and the majority of
libraries also support Python 3.

The chances of that forward motion coming to a stop are very slim. The work
being done on async and concurrency for Python 3.5 is getting lots of
people excited, and Red Hat and Debian have committed to migrating to
Python 3. Where they go, Centos, Fedora, Mint and (probably) Ubuntu are
sure to follow, and quite quickly too.

My guess is, the rate of Python 3 adoption is going to hit the tipping point
in 2 or 3 years, after which time it will be *very* rapid.


> Not to mention the elephant in the room: We have been moving
> towards mobile and cloud ubiquity, and this trend is not
> going to stop. If Python wants to survive it had better
> start adapting, and adapting fast. If not, it shall become
> just another forgotten language relegated to obscurity
> within the dark corners of academia.

Yeah, right. Like academic computer scientists use Python.

Whatever way you look at it, Python is one of the top 10 programming
languages. It's at no risk of becoming forgotten any time soon.

http://import-that.dreamwidth.org/1388.html




-- 
Steven

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web