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

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

Python 3 lack of support for fcgi/wsgi.

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

Contents

  Python 3 lack of support for fcgi/wsgi. John Nagle <nagle@animats.com> - 2015-03-29 11:57 -0700
    Re: Python 3 lack of support for fcgi/wsgi. Andrew Berg <aberg010@my.hennepintech.edu> - 2015-03-29 14:06 -0500
    Re: Python 3 lack of support for fcgi/wsgi. Ben Finney <ben+python@benfinney.id.au> - 2015-03-30 06:11 +1100
      Re: Python 3 lack of support for fcgi/wsgi. John Nagle <nagle@animats.com> - 2015-03-29 15:37 -0700
        Re: Python 3 lack of support for fcgi/wsgi. Ben Finney <ben+python@benfinney.id.au> - 2015-03-30 09:58 +1100
          Re: Python 3 lack of support for fcgi/wsgi. Paul Rubin <no.email@nospam.invalid> - 2015-03-29 18:03 -0700
            Re: Python 3 lack of support for fcgi/wsgi. Ben Finney <ben+python@benfinney.id.au> - 2015-03-30 12:22 +1100
              Re: Python 3 lack of support for fcgi/wsgi. Paul Rubin <no.email@nospam.invalid> - 2015-03-29 19:16 -0700
                Re: Python 3 lack of support for fcgi/wsgi. Ben Finney <ben+python@benfinney.id.au> - 2015-03-30 13:30 +1100
                  Re: Python 3 lack of support for fcgi/wsgi. Paul Rubin <no.email@nospam.invalid> - 2015-03-29 19:51 -0700
                    Re: Python 3 lack of support for fcgi/wsgi. Chris Angelico <rosuav@gmail.com> - 2015-03-30 14:06 +1100
                      Re: Python 3 lack of support for fcgi/wsgi. Rustom Mody <rustompmody@gmail.com> - 2015-03-29 20:20 -0700
                        Re: Python 3 lack of support for fcgi/wsgi. Paul Rubin <no.email@nospam.invalid> - 2015-03-29 21:35 -0700
                          Re: Python 3 lack of support for fcgi/wsgi. Chris Angelico <rosuav@gmail.com> - 2015-03-30 15:47 +1100
                            Re: Python 3 lack of support for fcgi/wsgi. Denis McMahon <denismfmcmahon@gmail.com> - 2015-03-30 18:15 +0000
                          Re: Python 3 lack of support for fcgi/wsgi. Rustom Mody <rustompmody@gmail.com> - 2015-03-29 22:03 -0700
                    Re: Python 3 lack of support for fcgi/wsgi. Ben Finney <ben+python@benfinney.id.au> - 2015-03-30 14:22 +1100
            Re: Python 3 lack of support for fcgi/wsgi. John Nagle <nagle@animats.com> - 2015-03-29 19:11 -0700
              Re: Python 3 lack of support for fcgi/wsgi. Ben Finney <ben+python@benfinney.id.au> - 2015-03-30 13:28 +1100
              Re: Python 3 lack of support for fcgi/wsgi. John Nagle <nagle@animats.com> - 2015-03-30 13:07 -0700
                Re: Python 3 lack of support for fcgi/wsgi. Terry Reedy <tjreedy@udel.edu> - 2015-03-30 19:02 -0400
                Re: Python 3 lack of support for fcgi/wsgi. Ben Finney <ben+python@benfinney.id.au> - 2015-03-31 10:30 +1100
            Re: Python 3 lack of support for fcgi/wsgi. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-30 11:29 +0100
        Re: Python 3 lack of support for fcgi/wsgi. Michael Torrie <torriem@gmail.com> - 2015-03-29 21:30 -0600
        Re: Python 3 lack of support for fcgi/wsgi. Carl Meyer <carl@oddbird.net> - 2015-03-29 21:50 -0600
        Re: Python 3 lack of support for fcgi/wsgi. INADA Naoki <songofacandy@gmail.com> - 2015-03-30 13:45 +0900
    Re: Python 3 lack of support for fcgi/wsgi. Marko Rauhamaa <marko@pacujo.net> - 2015-03-29 22:42 +0300
    Re: Python 3 lack of support for fcgi/wsgi. Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-03-30 08:40 +1100
      Re: Python 3 lack of support for fcgi/wsgi. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-03-29 23:04 +0100
    Re: Python 3 lack of support for fcgi/wsgi. Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2015-03-30 00:56 +0000
    Re: Python 3 lack of support for fcgi/wsgi. Denis McMahon <denismfmcmahon@gmail.com> - 2015-03-30 17:21 +0000

