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

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

Understanding Python from a PHP coder's perspective

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

Contents

  Understanding Python from a PHP coder's perspective villascape@gmail.com - 2015-12-07 13:07 -0800
    Re: Understanding Python from a PHP coder's perspective villascape@gmail.com - 2015-12-07 13:21 -0800
      Re: Understanding Python from a PHP coder's perspective Chris Angelico <rosuav@gmail.com> - 2015-12-08 09:00 +1100
        Re: Understanding Python from a PHP coder's perspective villascape@gmail.com - 2015-12-07 14:27 -0800
          Re: Understanding Python from a PHP coder's perspective Chris Angelico <rosuav@gmail.com> - 2015-12-08 10:09 +1100
            Re: Understanding Python from a PHP coder's perspective villascape@gmail.com - 2015-12-07 17:00 -0800
              Re: Understanding Python from a PHP coder's perspective Chris Angelico <rosuav@gmail.com> - 2015-12-08 14:26 +1100
          Re: Understanding Python from a PHP coder's perspective Ian Kelly <ian.g.kelly@gmail.com> - 2015-12-07 16:10 -0700
          Re: Understanding Python from a PHP coder's perspective Cameron Simpson <cs@zip.com.au> - 2015-12-08 10:07 +1100
          Re: Understanding Python from a PHP coder's perspective Tim Chase <python.list@tim.thechases.com> - 2015-12-07 21:11 -0600
          Re: Understanding Python from a PHP coder's perspective Chris Angelico <rosuav@gmail.com> - 2015-12-08 14:47 +1100
    Re: Understanding Python from a PHP coder's perspective Cameron Simpson <cs@zip.com.au> - 2015-12-08 08:33 +1100
    Re: Understanding Python from a PHP coder's perspective Ian Kelly <ian.g.kelly@gmail.com> - 2015-12-07 14:37 -0700
    Re: Understanding Python from a PHP coder's perspective Chris Angelico <rosuav@gmail.com> - 2015-12-08 08:40 +1100
    Re: Understanding Python from a PHP coder's perspective Terry Reedy <tjreedy@udel.edu> - 2015-12-07 16:53 -0500
    Re: Understanding Python from a PHP coder's perspective Ian Kelly <ian.g.kelly@gmail.com> - 2015-12-07 14:59 -0700
    Re: Understanding Python from a PHP coder's perspective Chris Angelico <rosuav@gmail.com> - 2015-12-08 09:03 +1100
    Re: Understanding Python from a PHP coder's perspective Tim Chase <python.list@tim.thechases.com> - 2015-12-07 16:28 -0600
    Re: Understanding Python from a PHP coder's perspective villascape@gmail.com - 2015-12-07 20:11 -0800
    Re: Understanding Python from a PHP coder's perspective Peter Otten <__peter__@web.de> - 2015-12-08 10:24 +0100
    Re: Understanding Python from a PHP coder's perspective Chris Angelico <rosuav@gmail.com> - 2015-12-08 20:40 +1100

Page 1 of 2  [1] 2  Next page →

#100105 — Understanding Python from a PHP coder's perspective

Hello all!  Just started getting into Python, and am very excited about the prospect.

I am struggling on some general concepts.  My past experience with server-side code is mostly limited to PHP and websites.  I have some file called "whatever.php", the browser accesses it, and PHP parses it and returns HTML, JSON, etc.  Every now and then, I need to run some background PHP script, or have some PHP script initiated by a CRON job, or have some PHP script initiated by the command line running in an endless loop, and while it works, feel other languages might be more appropriate.

So, my interest in Python...

I've read up on Python, and while some aspects seem similar to PHP, some don't.  I have learned how to create Python script, have run it from the command line, and have even accessed it with Apache by placing http://example.com/myscript.py in the browser.  I am used to seeing .php extensions, but never .py extentions, and even visited multiple sites which I knew were written in Python, but never saw the browser expose the .py extensions.  I am obviously missing something.

Why don't I see the .py extension in my browser?

Is Python event driven like PHP, or is it somehow different?

How should I view Python differently than PHP?

Thank you

[toc] | [next] | [standalone]

#100106

Right after I sent my first post, I realized I did not include the following:

Per https://wiki.python.org/moin/PythonVsPhp, "The vast majority of Python Web applications are run in a separate process. This has some important implications."

