Moving from PHP to Python. Is it Possible

Sancar Saran sancar.saran at evodot.com
Sun Dec 13 20:04:08 EST 2009


On Monday 14 December 2009 02:10:16 am Diez B. Roggisch wrote:
> >> 1) PHP does some really nasty things in how it treats globals, and you
> >> will have to break yourself of those sorts of habits -- Python offers
> >> much cleaner alternatives, like grouping similar functionality into
> >> modules which can be imported; the import functionality in python is
> >> pretty flexible.
> >> Python won't pack a ton of garbage into a giant, global
> >> 'dictionary' (what python calls associative arrays).  There are
> >> modules (bundled of code) which you can import to handle your needs.
> >
> > PHP was doing tons of nasty things. 10 years after I'm starting to
> > understand some those and still not understand most programmers point of
> > view to GLOBALS are evil. Anyhow I'm self learner plus I got heavy
> > English limitation or probably I'm too narrow minded to see right thing.
> >
> > 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, 

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.

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...

> Diez
> 

Regards

Sancar



More information about the Python-list mailing list