Page 1 of 2  [1] 2  Next page →

#88276 — Python 3 lack of support for fcgi/wsgi.

The Python 2 module "fcgi" is gone in Python 3.

The Python 3 documentation at

https://docs.python.org/3/howto/webservers.html

recommends "flup" and links here:

https://pypi.python.org/pypi/flup/1.0

That hasn't been updated since 2007, and the SVN repository linked there
is gone.  The recommended version is abandoned. pip3
tries to install version 1.0.2, from 2009.  That's here:
https://pypi.python.org/pypi/flup/1.0.2 That version is supported
only for Python 2.5 and 2.6.

There's a later version on Github:

https://github.com/Pyha/flup-py3.3

But that's not what "pip3" is installing.

I get the feeling, again, that nobody actually uses this stuff.

"pip3" seems perfectly happy to install modules that don't work with
Python 3.  Try "pip3 install dnspython", for example.  You need
"dnspython3", but pip3 doesn't know that.

There's "wsgiref", which looks more promising, but has a different
interface.  That's not what the Python documentation recommends as
the first choice, but it's a standard module.

I keep thinking I'm almost done with Python 3 hell, but then I
get screwed by Python 3 again.

			John Nagle

[toc] | [next] | [standalone]

#88277

On 2015.03.29 13:57, John Nagle wrote:
> There's "wsgiref", which looks more promising, but has a different
> interface.  That's not what the Python documentation recommends as
> the first choice, but it's a standard module.
Oh?

> These days, FastCGI is never used directly. Just like mod_python, it is only used for the deployment of WSGI applications.
> ...
> The Web Server Gateway Interface, or WSGI for short, is defined in PEP 333 and is currently the best way to do Python web programming.

It seems to me that FastCGI isn't well supported in the Python world because
WSGI is by far the recommended choice.

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

#88278

John Nagle <nagle@animats.com> writes:

> The Python 3 documentation at
> https://docs.python.org/3/howto/webservers.html
>
> recommends "flup"

I disagree. In a section where it describes FastCGI, it presents a tiny
example as a way to test the packages installed. The example happens to
use ‘flup’.

That's quite different from a recommendation.

> I get the feeling, again, that nobody actually uses this stuff.
> […]
> I keep thinking I'm almost done with Python 3 hell, but then I
> get screwed by Python 3 again.

You have found yet another poorly-maintained package which is not at all
the responsibility of Python 3.

Why are you discussing it as though Python 3 is at fault? What do you
expect to change *about Python 3* that would address the perceived
problem? Whose responsibility is it to do that?