From a PHP background, guess I just don't understand the concept of "separate processes".  What does this mean, how is it implemented, and what are the "important implications"?

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

#100113

On Tue, Dec 8, 2015 at 8:21 AM,  <villascape@gmail.com> wrote:
> Per https://wiki.python.org/moin/PythonVsPhp, "The vast majority of Python Web applications are run in a separate process. This has some important implications."
>
> From a PHP background, guess I just don't understand the concept of "separate processes".  What does this mean, how is it implemented, and what are the "important implications"?

This is talking about how PHP code is generally run inside the
server's process. I'll use Apache as my example, as that's what I have
handy.

There are a couple of ways that Apache can run PHP code. One is
spawning a new process for every page request, and using CGI mode; and
the other is a thing called mod_php, which runs PHP as a module inside
the Apache process. The first one gives great isolation between pages,
but it's horribly slow (every page request has to start a process -
cheap on Unix, expensive on Windows - and fully initialize PHP, which
is expensive everywhere); the second fixes the performance problem, at
the cost of maintaining hidden state in the Apache process. Most PHP
web sites out there are using (the equivalent of) mod_php. Coupled
with features like persistent database connections (another way of
improving performance at the cost of isolation), or changes to PHP
error handling configs, this can create *very* debug-hard problems
that depend on the exact distribution of work among Apache processes.
This becomes even worse if you have multiple PHP web sites running in
the same Apache instance; any one of them could interfere with any
other.

In contrast, Python code is run in a separate process from Apache. It
openly and honestly does NOT reset its state between page requests
(which you do need to be aware of; for instance, always commit/roll
back your database transactions before returning), but there's no way
for Python to affect Apache or vice versa. If you have two Python web
sites on the same server, they are completely isolated from each
other.

As well as the massively-beneficial implications of this isolation,
there are some less positive effects. One is that you need to have a
complete Python process for each site you have active - or else pay a
hefty startup penalty on first page load. This can cost a lot of
memory, especially if you have a lot of isolated little web sites
running. But the benefits of isolation are usually worth that cost;
it's possible to run the web server as one user (say, www-data) and
the application server as a different user (say, python-app), and then
grant file system permissions differently to the different users. You
could have two apps running in different versions of Python, or with
different versions of third-party packages. You can put memory or CPU
usage limits on the Python process, without worrying about the web
server itself going down.

It's a very different structure from the mod_php model, and worth
understanding. Personally, I think the costs are worth it; but if you
have a mostly-static web site with just a tiny amount of scripting in
it, it might be better to follow a PHP model.

ChrisA

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

#100116

Thank you all!

Okay, the concept of a WSGI along with a framework provides insight on my main questions.

In regards to Chris's statement: "It openly and honestly does NOT reset its state between page requests"

With PHP, I have sessions to preserve state.  I have a feeling that this is significantly different.  Yes?  How?  Does this somehow relate to how websockets are implemented?

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

#100117

On Tue, Dec 8, 2015 at 9:27 AM,  <villascape@gmail.com> wrote:
> In regards to Chris's statement: "It openly and honestly does NOT reset its state between page requests"
>
> With PHP, I have sessions to preserve state.  I have a feeling that this is significantly different.  Yes?  How?  Does this somehow relate to how websockets are implemented?

All three are very different.

1) Process state.

You start up a Python program, and it sits there waiting for a
request. You give it a request, and get back a response; it goes back
to waiting for a request. If you change a global variable, or maintain
persistent state, or anything, the next request will 'see' that
change. This is completely global.

2) Sessions, cookies, and related concepts.

A request comes in, and the response goes out "Hi! You're caller
number 52635686412, and your call is important to us". Another request
comes in from the same web browser, and the browser says "Hi! You said
I was caller number 52635686412". The server looks up its information
about that caller, which might be in a database, or on disk in the
/tmp directory, or stored in process state (see above), or anything at
all. This gives the appearance of per-client state, but it's all a
simulation.

3) Websockets.

A client makes a request saying "Hey, I want a websocket, please". The
server says "Sure", and then they start maintaining true state. The
socket would be broken if either the server or the client restarts
(unlike sessions, although normally they're set up so a client restart
will wipe the session). Websocket state is per-connection.

Does that answer your question? The one I was talking about there was
#1, process state.

