[Tutor] Python logging

[Scott SA]

Hi,

For some reason, I'm having a bit of trouble figuring this one out. I  
know it has to be relatively easy but it just isn't "working" for me  
at the moment.


I want to re-direct the logs from python's logging library and while  
using a config file rather than instantiating all of the logging  
within my actual code.


So, lets say I have a file log.conf that contains the various  
directives for the logging module. Amongst all of the other settings a  
handler might look like this:


[handler_warn_logfile]
class=handlers.RotatingFileHandler
level=WARNING
formatter=DatetimeLevelMessage
args=('test_warn.log', 'a', 125829120, 5)
filename=test_warn.log
mode=a

then loaded like this

logging.config.fileConfig(log_config_path)
logging.debug('Logging enabled')


... which basically says append WARNING messages to the rotating file  
handler in DatetimeLevelMessage format to a log-file named  
test_warn.log splitting the log-file when it exceeds 125829120 bytes.


Because I don't have any full paths listed, the logger uses the  
current working directory i.e. "/home/user/workspace/logged_app/ 
test_warn.log"


I could change the name to "logs/test_warn.log" for a sub-directory  
but I'd like to put a data on some of the logs and not necessarily in  
the root of the scripts but maybe elsewhere on the system i.e. /home/ 
user/logs/someapp/200904_logs/


I've done a bunch of inspection of dictionaries, methods and  
attributes but nothing seems to be surfacing that would allow me to re- 
direct the paths in a dynamic way -- other than using  
os.cwd('some_path') before instantiating the logging... which is quite  
hack-ish IMO.


The only thing that comes to mind, after reviewing the logging via  
help(logging...), is that I may need to dynamically re-write the .conf  
file using ConfigParser.



Any ideas on what I'm missing within the logging for redirecting the  
files? Or, should I bump this up to the main python list?


Thanks in advance,

Scott

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Webpy vs Django

[Scott SA]

On Apr 19, 2009, at 4:52 AM, vishwajeet singh wrote:

This is not to flame any war; I just wanted to know the key features  
to consider among the two web frame works.


What advantage and disadvantages you have when you decide using any  
one of them.


I can't speak with any authority on Webpy (webpy.org), as I have not  
actually used it though I did read up on its features about a year ago  
and now just a quick glance again. I do have some experience with a  
different 'light-weight' framework called Quixote (www.quixote.ca) and  
have a production project using it... that I'm migrating to Django. I  
also have a couple of projects using Zope... also being migrated to  
Django. I don't mention all of this as any indication of prowess, in  
fact much of the code on these projects has been written by other  
developers I've contracted to, but that I have some similar experience.


The main point I wish to make of all this is that these different  
frameworks kind of coalesce into sub-groups. They sort-of form into  
three groups: light-weight framework, full-featured framework and  
heavy CMS (lots of inseparable overhead). Furthermore, like a series  
of balls or coins in a simple Pachinko machine (http://en.wikipedia.org/wiki/Pachinko 
) where each one takes a different route, the application you are  
developing will have a huge influence on requirements.


Personally, I've been working with Django on and off for about 2-1/2  
years and find it a joy to work with. It does not have the overhead  
and hidden 'magic' of Zope and I don't have to re-invent almost  
everything like Quixote. For _my_ needs, it has been a great blend of  
capabilities without the oppressing overhead of the CMS. I can add or  
remove the modules needed on a project-by-project basis.


"Out of the box", the automated admin interface is a huge time-saver  
and its object-relational model is quite good at wrapping relational  
databases into a python-friendly framework. Also it's user-admin and  
authentication takes care of the core of most sites I work on. It has  
a good blend for my requirements of granular framework access and  
functional tools to save me time. And now, there is quite a nice  
selection of add-on applications that extend Django in a very modular  
fashion, though there are still growing pains. Like "Goldie Locks and  
the three bears", this one is "just right" for my needs.


Just as Zope is overkill for projects that don't need CMS, Django  
would be overkill for a project that didn't need much for database  
access and admin interface. The authors of Django, try pretty hard to  
not hide anything that is going on in the background but there is  
still a lot being done for the developer. For example in creating db  
schemas, wrapping queries and result-sets into object calls, rendering  
content through templates and much more. All have ways of being  
modified but not necessarily by novice python developers.