-- 
 \           “Oh, I love your magazine. My favorite section is ‘How To |
  `\          Increase Your Word Power’. That thing is really, really, |
_o__)                          really... good.” —Homer, _The Simpsons_ |
Ben Finney

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

#88291

On 3/29/2015 1:19 PM, John Nagle wrote:
> On 3/29/2015 12:11 PM, Ben Finney wrote:
>> John Nagle <nagle@animats.com> writes:
>>
>>> The Python 3 documentation at
>>> https://docs.python.org/3/howto/webservers.html
>>>
>>> recommends "flup"
>>
>> I disagree. In a section where it describes FastCGI, it presents a tiny
>> example as a way to test the packages installed. The example happens to
>> use ‘flup’.
>>
>> That's quite different from a recommendation.
>>
>>> I get the feeling, again, that nobody actually uses this stuff.
> 
> So do others. See "http://www.slideshare.net/mitsuhiko/wsgi-on-python-3"
> 
> "A talk about the current state of WSGI on Python 3. Warning:
> depressing. But it does not have to stay that way"
> 
> "wsgiref on Python 3 is just broken."
> 
> "Python 3 that is supposed to make unicode easier is causing a lot more
> problems than unicode environments on Python 2"
> 
> "The Python 3 stdlib is currently incredible broken but because there
> are so few users, these bugs stay under the radar."
> 
> That was written in 2010.  Most of that stuff is still broken.
> Here's his detailed critique:
> 
> http://lucumr.pocoo.org/2010/5/25/wsgi-on-python-3/
> 
>> You have found yet another poorly-maintained package which is not at all
>> the responsibility of Python 3.
>> Why are you discussing it as though Python 3 is at fault?
> 
>    That's a denial problem.  Uncritical fanboys are part of the problem,
> not part of the solution.
> 
>    Practical problems: the version of "flup" on PyPi is so out of date
> as to be useless.  The original author abandoned the software.  There
> are at least six forks of "flup" on Github:
> 
> https://github.com/Pyha/flup-py3.3
> https://github.com/Janno/flup-py3.3
> https://github.com/pquentin/flup-py3
> https://github.com/SmartReceipt/flup-server
> https://github.com/dnephin/TreeOrg/tree/master/app-root/flup
> https://github.com/noxan/flup
> 
> The first three look reasonably promising; the last three look
> abandoned.  But why are there so many, and what are the
> differences between the first three?   Probably nobody
> was able to fix all the Python 3 related problems documented by
> Ronacher in 2010.  None of the versions have much usage.  Nobody
> thought their version was good enough to push it to Pypi.
> 
> All those people had to struggle to try to get a basic capability for
> web development using Python to work. To use WSGI with Python 3, you
> need to do a lot of work.  Or stay with Python 2.
> 
> Python 3 still isn't ready for prime time.
> 
> 				John Nagle
> 

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

#88294

John Nagle <nagle@animats.com> writes:
(for some reason quoting himself extensively without further comment)

> On 3/29/2015 1:19 PM, John Nagle wrote:
> > On 3/29/2015 12:11 PM, Ben Finney wrote:
> >> John Nagle <nagle@animats.com> writes:
> >>> The Python 3 documentation at
> >>> https://docs.python.org/3/howto/webservers.html
> >>>
> >>> recommends "flup"
> >>
> >> I disagree. In a section where it describes FastCGI, it presents a tiny
> >> example as a way to test the packages installed. The example happens to
> >> use ‘flup’.
> >>
> >> That's quite different from a recommendation.

You don't respond to that. So I take it that you won't be claiming any
more that the documentation “recommends” use of ‘flup’?

> >> You have found yet another poorly-maintained package which is not
> >> at all the responsibility of Python 3.
> >> Why are you discussing it as though Python 3 is at fault?
> > 
> >    That's a denial problem. Uncritical fanboys are part of the
> > problem, not part of the solution.

To be critical entails rejecting an assertion presented without
supporting evidence.

You have provided none for your assertion that an unmaintained
third-party library is somehow a special failure of Python 3.

You removed relevant critical questions without responding to them. Let
me continue to ask these critical questions, in hope of getting a
pertinent response this time:

Why are you discussing it as though Python 3 is at fault? What do you
expect to change *about Python 3* that would address the perceived
problem? Whose responsibility is it to do that?

In the absence of good answers to those questions, the proper critical
response would be to dismiss your unsupported claims.

-- 
 \     “Guaranteed to work throughout its useful life.” —packaging for |
  `\                                          clockwork toy, Hong Kong |
_o__)                                                                  |
Ben Finney

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

#88298