ChrisA

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

#100122

Ah, I was confused that process state somehow allowed Python to support per-connection state without using sessions (which lead me to ask about websockets).  I guess Python could do it without storing the session ID in a file or database and instead in process state (i.e. application memory, right?), but the effect seems basically the same. Without being per-connection, what is the value of process state?

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

#100131

On Tue, Dec 8, 2015 at 12:00 PM,  <villascape@gmail.com> wrote:
> Ah, I was confused that process state somehow allowed Python to support per-connection state without using sessions (which lead me to ask about websockets).  I guess Python could do it without storing the session ID in a file or database and instead in process state (i.e. application memory, right?), but the effect seems basically the same. Without being per-connection, what is the value of process state?
>

Caches and stuff. For example, you might establish a database
connection, and then hang onto it for all queries; or maybe you load
up a bunch of user objects and keep them in memory for when you need
them again. Anything that you store in a global (module-level)
variable will hang around.

ChrisA

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

#100118

On Mon, Dec 7, 2015 at 3:27 PM,  <villascape@gmail.com> wrote:
> Thank you all!
>
> Okay, the concept of a WSGI along with a framework provides insight on my main questions.
>
> In regards to Chris's statement: "It openly and honestly does NOT reset its state between page requests"
>
> With PHP, I have sessions to preserve state.  I have a feeling that this is significantly different.  Yes?  How?  Does this somehow relate to how websockets are implemented?

Session state is different from process state. Whether you start a new
process for each request or reuse an existing process has no bearing
on whether you're storing and reading data related to the user's
session (except that in the reuse case it's possible to cache the data
in-process, whereas an in-memory cache for a restarted process must be
in a separate process; but it's good practice to have your in-memory
cache in a separate process anyway).

I'm not sure where websockets come into this, as that's a completely
separate technology that is not used by most web apps.

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

#100119

On 07Dec2015 14:27, villascape@gmail.com <villascape@gmail.com> wrote:
>In regards to Chris's statement: "It openly and honestly does NOT reset its 
>state between page requests"
>With PHP, I have sessions to preserve state.  I have a feeling that this is 
>significantly different.  Yes?  How?  Does this somehow relate to how 
>websockets are implemented?

Plenty of things use sessions, and I suspect most frameworks provide handy 
mechanisms to make using them easier. I expect that normally, as with PHP, 
you'd pass a cookie back to the user to track them and store the session state 
either in an in memory data structure (loses state over an app or web server 
restart) or in some persistent storage, typically a database of some kind 
(which also allows another process implementing your app/site to handle the 
state even if it did not issue the original session).

Cannot address your websockets query.

Cheers,
Cameron Simpson <cs@zip.com.au>

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

#100133

On 2015-12-08 10:09, Chris Angelico wrote:
> All three are very different.
> 
> 1) Process state.
> 
> You start up a Python program, and it sits there waiting for a
> request. You give it a request, and get back a response; it goes
> back to waiting for a request. If you change a global variable, or
> maintain persistent state, or anything, the next request will 'see'
> that change. This is completely global.

1) This is completely global *to the process* (you can have multiple
Python processes sitting around waiting, taking advantage of multiple
cores)

2) This is almost always a bad idea for multiple reasons (it can get
in the way of scaling, it can produce hard-to-track-down bugs, etc).
Use a real session store (a database, a key/value store like
memcached, a NoSQL store like Redis, store session info in cookies,
etc.) instead.

-tkc

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

#100134

On Tue, Dec 8, 2015 at 2:11 PM, Tim Chase <python.list@tim.thechases.com> wrote:
> On 2015-12-08 10:09, Chris Angelico wrote:
>> All three are very different.
>>
>> 1) Process state.
>>
>> You start up a Python program, and it sits there waiting for a
>> request. You give it a request, and get back a response; it goes
>> back to waiting for a request. If you change a global variable, or
>> maintain persistent state, or anything, the next request will 'see'
>> that change. This is completely global.
>
> 1) This is completely global *to the process* (you can have multiple
> Python processes sitting around waiting, taking advantage of multiple
> cores)
>
> 2) This is almost always a bad idea for multiple reasons (it can get
> in the way of scaling, it can produce hard-to-track-down bugs, etc).
> Use a real session store (a database, a key/value store like
> memcached, a NoSQL store like Redis, store session info in cookies,
> etc.) instead.