So the short answer to your question is that Webpy and Django are  
quite different in their tool-sets and are therefore tough to compare.  
As with all lightweight frameworks, they are _shorter_ on pre-defined  
features. That's not a negative, that _is_ the point of them. Django  
has tried to bridge, and in my opinion done a good job of it, a  
lighter-weight core with a well documented and developer-friendly  
interface for extension. It is a framework that has allowed me to  
gradually dig deeper and deeper into its workings to extract more  
advanced features while not bogging me down with redundant and tedious  
things like forms and user authentication.


I chose Django because it had the most to offer for what I need and it  
seems to have the "legs" to cover a lot of ground. That said, I don't  
that anyone could say you were wrong by choosing either of the  
projects you mentioned given appropriate circumstances (though  
personally, I can't find _any_ circumstances where I'd recommend Zope  
today -- but that's probably a personal bias and I won't digress).


I know this doesn't answer your question directly but I hope it helps  
broaden the perspective a little,


Scott
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python logging

[Scott SA]

Hi Stephan & Kent,

On Apr 19, 2009, at 6:12 AM, Stefan Behnel wrote:


just commenting on this part:


... which basically says append WARNING messages to the rotating file
handler in DatetimeLevelMessage format to a log-file named  
test_warn.log

splitting the log-file when it exceeds 125829120 bytes.


You may have a reason to cut these at "125829120" bytes, but it's  
usually a

bad idea to cut log files by size. It's much more natural to have time
sliced log files (one per day or per hour), so that you directly  
know which
file you have to look at to analyse that stuff that went so terribly  
wrong

yesterday evening (especially once they get archived somewhere).


I didn't set-up this portion of the file config. file and have not  
found much documentation for the conf-file formating (much of the rest  
is very well documented). I guess I should really find the actual code  
and read what it is doing... as Kent very gently prodded me with. I  
did go through a few PEPs too, and I don't recall seeing anything  
about time-based rotation ... but then maybe it was there and it  
didn't register with me. Thanks for the heads-up, I'll go back and re- 
read the material.



Looking at the code for the logging module, I think it will work to
create the RotatingFileHandler with the parameter delay=True, then in
your code get the handler and change its baseFilename attribute to be
the path you want, e.g.
"/home/user/workspace/logged_app/test_warn.log".


That's an interesting feature, I'll have to go look and see what other  
jewels are lurking in various modules. So far I've not spent a lot of  
time going through the code for modules like this, but obviously I  
should (I often learn more than just how a bit of code works by  
reading how others have solved problems).


Thank you both!

Scott
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Reading from files problem

[Scott SA]

On Apr 20, 2009, at 12:59 AM, Alan Gauld wrote:


You might want to store the data in a dictionary keyed by ID number?


I had thought of suggesting this, but it appeared that the OP was  
going to re-iterate the file each time he wished to query the CSV.


May have been a bad assumption on my part as I envisioned pickling a  
dict. and that just got too complicated.



test = [float(n) for n in lines[11:14]]
hwgrades = sum(hw)


The composite of this would be:
sum([float(n) for n in lines[11:14]])

... which, I agree, is easier on the eyes/brain than the  
reduce(lambda:...) example I gave.


sum is also on  along  
with with range and other built-ins.


Chris: wrapping the for-loop in square-brackets is part of list  
comprehension, found here (part 5.1.4)



