From: zeph on
On Dec 11, 8:58 am, MRAB <pyt...(a)mrabarnett.plus.com> wrote:
> output = ['<html><head>']
> output.append('<title>My Page</title>')
> output.append('</head><body>')
> output.append('<h1>Powers of two</h1>\n<ol>')
> for n in range(1, 11):
>      output.append('<li>%s</li>' % (2 ** n))
>
> output.append('</ol></body></html>')
> print ''.join(output)

Agreed (I might join on '\n' though), I was just trying to introduce
as few new concepts as possible :)
From: Tino Wildenhain on
MRAB schrieb:
> zeph wrote:
> [snip]
>> 4) It's better to collect all your eventual output into a string that
>> you print - there are examples at [3]. You can import from other
>> modules as needed (even conditionally), grow your string for output,
>> then finally print it like (this example was adapted from one found on
>> [3]):
>>
>> output = '<html><head>'
>> output += '<title>My Page</title>'
>> output += '</head><body>'
>> output += '<h1>Powers of two</h1>\n<ol>'
>> for n in range(1,11):
>> output += '<li>'+str(2**n)+'</li>'
>>
>> output += '</ol></body></html>'
>> print output
>>
>>
>> You can copy-paste this right into your Python interactive shell to
>> see the output. Note: += is inline string concatenation.
>>
> It's better to put the strings into a list and then concatenate them in
> one go:
>
> output = ['<html><head>']
> output.append('<title>My Page</title>')
> output.append('</head><body>')
> output.append('<h1>Powers of two</h1>\n<ol>')
> for n in range(1, 11):
> output.append('<li>%s</li>' % (2 ** n))
>
> output.append('</ol></body></html>')
> print ''.join(output)

Actually I'd use a proper template engine in any case. The above
construction of mixing code and representation (or rather code with
code and data for another interpreter - the users browser) is not only
unlucky, it is almost everytime very dangerous.

Keep in mind if you are using a user supplied string, like coming from
a form entry and just include it as above literally into your HTML, you
have created a way of cross site scripting, a very common attack.

To prevent that, you should always propery quote strings for the context
where they are used. Template engines such as Zope Page Templates (also
usable stand allone) are doing this for you.

Regards
Tino
From: Diez B. Roggisch on
>> 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.

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

Diez
From: Sancar Saran on
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
From: Nobody on
On Fri, 11 Dec 2009 12:26:30 +0200, Sancar Saran wrote:

> 1-) Can I create Global (read/write access anywhere from my code) Multi
> dimensional, associative array (or hash) and store any kind of variable type.

Global, no; at least not in the sense of e.g. C. Python doesn't have a
global namespace; the highest level is a module.

Read/write from anywhere in your code, yes. You just need to decide which
module to put the variable in, then import that module (or even the
specific variable) from the other modules.

E.g. you can have a file state.py containing nothing but:

state = {}

Other modules can then use:

from state import state

to make the variable visible.