Ben Finney <ben+python@benfinney.id.au> writes:
> Why are you discussing it as though Python 3 is at fault?  What do you
> expect to change *about Python 3* that would address the perceived
> problem? Whose responsibility is it to do that?

Those questions seem unfair to me.  Nagle posted an experience report
about a real-world project to migrate a Python 2 codebase to Python 3.
He reported hitting more snags than some of us might expect purely from
the Python 3 propaganda ("oh, just run the 2to3 utility and it does
everything for you").  The report presented info worth considering for
anyone thinking of doing a 2-to-3 migration of their own, or maybe even
choosing between 2 and 3 for a new project.  I find reports like that to
be valuable whether or not they suggest fixes for the snags.

Meanwhile here's a very well informed post about headaches with Python
3's treatment of Unicode.  I had always thought Python 3's main benefit
was to fix the headaches of Python 2's somewhat accidental treatment of
Unicode.  But it looks like Python 3 introduces its own Unicode headaches.

http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/

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

#88300

Paul Rubin <no.email@nospam.invalid> writes:

> Ben Finney <ben+python@benfinney.id.au> writes:
> > Why are you discussing it as though Python 3 is at fault?  What do you
> > expect to change *about Python 3* that would address the perceived
> > problem? Whose responsibility is it to do that?
>
> Those questions seem unfair to me. Nagle posted an experience report
> about a real-world project to migrate a Python 2 codebase to Python 3.

He presented it explicitly in support of the claim that he is “screwed
by Python 3”:

    I keep thinking I'm almost done with Python 3 hell, but then I
    get screwed by Python 3 again.

The story, though, gives no support that this is specially Python 3's
fault. I am asking questions to get John Nagle to explain how Python 3
in particular has caused this problem.

> He reported hitting more snags than some of us might expect purely
> from the Python 3 propaganda ("oh, just run the 2to3 utility and it
> does everything for you").

Propaganda?

Are you referring to the official guidelines for migrating from Python 2
to Python 3? The official guide at
<URL:https://docs.python.org/3/howto/pyporting.html> doesn't support
that assertion.

The ‘2to3’ program is presented as a tool to assist. I don't know of
anything official saying “it does everything for you”. Even when it was
first introduced it was only ever presented as a *start* to the porting
effort.

Or are you referring, by “propaganda”, to some unofficial line that
contradicts the official statements of the Python developers?

If someone follows unofficial advice directly contradicting the advice
explicitly given in the Python 3 porting guide, and then feels they “get
screwed by” following that advice, that sounds more like uncritical
flailing.

> The report presented info worth considering for anyone thinking of
> doing a 2-to-3 migration of their own, or maybe even choosing between
> 2 and 3 for a new project. I find reports like that to be valuable
> whether or not they suggest fixes for the snags.

I agree. It points to the need for improvement in areas where
third-party libraries are still lacking.

Which doesn't address the assertion that this is somehow a special
responsibility of “Python 3”, which I asked critical questions about.
Can we expect those claims, still unsupported, to cease?

-- 
 \       “Facts are meaningless. You could use facts to prove anything |
  `\                that's even remotely true!” —Homer, _The Simpsons_ |
_o__)                                                                  |
Ben Finney

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

#88304

Ben Finney <ben+python@benfinney.id.au> writes:
> Which doesn't address the assertion that this is somehow a special
> responsibility of “Python 3”, which I asked critical questions about.

"Python 3" in those sorts of contexts refers to the whole ecosystem
including the 3rd party libs.  I don't know that I'd say that the
language or ecosystem is "responsible".  It's just there, with its good
and bad points, and people who choose to engage with it find themselves
engaging with those points further into the weeds than they might have
expected.

One of the attractions of Python 2 has traditionally been the existence
of a solid library codebase to build on.  John is telling us that the
Python 3 experience still has dark alleys.

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

#88306

Paul Rubin <no.email@nospam.invalid> writes:

> I don't know that I'd say that the language or ecosystem is
> "responsible".

Then you're not in a position to defend the claim. I'm addressing my
critical inquiry to the person who made the claim that they “get screwed
by Python 3”.

-- 
 \      “Fox News gives you both sides of every story: the President's |
  `\  side and the Vice President's side.” —Steven Colbert, 2006-04-29 |
_o__)                                                                  |
Ben Finney

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

#88307

Ben Finney <ben+python@benfinney.id.au> writes:
> Then you're not in a position to defend the claim. I'm addressing my
> critical inquiry to the person who made the claim that they “get screwed
> by Python 3”.

I'd say that the screw was expecting the migration to be easier than it
actually was.  This might result from there not being sufficiently
revealing info out there.  And that shortage might come from too much
stifling of dissent from Python 3 dogma by Python 3 proponents and
defenders.  In that way, the proponents created or fostered unrealistic
expectations for users.  You asked for concrete suggestions how to fix
that.  One way is take reports like John's seriously and receive them
with thanks, instead of attacking the messenger.

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

#88308

On Mon, Mar 30, 2015 at 1:51 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> One way is take reports like John's seriously and receive them
> with thanks, instead of attacking the messenger.

If a messenger wants to be thanked, he should start by not attacking
the recipients. Respect goes both ways. Make your post with a hostile
attitude of "Python 3 is the cause of all my problems", and you'll
find hostility coming back at you.

One of my sisters keeps on doing this to me. Not with Python, but with
computers generally. She complains that computers never work properly
for her, and she's hostile to *the machine* even before she starts
doing anything. Well, no wonder the computer gets angry with you, and
refuses to work! Of course, the moment I come along, the computer sits
up and takes notice, because he respects my authority (as the network
admin for the house, I'm in command of all computers, to at least some
extent - and they know that), but she still complains loudly. It does
tend to make the assistance somewhat more caustic in delivery.

ChrisA

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

#88309

On Monday, March 30, 2015 at 8:37:13 AM UTC+5:30, Chris Angelico wrote:
> On Mon, Mar 30, 2015 at 1:51 PM, Paul Rubin  wrote:
> > One way is take reports like John's seriously and receive them
> > with thanks, instead of attacking the messenger.
> 
> If a messenger wants to be thanked, he should start by not attacking
> the recipients. Respect goes both ways. Make your post with a hostile
> attitude of "Python 3 is the cause of all my problems", and you'll
> find hostility coming back at you.

John : Messenger
Paul : ??

Paul is asking for John (et al) to be thanked
[And +1 from me on that]

On a more serious note you can (and IMHO should) orthogonalize:
1. John I dont appreciate your tone
2. John thank your for the bug-report

> 
> One of my sisters keeps on doing this to me. Not with Python, but with
> computers generally. She complains that computers never work properly
> for her, and she's hostile to *the machine* even before she starts
> doing anything. Well, no wonder the computer gets angry with you, and
> refuses to work! Of course, the moment I come along, the computer sits
> up and takes notice, because he respects my authority (as the network
> admin for the house, I'm in command of all computers, to at least some
> extent - and they know that), but she still complains loudly. It does
> tend to make the assistance somewhat more caustic in delivery.

heh dont I know!

I send my mom a file and occasionally she complains: "Why do you spell your
file-names funny?" Wedontwritesentenceslikethisdowe?
More often she just quietly corrects this stupid boy's spelling.
[Unix is one habit that dies hard...]

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

#88313

Rustom Mody <rustompmody@gmail.com> writes:
> On a more serious note you can (and IMHO should) orthogonalize:
> 1. John I dont appreciate your tone
> 2. John thank your for the bug-report

Fair enough, but I'd split #2 into

2a. John, thank you for the bug report describing specific problems we
can fix, bringing Python 3 another few little steps closer to maturity.

2b. John, thank you for describing your experience and making the
community's picture of the current overall state of Python 3 more
accurate.  It was apparently a bit too rosy before, and we should avoid
fostering unrealistic expectations in the future.  

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

#88315

On Mon, Mar 30, 2015 at 3:35 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> 2b. John, thank you for describing your experience and making the
> community's picture of the current overall state of Python 3 more
> accurate.  It was apparently a bit too rosy before, and we should avoid
> fostering unrealistic expectations in the future.

Not without some evidence of where this "a bit too rosy" picture came
from. So far, we've had rebuttals of vaguenesses, which pretty much
amount to FUD.

ChrisA

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

#88338

On Mon, 30 Mar 2015 15:47:23 +1100, Chris Angelico wrote:

> On Mon, Mar 30, 2015 at 3:35 PM, Paul Rubin <no.email@nospam.invalid>
> wrote:
>> 2b. John, thank you for describing your experience and making the
>> community's picture of the current overall state of Python 3 more
>> accurate.  It was apparently a bit too rosy before, and we should avoid
>> fostering unrealistic expectations in the future.

> Not without some evidence of where this "a bit too rosy" picture came
> from. So far, we've had rebuttals of vaguenesses, which pretty much
> amount to FUD.

I went and looked earlier - the HOWTO on the Python 3 documentation site 
<https://docs.python.org/3.4/howto/webservers.html> appears to be almost 
a straight copy of the HOWTO from the Python 2 documentation. <https://
docs.python.org/2/howto/webservers.html>

As such, it should either be updated to ensure that any external 
libraries and modules are Python 3 compatible, have a suitable caveat 
inserted, or be removed.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#88316

On Monday, March 30, 2015 at 10:05:37 AM UTC+5:30, Paul Rubin wrote:
> 2b. John, thank you for describing your experience and making the
> community's picture of the current overall state of Python 3 more
> accurate.  It was apparently a bit too rosy before, and we should avoid
> fostering unrealistic expectations in the future.

Now who's being unrealistic? <wink>

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

#88310

Chris Angelico <rosuav@gmail.com> writes:

> On Mon, Mar 30, 2015 at 1:51 PM, Paul Rubin <no.email@nospam.invalid> wrote:
> > One way is take reports like John's seriously and receive them
> > with thanks, instead of attacking the messenger.

Please note that, where John Nagle has made supportible criticisms, I
have thanked him for them. They are indeed useful to be aware of.

It's also important to note, of course, that those specific criticisms
are already well known and are being publicly addressed.

It is his claims that there are un-addressed problems which I was
focussing on, trying to get specific information.

> If a messenger wants to be thanked, he should start by not attacking
> the recipients. Respect goes both ways. Make your post with a hostile
> attitude of "Python 3 is the cause of all my problems", and you'll
> find hostility coming back at you.

If my responses seemed hostile, that was not my intent. I asked John
Nagle (and have still not seen in this forum his answers to) questions
asking for support of his claims.

My request for specific supporting information – that is, this critical
inquiry – was met not with answers, but with allegations of a “denial
problem” and “uncritical fanboys”.

So I've continued to be especially critical in this thread, since John
Nagle expressed opposition to uncritical acceptance of claims.

Critical inquiry is often mistaken for hostility. If that happened here,
I apologise. But so far it's all been a distraction, and I still have
nothing from Nagle supporting his assertions


Your broader point remains true: readers are safe in dismissing claims
about being “screwed by Python 3” or “Python 3 not ready for prime time”
unsupported by specific evidence.

Frustration is understandable. Expressing anger is regrettable,
especially if it is misdirected. Persisting in blaming “Python 3” when
the only reported problems are clearly not particular to Python 3, is
disingenuous and harmful.

-- 
 \         “If history and science have taught us anything, it is that |
  `\     passion and desire are not the same as truth.” —E. O. Wilson, |
_o__)                                              _Consilience_, 1998 |
Ben Finney

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

#88303

On 3/29/2015 6:03 PM, Paul Rubin wrote:
> Those questions seem unfair to me.  Nagle posted an experience report
> about a real-world project to migrate a Python 2 codebase to Python 3.
> He reported hitting more snags than some of us might expect purely from
> the Python 3 propaganda ("oh, just run the 2to3 utility and it does
> everything for you").  The report presented info worth considering for
> anyone thinking of doing a 2-to-3 migration of their own, or maybe even
> choosing between 2 and 3 for a new project.  I find reports like that to
> be valuable whether or not they suggest fixes for the snags.

    Thanks.

    Meanwhile, I've found two more variants on "flup"

	https://pypi.python.org/pypi/flipflop
	https://pypi.python.org/pypi/flup6

All of these are descended from the original "flup" code base.

PyPi also has

	fcgi-python (Python 2.6, Windows only.)
	fcgiapp (circa 2005)	
	superfcgi (circa 2009)

Those can probably be ignored.

One of the "flup" variants may do the job, but since there
are so many, and no single version has won out, testing is
necessary.  "flipflop" looks promising, simply because the
author took all the code out that you don't need on a server.

CPAN, the Perl module archive, has some curation and testing.
PyPi lacks that, which is how we end up with situations like
this, where there are 11 ways to do something, most of which
don't work.

Incidentally, in my last report, I reported problems with BS4,
PyMySQL, and Pickle. I now have workarounds for all of those,
but not fixes. The bug reports I listed last time contain the
workaround code.

				John Nagle

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

#88305

John Nagle <nagle@animats.com> writes:

> CPAN, the Perl module archive, has some curation and testing. PyPi
> lacks that, which is how we end up with situations like this, where
> there are 11 ways to do something, most of which don't work.

That is a valid criticism of PyPI, and more broadly of the Python
distribution ecosystem. (Uncritical fanatics would deny that, but I'm
not one.)

You're quite right that Python's third-party library distribution
landscape lags behind that for some other platforms. There has been a
great deal of progress in recent years, but contrariwise the progress is
in fixing a legacy backlog of terrible third-party distribution support.

    <URL:http://python-notes.curiousefficiency.org/en/latest/pep_ideas/core_packaging_api.html#incremental-plans-to-improve-python-packaging>

This is true for code targetting Python 2 as much, if not more so, as of
code targetting Python 3. So I'll thank you to direct the frustration
where it belongs: at the state of distribution support, which is not a
special Python 3 problem but is common to all versions of Python.

> Incidentally, in my last report, I reported problems with BS4,
> PyMySQL, and Pickle. I now have workarounds for all of those, but not
> fixes. The bug reports I listed last time contain the workaround code.

Thanks for your persistence. It is good to know progress can be made by
focussing on problems where they are.

-- 
 \      “I am too firm in my consciousness of the marvelous to be ever |
  `\       fascinated by the mere supernatural …” —Joseph Conrad, _The |
_o__)                                                     Shadow-Line_ |
Ben Finney

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

#88343

On 3/29/2015 7:11 PM, John Nagle wrote:
>     Meanwhile, I've found two more variants on "flup"
> 
> 	https://pypi.python.org/pypi/flipflop
> 	https://pypi.python.org/pypi/flup6
> 
> All of these are descended from the original "flup" code base.
> 
> PyPi also has
> 
> 	fcgi-python (Python 2.6, Windows only.)
> 	fcgiapp (circa 2005)	
> 	superfcgi (circa 2009)
> 
> Those can probably be ignored.
> 
> One of the "flup" variants may do the job, but since there
> are so many, and no single version has won out, testing is
> necessary.  "flipflop" looks promising, simply because the
> author took all the code out that you don't need on a server.

   "flipflop" works well with Apache.  It does log
"WARNING: SCRIPT_NAME does not match REQUEST_URI" for any URL
renamed using mod_rename with Apache, but other than that,
it seems to do the job.  The warning message was copied
over from "flup", and there's an issue for it for one of the
"flup" variants.  So I referenced that issue for "flipflop":

https://github.com/Kozea/flipflop/issues

That's part of the problem of having all those forks - now
each bug has to be fixed in each fork.

After all this, the production system is now running entirely
on Python 3.

				John Nagle

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web