Thats all fine for reading one stiudent, but you overwrite the data  
each time through the loop! This also looks like an obvious use for  
a class so I'd create a Student class to hold all the data
(You could create methods to do the totals/averages too, plus add a  
__str__  method to print the student data in the format required-  
I'll leave that as an excercise for the reader!))


This part is actually the reason I've replied, everything before this  
was 'just along the way'.


Classes are a big subject for starting out, here are the main docs.


Also, check out 'dive into python' and others for help in getting a  
handle on that.


I figured that the Student class proposed probably needed an example  
to get over the initial hurdle.


class Student(object):
def __init__(self)
pass

In its most basic form, this is pretty much the 'hello world' for  
classes.



So I'd change the structure to be like this(pseudo code)

students = dict()  # empty dict
for line in gradesfile:
  line = line.split(',')
  s = Student()


This step creates an instance of the class. Just for the moment, think  
of it as a fancy variable -- how python will store and reference the  
live data. In the end, you would need a class-instance for each and  
every student (line of the file).



  s.id = line[0]


And this adds an 'id' attribute to the class

Pre-defined in the class, this would look like:

class Student(object):
def __init__(self)
self.id = None

When the instance is created, the id has None as its value (or  
anything you wanted). The "self" reference means the instance of the  
class itself, more on that in a moment.


Still accessed the same as above:
s.id = n


  s.lastname = line[1]
  etc
  s.hwtotal = sum(hw)
  etc
  students[s.id] = s


As mentioned, id, lastname, hwtotal, etc. become attributes of the  
class. Nothing terribly magical, they are actually stored in a  
dictionary (i.e. s.__dict__) and long-hand access would be:  
s.__dict__['id']


So, the next step to this would be to actually use the class to do the  
heavy lifting. This is what Alan is talking about a bit further down.


class Student(object):
def __init__(self, csv_data):
csv_list = csv_data.split(',')

self.id = csv_list[0]
...
self. hwgrades = self._listFloats(csv_list[4:10])

def _list_floats(self, str_list):
return [float(n) for n in str_list]

def hw_grade_total(self):
sum(self.hwgrades)

The two methods are part of the business-logic of the class - notice  
internally they are accessed by 'self'. This is very important, so  
python knows what data to work with.


Assuming you're not using the CSV library or already have the row/line  
from the file as a list:


for student_data in grades_file:
s = Student(student_data)
student_dict[s.id] = s

So, when python creates the class instance, it calls the __init__  
method. Since you've passed it a list of student data, it processes it  
at the same time. In this example, it will cause an error if you don't  
pass any data, by the way. You might need to consider verifying that  
each line has the correct number of fields otherwise an error could be  
generated.


Accessing the grade total method is like this:

grade_total = s.hw_grade_total()

Or, if you want the raw list of floats:

grade_list = s.hwgrades

I still contend that all of this is ideal for a database, like SQLite,  
which would allow for searching by name as well as ID, etc. It is the  
persistence of data that motivates this perspective. So what I would  
do is make a class Students, with a file-import method using the CSV  
lib which then did the work of putting all the data into a database,  
bypassing a Student cla

Re: [Tutor] visualizing code structure / flow charting

[Scott SA]

On 11/6/07, Wesley Brooks ([EMAIL PROTECTED]) wrote:

>Taking both one step further if you can extract all the __doc__
>strings for all the objects listed from the dir of an object:
>
>a = 'a random string'
>for i in dir(a):
>command = "print str." + i + ".__doc__"
>exec(command)
>
>This will print out all the __doc__ strings for functions you can call
>on your string object a. This is particually helpful when you know
>what you want to do to something (for instance capitalise the first
>letter each word in a string) but don't know what function to call.

While not as educational from one perspective, I've found the epydoc package 
quite useful. It extracts all of the doc strings and formats them in a nice, 
easy to read, layout.



Scott
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Obtaining image date of creation

[Scott SA]

On 11/14/07, Roy Chen ([EMAIL PROTECTED]) wrote:

>I would like to write a simple script that would rename a bunch of  
>photos according to their creation date, i.e. the date which the  
>photo was taken.
>
>Is there a way to use Python to obtain that information from the  
>image file, or is that information not stored in the file?

There are a couple of EXIF libraries dedicated to reading EXIF headers of JPEG 
images plus, as mentioned by others PIL. Another great imaging library is 
ImageMagick but last time I looked the wrapper for it was in disarray IIRC.

A really quick snoop 'round the web turned up this PIL snippet:

from PIL import Image
from PIL.ExifTags import TAGS

def get_exif(fn):
ret = {}
i = Image.open(fn)
info = i._getexif()
for tag, value in info.items():
decoded = TAGS.get(tag, tag)
ret[decoded] = value
return ret

Posted by 'Justin' here:




There is also:
 (recommends EXIF.py below)

 (py-magic is one library-wrapper)

EXIF.py is a possible choice for this task:


Here's a sample of what I did to extract the tags I was interested in (I wanted 
_more_ than the dates ;-). I also wanted something that could handle the 
variances between manufacturers i.e. not using a particular tag. There _are_ 
tags missing in EXIF.py although it has been updated recently for some Nikon 
and Olympus stuff.