If your goal is session state, then yes - use something that actually
persists past the process life. But for caches and stuff, where
dropping them has performance implications but nothing else, it makes
good sense to keep them in globals. Particularly if you simply
populate the cache on process load and then never lose it.

ChrisA

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

#100107

On 07Dec2015 13:07, villascape@gmail.com <villascape@gmail.com> wrote:
>Hello all!  Just started getting into Python, and am very excited about the prospect.
>
>I am struggling on some general concepts.  My past experience with server-side code is mostly limited to PHP and websites.  I have some file called "whatever.php", the browser accesses it, and PHP parses it and returns HTML, JSON, etc.  Every now and then, I need to run some background PHP script, or have some PHP script initiated by a CRON job, or have some PHP script initiated by the command line running in an endless loop, and while it works, feel other languages might be more appropriate.
>
>So, my interest in Python...
>
>I've read up on Python, and while some aspects seem similar to PHP, some don't.  I have learned how to create Python script, have run it from the command line, and have even accessed it with Apache by placing http://example.com/myscript.py in the browser.  I am used to seeing .php extensions, but never .py extentions, and even visited multiple sites which I knew were written in Python, but never saw the browser expose the .py extensions.  I am obviously missing something.

The most obvious thing is: a well produced website does not expose its 
implementation language in the URL. All those .php URLs? Sloppy! Suppose you 
wanted to change the implementation and switched languages? All your users' 
bookmarks would break!

>Why don't I see the .py extension in my browser?

Usually Python is used in a web server via a WSGI plugin and a framework of 
some kind (Django, Flask, CheryPy etc). All of these allow you to associate any 
URL with any piece of Python code. So you don't have that simple but also 
inflexible "map this URL to a specific .php file" model that you have with 
typical PHP.

>Is Python event driven like PHP, or is it somehow different?

Depends what you mean by "event driven". I suspect you mean "accessing a web 
page runs a python program".

A .php file is a kind of macro file: it is ostensibly HTML until one hits the 
<?php tag, and then a snippet of PHP runs and usually writes some output into 
the HTML stream going back to the browser. You very rarely see PHP 
"standalone", used to write command line tools or other things - it is almost 
only ever used to generate web page output.

Python is a general purpose language and all manner of things are written in 
it. When used in a web server there is usually:

  - a WGSI hook into the web server configuration, which causes certain URLs to 
    be passed to a running Python program for implementation

  - a Python program which maps those URLs to particular pieces of code, which 
    return HTML or other suitable content

>How should I view Python differently than PHP?

It is more useful and nicer to work in. For a quick and dirty web page PHP is a 
handy tool, but almost entirely for the web. Python is not targeted specificly 
at web output.

Cheers,
Cameron Simpson <cs@zip.com.au>

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

#100108

On Mon, Dec 7, 2015 at 2:07 PM,  <villascape@gmail.com> wrote:
> Hello all!  Just started getting into Python, and am very excited about the prospect.
>
> I am struggling on some general concepts.  My past experience with server-side code is mostly limited to PHP and websites.  I have some file called "whatever.php", the browser accesses it, and PHP parses it and returns HTML, JSON, etc.  Every now and then, I need to run some background PHP script, or have some PHP script initiated by a CRON job, or have some PHP script initiated by the command line running in an endless loop, and while it works, feel other languages might be more appropriate.
>
> So, my interest in Python...
>
> I've read up on Python, and while some aspects seem similar to PHP, some don't.  I have learned how to create Python script, have run it from the command line, and have even accessed it with Apache by placing http://example.com/myscript.py in the browser.  I am used to seeing .php extensions, but never .py extentions, and even visited multiple sites which I knew were written in Python, but never saw the browser expose the .py extensions.  I am obviously missing something.
>
> Why don't I see the .py extension in my browser?

PHP tends to be served like CGI, which is that the URL mirrors the
path to a script that lives under a particular directory, which the
webserver locates and executes. This has some downsides:

* It exposes details about the structure of your server to the public,
which is considered a security weakness.
* An improperly configured webserver might accidentally serve scripts
or other files that are not intended to be served over the web, which
is a much bigger security risk.
* It's inflexible; if you move your script, then the URL must
necessarily change as well.

