Hi folks. I'd love some feedback for two scripts.
-startup_user: Intended to be called from a users logon script to
present a list of apps to launch. List items can be set to default on or
off. I run it from my system logon script like this:
if exist "c:\_utils\scripts\logon_%USERNAME%.py" pytho
Ricardo Aráoz wrote:
> looking at the simpler use, if you would have exception handling in :
>
> try :
> with open('/etc/passwd', 'r') as f:
> for line in f:
> print line
> ... more processing code ...
> except ExceptionsOnOpening :
> ... exception handling
Torsten Marek wrote:
>> try :
>> with open('/etc/passwd', 'r') as f:
>> for line in f:
>> print line
>> ... more processing code ...
>> except ExceptionsOnOpening :
>> ... exception handling
>> except :
>> ... exceptions inside the for
>>
>>
>>
>> Whereas
On Mo, 2008-01-07 at 21:15 -0300, Ricardo Aráoz wrote:
> Kent Johnson wrote:
> > Ricardo Aráoz wrote:
> >> PEP 0343 is not an
> >> example of clarity in the definition of a statement, it mixes
> >> justification with historic development with definition with actual
> >> equivalent code. Couldn't o
Kent Johnson wrote:
> Ricardo Aráoz wrote:
>> Kent Johnson wrote:
>>> from contextlib import nested
>>> with nested(open_file(self.direcciones), open_file(self.excluidas))
>>> as (fIncl, fExcl):
>>>
>> Nice! How would you add exception reporting to this?
>
> I don't have a good answer to tha
Kent Johnson wrote:
> Ricardo Aráoz wrote:
>> PEP 0343 is not an
>> example of clarity in the definition of a statement, it mixes
>> justification with historic development with definition with actual
>> equivalent code. Couldn't or wouldn't bother to understand it.
>
> Here is a better starting p
Ricardo Aráoz wrote:
> Kent Johnson wrote:
>> from contextlib import nested
>> with nested(open_file(self.direcciones), open_file(self.excluidas))
>> as (fIncl, fExcl):
>>
>
> Nice! How would you add exception reporting to this?
I don't have a good answer to that, that's why I didn't propos
Ricardo Aráoz wrote:
> PEP 0343 is not an
> example of clarity in the definition of a statement, it mixes
> justification with historic development with definition with actual
> equivalent code. Couldn't or wouldn't bother to understand it.
Here is a better starting point:
http://docs.python.org/w
Kent Johnson wrote:
> Jeff Younker wrote:
>
>> Or if you're using python 2.5 then you can use with statements:
>>
>> from __future__ import with_statements
>> from contextlib import closing
>> ...
>> def mails(self):
>> with closing(open_file(self.direcciones)) as fIncl:
>>with clo
Jeff Younker wrote:
>> Maybe it is my poor understanding of exception handling. My intention
>> here is to open the first file, if error then report in logging and
>> finish normally, else open the 2nd file, if error then report in
>> logging
>> close the 1st file and finish normally. If no error
Jeff Younker wrote:
> Or if you're using python 2.5 then you can use with statements:
>
> from __future__ import with_statements
> from contextlib import closing
> ...
> def mails(self):
> with closing(open_file(self.direcciones)) as fIncl:
>with closing(open_file(self.excluidas))
>
> Maybe it is my poor understanding of exception handling. My intention
> here is to open the first file, if error then report in logging and
> finish normally, else open the 2nd file, if error then report in
> logging
> close the 1st file and finish normally. If no error then process.
>
Right
Ok, now the "tested" version (has been corrected) :
#!/usr/bin/env python
import time
import smtplib
import email
import ConfigParser
import logging
class Mensaje(object) :
def __init__(self) :
cfg = ConfigParser.ConfigParser()
try :
cfg.readfp(open('config.cfg'))
Jeff Johnson wrote:
> I would like to "butt" in here and mention that this is some of the most
> useful information I have seen! I am a programmer of 25 years that is
> new to Python. This type of back and forth dialog on actual production
> code is extremely useful to learning the language.
Ok, new version.
In procesar() I tried getting rid of the outer try block and having
'return' instead of 'raise' in the inner try blocks but I didn't like
the result. I'd rather have one more indent level but have only one exit
point from the function.
Redesigned class Mensaje so that it now includ
Kent Johnson wrote:
> Ricardo Aráoz wrote:
>> Jeff Younker wrote:
>
>>> The enclosing try block isn't needed. More on this later.
>
>> Maybe it is my poor understanding of exception handling. My intention
>> here is to open the first file, if error then report in logging and
>> finish normally,
Ricardo Aráoz wrote:
> Jeff Younker wrote:
>> The enclosing try block isn't needed. More on this later.
> Maybe it is my poor understanding of exception handling. My intention
> here is to open the first file, if error then report in logging and
> finish normally, else open the 2nd file, if erro
Jeff Younker wrote:
> The procesar function is complicated. It tries to do several things
> that that are better done elsewhere. It needs to be broken up into
> several functions and methods. This also clarifies and isolates the
> exception handling.
>
>> def procesar(mensaje):
>>try :
>
The procesar function is complicated. It tries to do several things
that that are better done elsewhere. It needs to be broken up into
several functions and methods. This also clarifies and isolates the
exception handling.
> def procesar(mensaje):
>try :
The enclosing try block isn't need
I would like to "butt" in here and mention that this is some of the most
useful information I have seen! I am a programmer of 25 years that is
new to Python. This type of back and forth dialog on actual production
code is extremely useful to learning the language. I have done this
with Ed Le
Kent Johnson wrote:
> Ricardo Aráoz wrote:
>> Ok, here is a corrected new version, I hope.
>>
>> Kent, the fact that Mensaje.__init__ reads the message configuration is
>> by design (it's a feature, not a bug ;c) ).
>
> You misunderstood my suggestion. I would add a method to Mensaje that
> creat
Ricardo Aráoz wrote:
> Ok, here is a corrected new version, I hope.
>
> Kent, the fact that Mensaje.__init__ reads the message configuration is
> by design (it's a feature, not a bug ;c) ).
You misunderstood my suggestion. I would add a method to Mensaje that
creates the email.MIMEMultipart.MIME
Ok, here is a corrected new version, I hope.
Kent, the fact that Mensaje.__init__ reads the message configuration is
by design (it's a feature, not a bug ;c) ). The class is meant to be
instantiated for using only once and with only one configuration and one
message so including the configuration
Thanks everyone for your feedback. I'll correct the code and re-post it.
___
Tutor maillist - Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
Ricardo Aráoz wrote:
> except Exception, e :
> logging.error('No pude leer "config.cfg" : %s', e.strerror)
You might like to use
logging.error('No pude...', exc_info=True)
which will include the full traceback in the log. You can use the
exc_info keyword with any of the lo
> This~~ works, but may be a little inefficient. Especially the double
> addr.strip() here. Given, it doesn't really matter, but I like even better
> Perhaps a use of sets here... particularly intersection somehow...
Whoops, I'm not versed in sets (blush) I meant difference_update
_
uble
addr.strip() here. Given, it doesn't really matter, but I like even better
Perhaps a use of sets here... particularly intersection somehow...
- Original Message -
From: "Ricardo Aráoz" <[EMAIL PROTECTED]>
To:
Sent: Friday, January 04, 2008 6:47 PM
Subject: [T
Considering we are reviewing programs I'd like to submit one of mine and
I would be thankful for any critic/improvement you can suggest.
My ex needs to send mails to a long list of customers, problem is that
she can not send more than 70 every 10 minutes or her ISP will consider
her a spammer. So s
28 matches
Mail list logo