This is a portion of a class I wrote to wrap other tasks, I didn't do anything 
wonderful here with exception handling:

import EXIF

def fetch_exif(strPath):

# dictionary of desired tags (I have it elsewhere in the class). 
# Only one of a few ways to do this...
exif_tags = {
'EXIF DateTimeDigitized': '',
'EXIF DateTimeOriginal': '',
'EXIF ExifImageLength': '',
'EXIF ExifImageWidth': '',
'EXIF ExifVersion': '',
'EXIF ExposureBiasValue': '',
'EXIF ExposureProgram': '',
'EXIF ExposureTime': '',
'EXIF Flash': '',
'EXIF FNumber': '',
'EXIF FocalLength': '',
'EXIF ISOSpeedRatings': '',
'EXIF MaxApertureValue': '',
'EXIF MeteringMode': '',
'EXIF SceneType': '',
'EXIF ShutterSpeedValue': '',
'EXIF SubSecTime': '',
'Image DateTime': '',
'Image ImageDescription': '',
'Image Make': '',
'Image Model': '',
'Image Orientation': '',
'Image XResolution': '',
'Image YResolution': '',
'ImageType': '',
'ImageNumber': '',
'OwnerName': '',
'SerialNumber': '',
'FirmwareVersion': '',
'InternalSerialNumber': '',
}

exif_keys = exif_tags.keys()

# iterate the keys looking for desirable/desired tags
try:
image_file = open(strPath,'rb')
image_tags = EXIF.process_file(image_file, details=False)
image_file.close()
image_keys = image_tags.keys()

for key_name in exif_keys:
if key_name in image_keys:
exif_tags[key_name] = image_tags[key_name]

except:
# typically caused by missing exif
exif_tags = False
image_file.close()

return exif_tags


A more compact option would have been to iterate a simple list of _desired_ 
tags, then build the dictionary of the ones available.

return_exif_dict = {}

shopping_list = ['EXIF DateTimeDigitized', 'EXIF DateTimeOriginal', 
'EXIF ExifImageLength', 'EXIF ExifImageWidth', 'EXIF ExifVersion', 
'EXIF ExposureBiasValue', 'EXIF ExposureProgram', 'EXIF ExposureTime', 
'EXIF Flash', 'EXIF FNumber', 'EXIF FocalLength', 'EXIF ISOSpeedRatings',   

'EXIF MaxApertureValue', 'EXIF MeteringMode', 'EXIF SceneType', 
'EXIF ShutterSpeedValue', 'EXIF SubSecTime', 'Image DateTime', 
'Image ImageDescription', 'Image Make', 'Image Model', 
'Image Orientation', 'Image XResolution', 'Image YResolution', 
'ImageType', 'ImageNumber', 'OwnerName', 'SerialNumber', 
'FirmwareVersion', 'InternalSerialNumber'] 

try:
image_file = open(strPath,'rb')
image_tags = EXIF.process_file(image_file, details=False)
image_file.close()
image_keys = image_tags.keys()

for key_name in exif_keys:
if key_name in image_keys:
return_exif_dict[key_name] = image_tags[key_name]
...


You should be aware that it _is_ possible for a DC to take more than one image 
per second - though with a

Re: [Tutor] repeat

[Scott SA]

On 11/17/07, Michael ([EMAIL PROTECTED]) wrote:

>This has probably been asked before but can I get some clarification on 
>why Python does not have a repeat...until statement, and does that mean 
>repeat...until is bad practice? I was trying to get Python on the 
>standard langauge list for my state secondary school system but they say 
>a langauge must have a test last structure in it to be considered.

While you may feel your assertion to be true, it will persist until discovered  
false... 



... to date has satisfied my needs for the task. 8^)


Like many things in Python there are alternates, even to this (I expect to be 
learning more of them myself for a good long time 8^)