With Python, it's more usual to have a greater abstraction between
URLs and code. A set of URLs are mapped to a single Python gateway,
and the gateway dispatches the request to the appropriate request
handler. With this scheme there is no reason to have .py extensions in
the URLs because the URL structure is unrelated to how the actual
scripts are organized in the file system. This also makes it easier to
create meaningful URLs: see
https://en.wikipedia.org/wiki/Semantic_URL.

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

#100110

On Tue, Dec 8, 2015 at 8:07 AM,  <villascape@gmail.com> wrote:
> I am struggling on some general concepts.  My past experience with server-side code is mostly limited to PHP and websites.  I have some file called "whatever.php", the browser accesses it, and PHP parses it and returns HTML, JSON, etc.  Every now and then, I need to run some background PHP script, or have some PHP script initiated by a CRON job, or have some PHP script initiated by the command line running in an endless loop, and while it works, feel other languages might be more appropriate.
>
> So, my interest in Python...
>
> I've read up on Python, and while some aspects seem similar to PHP, some don't.  I have learned how to create Python script, have run it from the command line, and have even accessed it with Apache by placing http://example.com/myscript.py in the browser.  I am used to seeing .php extensions, but never .py extentions, and even visited multiple sites which I knew were written in Python, but never saw the browser expose the .py extensions.  I am obviously missing something.
>
> Why don't I see the .py extension in my browser?
>
> Is Python event driven like PHP, or is it somehow different?
>
> How should I view Python differently than PHP?

Hi there! Welcome to the list, and thank you for trying to understand
the differences, instead of simply expecting Python to behave like the
thing you already know.

To demonstrate what I'm talking about, I'm going to use a tiny
Python-based web site that I knocked together a little while ago. The
source code is on GitHub, and the site itself is public, so you can
see both:

https://github.com/Rosuav/MinstrelHall
http://minstrelhall.com/

The most important file is mh.py - click on that to see the code.

In PHP-based web sites, the structure of your source code exactly
matches the structure of your web site. The file system *is* your web
site; any time the web server (say, Apache) comes across something
that has the .php extension, it goes and runs it as code.

In Python-based web sites like this one, the layout of the source tree
follows a structure that keeps logically-similar things together, and
the structure of the web site is defined by code. As you read through
mh.py, you'll see a number of lines saying @app.route("...") - those
are creating URLs (sloppy terminology, but close enough). There's one
that says @app.route("/"), which handles http://minstrelhall.com/, and
another just underneath it that says @app.route("/campaign/<int:id>"),
which handles http://minstrelhall.com/campaign/6 (and any other
integer ID that might be passed in).

One advantage of this kind of setup is that your URLs don't depend on
your back end. I could replace all this with a Ruby on Rails site, and
nobody would notice the difference. I could put together something
using Node.js to replace the Ruby site, and continue to provide
content at http://minstrelhall.com/campaign/6 - again, nobody would
care.

Another *massive* advantage is a complete separation of code and data.
You can't see it in Minstrel Hall, but here's a web site that has a
static-files collection:

https://github.com/Rosuav/Flask1
http://rosuav.com/1/

