From: Lie Ryan on
On 12/14/2009 12:04 PM, Sancar Saran wrote:
> On Monday 14 December 2009 02:10:16 am Diez B. Roggisch wrote:
>>> In my usage GLOBALS are too much useful to discard it.
>>
>> The problem with global variables is their scope. If you have a piece of
>> code, the important thing to know is what influences it's behavior when
>> being executed. Functional programs take this to the extreme and usually
>> don't allow any global or otherwise shared state, so if you have a
>> function that reads
>>
>> a = f(x)
>>
>> and you invoke it twice with the same value for x, you get the same result.
>>
>> But sometimes, you need state that is preserved over time. Object
>> orientied design encapsulates this in objects. Each function (method) in
>> a car-object shares the cars state. But *not* the state of *all* cars,
>> which global variables would.
>>
>> Now when reading code, you have to juggle with all the state that
>> influences it. The broader the scope (and global is the biggest one you
>> can get) the harder it is to understand. And believe me, the longer a
>> system exists and the older the code is you look at, the harder it is to
>> understand what's happening.
>
> Yes, I understood. And I'm using large Global dictionary (or Array) to
> replicate those objects. State of the thing will store in there. But it
> wasn't an object. Just Assocative array. Staying in global space,

In python, objects is just syntax sugar for dict/associative array. In
even lower languages (like C++), object is just syntax sugar for a
malloc-ated block of memory. Object-oriented is designed to eliminate
the need for having a God Data Structure such as Global Associative
Array that stores practically everything.

> Because.
>
> In web programming we do not store anything except session. Every object we
> created was destroyed after execution. Using objects in this conditions was
> non sense to me. (of course I'm not very capable programmer probably it was my
> fault to take full advantage of oo programming)

Why is it nonsense? You can create an object that stores the session id,
and the object's methods would query the database without you have to
explicitly mention the session id each time. That's cheap and is very
neat in organizational standpoint.

> Plus. In php we can store arrays in files very easy. Combining this with any
> PHP opcode cache can save those arrays in memory. So we got damn cheap state
> saver.
>
> Of course things may differ in python.

Things differ, but not by that much.
From: Bruno Desthuilliers on
zeph a �crit :
(snip)
> 4) It's better to collect all your eventual output into a string that
> you print

Yuck ! Definitly one of the worst advises you could give.

<OP>
By all mean, *DONT* do that. Use a templating system instead.
</OP>

From: Diez B. Roggisch on
> Yes, I understood. And I'm using large Global dictionary (or Array) to
> replicate those objects. State of the thing will store in there. But it
> wasn't an object. Just Assocative array. Staying in global space,
>
> Because.
>
> In web programming we do not store anything except session. Every object we
> created was destroyed after execution. Using objects in this conditions was
> non sense to me. (of course I'm not very capable programmer probably it was my
> fault to take full advantage of oo programming)
>
> Plus. In php we can store arrays in files very easy. Combining this with any
> PHP opcode cache can save those arrays in memory. So we got damn cheap state
> saver.

This is possible in python, too. But "damn cheap"... well, the cheapest
solution in terms of speed is to just keep the things in memory. Which
you can't do with PHP, as everything lives just one request, but in
Python with certain app-servers, you can do this.

>
> Of course things may differ in python.
>
> Anyhow I generate a Registry class to replicate global dictionary. Probably it
> much better than my PHP Direct $GLOBAL usage.
>
> So I have no problem with that.
>
>>> Anyway, I need to save my lots and lots of config variables in dictionary
>>> style global accessible location.
>>>
>>> Because.
>>>
>>> In my design We got lots of plugins, and those plugins may show in
>>> multiple times and multiple locations in a page.
>>>
>>> Each plugin may have setup values to affect entire page output.
>>>
>>> Because of this. I have to put those values in global location for future
>>> use.
>> No, you don't. Because of this, you can e.g. use ToscaWidgets as a
>> framework for creating widgets that encapsulate code, HTML, javascript
>> and CSS. And no global state is shared.
>>
>> Also, I think you should *really* look into one of the available
>> web-frameworks such as Django or Turbogears to learn how to write
>> webapps in python - instead of shoehorning your tried & trusted PHP
>> techniques that don't translate well.
>>
>
> Yes I download the django trying to learn but it was much different.
>
> My problem is not writing web apps. I'm doing well.
>
> My design was very good and I'm very proud its abilities.
>
> My problem is with PHP syntax and performance.
>
> I'm just trying to replicate my recepies in python...

Then the result will be a twice as horrible program in python. Because
you work against the language.

In the end of course, what matters is what works for you.

Diez
From: Bruno Desthuilliers on
Sancar Saran a �crit :
(snip)
> My problem is with PHP syntax and performance.
> I'm just trying to replicate my recepies in python...

Python is not PHP, and trying to write PHP in Python won't buy you much
except pain and frustration.
From: r0g on
Bruno Desthuilliers wrote:
> Sancar Saran a �crit :
> (snip)
>> My problem is with PHP syntax and performance. I'm just trying to
>> replicate my recepies in python...
>
> Python is not PHP, and trying to write PHP in Python won't buy you much
> except pain and frustration.


I think people are being a little harsh here. Replicating exactly what
PHP code does on a micro level i.e. line by line is probably a bad idea
but for all we know a lot of the macro level stuff might be fine, or
mostly fine i.e. structures, algorithms, classes and functions etc.

If this is the case rewriting the same bits in Python might not be
painful and frustrating, indeed seeing how much terser those things can
be written in Python would probably be quite satisfying.

Of course, some PHP is never going to port well but you can't say for
sure without seeing it.

Roger.