More examples and detail can be found at:





Simply put:

while [test]:
do something

 or

while True:
do something
if [test]:
break

x = 0

while x < 100:
x += 1

print x
100

Still, the links can elaborate more than I can.

HTH

Scott
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python CMS advice wanted

[Scott SA]

On 11/27/07, jim stockford ([EMAIL PROTECTED]) wrote:

>IMO:
>my experience with cms systems is that there's a big
>learning curve. you might have more fun (and be more
>productive and maybe more creative) if you use the
>available appropriate python modules and cobble
>together your own site.

Woah, I whole-heartedly disagree with this. Sorry!

>maintenance, especially by some one else, would
>be an area to worry about: each cms system has its
>own community of experts, a few of which are always
>available to help. your custom code would present
>new people a learning curve.

This is why I disagree: maintenance. 

Oh yeah, how about: security!

Along with expediency, quality and a bunch of other things like maybe the OP 
would like a life too (i.e. not be a slave to supporting his own code).

Frankly, the OP (Richard) does not really need the 'full-meal' of a CMS. He's 
looking for a templating system (cheetah, myghty, kid) and a mechanism to 
organize code into a web application of sorts.

While there are some behemouth CMS options (Zope/Plone) there are some lighter 
ones (turbogears) and even ones that are not as much CMS but frameworks 
(django, pylons, even quixote).

Yes, some of the frameworks/CMS have small communities (quixote) but others 
(django, tubogears) are quite active. Still, each _do_ have a community and if 
th OP chooses one that has a critical mass (all of the above), he will find 
ample help to get over the humps & bumps.

I'm presently working with Django and am thoroughly enjoying it. While it isn't 
perfect, nothing is, it is very well documented and has a vigorous community. I 
have worked with Zope and Quixote (ridiculous to the sublime), Django is a nice 
blend of features with an intelligent API for my needs. Your mileage may vary.