(Note that this Flask site isn't running the whole domain, but only
one subdirectory. What Python sees as @app.route("/foo") is actually
http://rosuav.com/1/foo.)

Any files in the static/ directory are made available by the framework
- but they are, by definition, static files. Any file that I put there
will be delivered as-is. Suppose I create a world-writable directory
called "uploads", and then have a script that accepts a form
submission with an attachment, saving the attachment into the uploads
directory. (This, by the way, is not an engineered example; it's a
real-world example from another web site that I host.) If the uploads
directory is inside static, anything saved to there will be viewable
as http://rosuav.com/1/uploads/some_file_name, but - and this is the
important part - no matter what its file extension, *it will not be
run*. You can upload a .py file, and it'll be visible as Python source
code. You can upload a .cgi script, and it'll be visible as plain
text. You can upload a .php file, and nothing will run it.

This is quite tricky to do with PHP, and requires some careful
management of Apache config files (or presumably the equivalent in
nginx or other servers). With Python+Flask (or any other code-based
server setup), it's automatic. This safety makes a *huge* difference
to the compromisability of your web site; you can accept uploads
without worrying about remote users running code and creating reverse
shells and stuff.

So that's a quick potted summary of why the URLs don't reflect the
language used. Python is event-driven, but instead of defining events
at the file level, the way PHP does, they're defined at the function
level. Of course, if you *want* to put ".py" on the end of all your
URLs, Python won't stop you... :)

ChrisA

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

#100111

On 12/7/2015 4:07 PM, villascape@gmail.com wrote:
> Hello all!  Just started getting into Python, and am very excited about the prospect.
>
> I am struggling on some general concepts.  My past experience with server-side code is mostly limited to PHP and websites.  I have some file called "whatever.php", the browser accesses it, and PHP parses it and returns HTML, JSON, etc.  Every now and then, I need to run some background PHP script, or have some PHP script initiated by a CRON job, or have some PHP script initiated by the command line running in an endless loop, and while it works, feel other languages might be more appropriate.
>
> So, my interest in Python...
>
> I've read up on Python, and while some aspects seem similar to PHP, some don't.  I have learned how to create Python script, have run it from the command line, and have even accessed it with Apache by placing http://example.com/myscript.py in the browser.  I am used to seeing .php extensions, but never .py extentions, and even visited multiple sites which I knew were written in Python, but never saw the browser expose the .py extensions.  I am obviously missing something.
>
> Why don't I see the .py extension in my browser?

Better security, I believe.

> Is Python event driven like PHP, or is it somehow different?

Python is not event-driven as you mean it, but you can do event-driven 
systems in Python.

> How should I view Python differently than PHP?

You should formulate your own general view.  For specific aspects, ask 
more specific quesitons, like you did above.

-- 
Terry Jan Reedy

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

#100112

On Mon, Dec 7, 2015 at 2:40 PM, Chris Angelico <rosuav@gmail.com> wrote:
> So that's a quick potted summary of why the URLs don't reflect the
> language used. Python is event-driven, but instead of defining events
> at the file level, the way PHP does, they're defined at the function
> level. Of course, if you *want* to put ".py" on the end of all your
> URLs, Python won't stop you... :)

Or, if it's a poorly implemented site, ".rb". ;-)

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

#100115

On Tue, Dec 8, 2015 at 8:59 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Dec 7, 2015 at 2:40 PM, Chris Angelico <rosuav@gmail.com> wrote:
>> So that's a quick potted summary of why the URLs don't reflect the
>> language used. Python is event-driven, but instead of defining events
>> at the file level, the way PHP does, they're defined at the function
>> level. Of course, if you *want* to put ".py" on the end of all your
>> URLs, Python won't stop you... :)
>
> Or, if it's a poorly implemented site, ".rb". ;-)

Well hey. Python won't stop me from adding ".rb" to the ends of my
URLs either...

ChrisA

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

#100135

On 2015-12-08 08:40, Chris Angelico wrote:
> One advantage of this kind of setup is that your URLs don't depend
> on your back end. I could replace all this with a Ruby on Rails
> site, and nobody would notice the difference. I could put together
> something using Node.js to replace the Ruby site, and continue to
> provide content at http://minstrelhall.com/campaign/6 

Of course, this assumes that your Ruby/Node.js skills allow you to
create a site that's as robust as Python.  Trust me...if I were to
swap out my Python web code with Ruby or Node.js, it would be pretty
noticeable.  Not because of URL issues, but because I don't do
Ruby/Node.js so it would fail pretty spectacularly. :-D

-tkc

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

#100136

Based on your responses, it is my understanding that process-state might offer some efficiency benefits, but it is typically not a driving factor.  If I misunderstand, please advise.  Thanks

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

#100141

Chris Angelico wrote:

> On Tue, Dec 8, 2015 at 8:59 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
>> On Mon, Dec 7, 2015 at 2:40 PM, Chris Angelico <rosuav@gmail.com> wrote:
>>> So that's a quick potted summary of why the URLs don't reflect the
>>> language used. Python is event-driven, but instead of defining events
>>> at the file level, the way PHP does, they're defined at the function
>>> level. Of course, if you *want* to put ".py" on the end of all your
>>> URLs, Python won't stop you... :)
>>
>> Or, if it's a poorly implemented site, ".rb". ;-)
> 
> Well hey. Python won't stop me from adding ".rb" to the ends of my
> URLs either...

Or ".php". Leaking the suffix is both ugly and excellent marketing -- a 
combination that is also common in the fashion industry.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web