On Tue, Dec 8, 2015 at 8:24 PM, Peter Otten <__pete...@web.de> wrote:
> Chris Angelico wrote:
>
>> On Tue, Dec 8, 2015 at 8:59 AM, Ian Kelly wrote:
>>> On Mon, Dec 7, 2015 at 2:40 PM, Chris Angelico wrote:
So that's a quick potted summary of why the URLs don't reflect the
language used.
Chris Angelico wrote:
> On Tue, Dec 8, 2015 at 8:59 AM, Ian Kelly wrote:
>> On Mon, Dec 7, 2015 at 2:40 PM, Chris Angelico 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
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
--
https://mail.python.org/mailman/listinfo/python-list
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,
On Tue, Dec 8, 2015 at 2:11 PM, Tim Chase 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
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,
On Tue, Dec 8, 2015 at 12:00 PM, 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 inst
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,
ri
On 07Dec2015 14:27, villasc...@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
On Mon, Dec 7, 2015 at 3:27 PM, 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
On Tue, Dec 8, 2015 at 9:27 AM, 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
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
signifi
On Tue, Dec 8, 2015 at 8:59 AM, Ian Kelly wrote:
> On Mon, Dec 7, 2015 at 2:40 PM, Chris Angelico 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 d
On Mon, Dec 7, 2015 at 2:40 PM, Chris Angelico 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
On Tue, Dec 8, 2015 at 8:21 AM, 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
> pro
On 12/7/2015 4:07 PM, villasc...@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.
On Tue, Dec 8, 2015 at 8:07 AM, 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
On Mon, Dec 7, 2015 at 2:07 PM, 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
On 07Dec2015 13:07, villasc...@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.p
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 t
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 an
21 matches
Mail list logo