>expansion and extensibility would probably be as
>problematic regardless of your choice: you can
>expand/extend your code depending on available
>modules and your imagination/skill. you can expand/
>extend a packaged cms system depending on how
>it presents an API and/or other means and limited
>by what the people coding, managing, and releasing
>the cms package choose to add (there'll sooner or
>later be bloat in everything, you want your bloat or
>some one else's?).

Do you think a person with emerging skills is going to create clean, elegant 
code that optimizes Python's strengths? No aspersions toward's Richard's 
skills, just going by his own remark: "I have a rudimentary knowledge of Python"

If the OP had stated some really specific and very unique requirements, there 
may be justification but telling someone to 'roll their own'. It is like saying 
there are side-effects to the latest Flu shot so you better go create your own. 

I don't mean to be critical of you; taking the time to express your 
constructive opinion is a valuable act. However, in this case I don't believe 
it serves in the best interest in the OP's requirements.

There are some truths to what I believe you were trying to say. Some 
CMS/Frameworks like Zope are to be avoided, IMHO, unless they satisfy some 
specific requirements (the Zope sites I have are a bear to extend for reasons 
outside the scope of this thread). They are bloated or just non-starters, but 
thankfully they are not the only options.

To close, I strongly suggest the original poster Richard check out Django, 
TurboGears and Pylons. I don't have much exp. with the latter two, but there is 
a reason they are generally popular. While those reasons don't meet with my 
req. they may meet with his.

It is _always_ easier to engineer/re-engineer from a _good_ base of knowledge 
than it is to start fresh... though an open mind is equally important.

I hope this helps,

Scott

>On Nov 27, 2007, at 6:52 AM, Richard Querin wrote:
>
>> Hi,
>>
>> I've got a site that is currently a static site. While not 
>> unmanageable at the moment (it's still pretty young), we've been 
>> entertaining thoughts of converting it to a CMS system. I'm looking 
>> for some good suggestions based on some simple criteria:
>>
>>
>> I'm a complete newbie when it comes to CMS systems so I'm not sure 
>> whether or not it might be better just to go with something like an 
>> install of Wordpress instead.
>>
>> Just looking for some suggestions. The current site btw is 
>> http://screencasters.heathenx.org
>>
>> RQ
>> ___
>> Tutor maillist  -  Tutor@python.org
>> http://mail.python.org/mailman/listinfo/tutor
>
>___
>Tutor maillist  -  Tutor@python.org
>http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python CMS advice wanted

[Scott SA]

First-off, I have to appologize to the list for an accidental re-send of my 
original post. I didn't want to spam the list with an 'oops' message, but it 
seems appropriate now. If the other version gets caught by a moderator, it can 
be deleted - thanks!

On 11/27/07, jim stockford ([EMAIL PROTECTED]) wrote:

Jim, great reply with valid points - only the reader can choose how to weight 
them for their needs.

>> Woah, I whole-heartedly disagree with this. Sorry!
>perfectly okay and somewhat hoped for. note the points
>* "cms systems have a big learning curve": largely true
>and often unsuspected how big.

Agreed, something like Zope sounds promising but it can easily become a 
rats-nest due to the 'magic' factor in the background.

As previously noted that I don't believe he is looking for a CMS but that 
seemed to be a good frame of reference for starting his quest. Now that 
"Frameworks" are on the table, his options are broader, simpler and certainly 
less bloated.

>* "might have more fun (and be more productive...":
>depends on his talents and ambitions, some people
>like coding despite the problems and responsibilities.

Possibly, but unlikely. Before you can use a pencil sharpener, you need to know 
what a pencil is (with mechanical pencils these days, this is not as silly as 
it sounds).

My point is, this being a 'Tutor' list and the expressed level of knowledge, it 
would be more informative for someone to learn how/why a framework has certain 
features by working with them, than trying to discover they need a feature.

The other nice thing about a framework like Django, for exampe, is it can be 
started quite easily and with it's automatic forms a novice can get a pretty 
decent site working in a short period of time. All the while allowing that 
person to write custom 'business logic' in python without a lot of contortions.

It's a high-level approach allowing for the user to drill down as they need.

Essentially, this _is_ the difference in our approaches: which end do you start 
with?

>>>maintenance, especially by some one else, would
>>> be an area to worry about: each cms system has its
>>> own community of experts, a few of which are always
>>> available to help. your custom code would present
>>> new people a learning curve.
>>
>> This is why I disagree: maintenance.
>> Oh yeah, how about: security!
>very good point, security.

I'd be a liar if I said I hadn't been bitten with this before... as would a lot 
of high-profile installations.

This is a double-edged sword. The gains you get from using a framework is the 
knowlege of others the sharp-bit is complexity which brings more opportunity to 
err.

>> Along with expediency, quality and a bunch of other things like maybe 
>> the OP would like a life too (i.e. not be a slave to supporting his 
>> own code).
>for sure one of the considerations, depends on his talent, ambition,
>and build-or-buy proclivity.

"proclivity", "a natural inclination", great word & thanks for introducing me 
to it... now back to the thread.

In my personal experience, the more a batch of code revolves arround _my_ view 
of the task, the more I become the sole point of support. It is a constant 
effort to make things clear, organzied and self-documenting. 

Having the separation of framework from customization is a reduction in volume 
of code to be maintained by the developer.

The sharp-pointy-bit to this is you are reliant on others sometimes for getting 
things fixed and exposed to the possibilty of breakage with upgrades. 

>> Frankly, the OP (Richard) does not really need the 'full-meal' of a 
>> CMS. He's looking for a templating system (cheetah, myghty, kid) and a 
>> mechanism to organize code into a web application of sorts.
>what are the learning curves of cheetah, myghty, kid?
>also,  http://screencasters.heathenx.org  seems at the lean end of the
>richness spectrum (per looking for a templating system), so of all
>possible python projects, his is within reasonable limits as a candidate
>for building from available modules (i.e. from scratch).

Hey, some things are better from scratch... like bread ;-)

My experience with Quixote was valuable from this perpsective. I got tired, 
though, of re-inventing things that already existed elsewhere. For example, we 
wanted to add breadcrumbs, not an arduous task, but we had to re-write it. That 
took resources, time to consider how it needed to work, code it then debug it.

>> Yes, some of the frameworks/CMS have small communities (quixote) but 
>> others (django, tubogears) are quite active. Still, each _do_ have a 
>> community and if th OP chooses one that has a critical mass (all of 
>> the above), he will find ample help to get over the humps & bumps.
>evaluating the community around a framework/cms product
>is an important part of evaluation.

... and everybody's measuring sticks are different. 

>> Do you think a person with emerging skills is going to create clean, 
>> elegant code that optimizes

Re: [Tutor] Python CMS advice wanted

[Scott SA]

On 11/27/07, Richard Querin ([EMAIL PROTECTED]) wrote:

>After reading it all I'm wondering if maybe a templating system like
>Cheetah might be the way to go for us. I'll have to do a lot more
>reading and exploring.

Sure. Be wary of any system that allows the template to freely call python i.e. 
one system I've seen:


... 'nuf said.

>I'd love to learn something like Django but
>like it has been said, that's really a framework you'd use to build a
>CMS. And this site is really a labour of love and not a business
>venture so the time we invest into it at the moment is kind of in
>short supply.

There are a couple of 'screencasts' on 'showmedo.com', one of them is here:


... it's the typical "Build a wiki in 20 minutes" dog 'n pony show, but you do 
get a feel for some of the key features.

There is a pretty direct line between the request and rendering a response. 
Everything arrives in a dictionary and is returned in a dictionary, usually 
with a template spec'd but can be direct too (this isn't totally unique to 
django, I'm just illustrating the concept).  URLs are parsed using regular 
expressions, a portable skill so it's not a framework-specific element and IMO 
doesn't count in the 'learning curve'.

A big difference between templating systems is how 'active content' is 
described. Some templating structures use embedded python within custom tags. 
This is not the case with django and for some that is a deal-breaker, others it 
is a deal-maker. It's pretty feature-rich, but _does_ have its own (well 
documented) syntax using curly-braces ie. {{ dict.item }} or {% ifequal %}.

The db interface is straightforward and much of it is managed for the 
developer, including the table creation; a single command-line call. There are 
a few gotcha's when you want to do some complex queries, but for most things it 
is straightforward and capable. There is the ability to use raw SQL, so the 
developer isn't 'trapped'.

Each table is defined as a python class with field-names as class-attributes 
and the class-name typically as the app & table-name i.e. 'thisap_apptable'. 

The developer can then define methods within each of the classes to do most 
table-related things i.e. custom type-chekcing, agregation of fields and so on. 
Quite pythonic indeed. (you could check out SQLObject for similar functionality 
in an independent library)[EMAIL PROTECTED]

Again, much of the required skills are very portable and not framework 
specific. This was a selling point _for_me_, it feels natural to work with. 
It's automatic admin forms were another bonus, allowing the developer to focus 
on more important things. Did I mention the automatic forms???

It has a built-in server as well, typically for development and dead-simple to 
start/config. From the main project directory the call is:
python manage.py runserver

... an optional port number can be added.

"manage.py" is a set of utility and maintenance scripts for creating the 
databases, seeing what SQL is generated and so on.

Still, as much as _I_ like this framework, I fully recognize there are good 
reasons why others exist and respect their capabilities. I don't want you or 
anyone else to use this because I said so, but because after review it is what 
meets your needs. 

All the best,

Scott

PS. In fact, I fully intend on exploring Pylons (and now Webpy) in the new year 
- nothing is perfect for all circumstances.


>While we have less than 50 entries at the moment, adding each one is
>still quite a hack. I've written a small wxpython app to take away
>some of the pain of it, but it's still prone to corruption and still
>too much work.
>
>I think I'll have to watch some demo's to get a feel for how some of
>these systems work before going down any specific path, because a lot
>of it is still Greek to me.
>
>Again sincere thanks for all the great info, and I'll try to check
>back in on this thread once we get going on a solution.

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Python CMS advice wanted

[Scott SA]

On 11/27/07, jim stockford ([EMAIL PROTECTED]) wrote:
>I'd love to know scott's definition of "framework", especially
>contrasting with full-blown CMS.

Yes, when one compares something like Quixote to Zope, there is a _lot_ of 
middle-ground. They are all frameorks, just with incrementally larger 
feature-sets (a.k.a. bloat and learning curve). I just anecdotally draw anline 
in the sand when workflows and content start being managed extensively. With 
the two names above, I classify the first is a framework, the latter is 
hel^h^h^h a CMS.



>Frameworks for Python:
>CherryPy · Django · Karrigell · Nevow · Porcupine · Pylons · Spyce · 
>TurboGears · TwistedWeb · Webware · Zope

I just found a new-to-me rather lite framework:


There is also more related info here:


A few years old, but still somewhat informative:



>Richard, i think from the (very) little investigation i did
>following scott's last post, that you should investigate
>Django. to me it looks like a pretty streamlined "framework"
>that marries a database (your choice of a few) to a web
>server (apache seems their choice) via mod_python.

FastCGI and WSGI are also supported, the latter looks promising. Has an 
integrated server as well.

>If you take a look on the top-level page for django
>http://www.djangoproject.com/
>you should see a link for "DRY principle". Click it and
>read and follow the links in the subsequent pages:
>you'll find an easy-to-read, to-the-point set of links to
>coders' wisdom (Don't Repeat Yourself,
>OnceAndOnlyOnce, YouAren'tGonnaNeedIt, and more).
>
>http://www.djangoproject.com/

If nothing else, some of the documentation from the project does cover good 
general material, as you've pointed out. (I wish I could get my teen-aged kid 
to figure out the DRY principal... but I digress ;-)

Thanks for the good discussion, Jim. For my part, I think it's  about time for 
me to stick a fork in it 'cause it's done ;-)

Happy trails!

Scott

>On Nov 27, 2007, at 6:49 PM, Richard Querin wrote:
>
>> Whoa!. Lots of very good advice here. Thanks to all.
>>
>> After reading it all I'm wondering if maybe a templating system like
>> Cheetah might be the way to go for us. I'll have to do a lot more
>> reading and exploring. I'd love to learn something like Django but
>> like it has been said, that's really a framework you'd use to build a
>> CMS. And this site is really a labour of love and not a business
>> venture so the time we invest into it at the moment is kind of in
>> short supply.
>>
>> While we have less than 50 entries at the moment, adding each one is
>> still quite a hack. I've written a small wxpython app to take away
>> some of the pain of it, but it's still prone to corruption and still
>> too much work.
>>
>> I think I'll have to watch some demo's to get a feel for how some of
>> these systems work before going down any specific path, because a lot
>> of it is still Greek to me.
>>
>> Again sincere thanks for all the great info, and I'll try to check
>> back in on this thread once we get going on a solution.
>>
>> RQ
>> ___
>> Tutor maillist  -  Tutor@python.org
>> http://mail.python.org/mailman/listinfo/tutor
>>
>
>___
>Tutor maillist  -  Tutor@python.org
>http://mail.python.org/mailman/listinfo/tutor
>
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

[Tutor] Python Best Practice/Style Guide question

[Scott SA]

Per the interesting read at 

Can anyone explain the rationale behind this:

- More than one space around an assignment (or other) operator to
  align it with another.

  Yes:

  x = 1
  y = 2
  long_variable = 3

  No:

  x = 1
  y = 2
  long_variable = 3

The example is rather simplistic and I find the latter form much easier to read 
when there is more than three or four assignments. Furthermore, I don't like 
the use of 'x' and 'y' style variables for anything but classical references 
and concise loops favoring 'chart_x' and 'chart_y' (I have a crappy memory, 
more descriptive names help me, and those reading my code, keep track of what 
I'm doing).

I _do_ see that in this example, it could be hard to follow which value is 
assigned to its respective name, but considering this _slightly_ less 
simplistic (though flawed) example:

string_item = some_method(with_argument)
y = 2
long_variable = antoher_method(with, multiple, arguments)
another_string_item = some_method(with, more, arguments)

Is easier to read (for me) as follows:

string_item= some_method(with_argument)
y  = 2
long_variable  = antoher_method(with, multiple, arguments)
another_assignment = some_method(with, more, arguments)

_Yes_ the order can be changed, but there are reasons why it might be 
inapropriate to reorder i.e. dependencies.

TIA,

Scott

PS. There is a good best-practice link here too:

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor