Hang on, not sure if we're talking about the same thing. Style, as in
preference of 'if' over 'try' is okay to discuss (although I think
*forcing* people to use 'if' is wrong). This proposed change, however,
inherently BREAKS backward compatibility, as seen from my example, for
anybody using the EAFP approach (myself included). That was my first
concern. Are we okay with this breakage ?
On May 23, 6:34 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> request.args is a special list anyway because it could be made
> readonly and because its elements can only be non-empty strings. This
> is why I have difficuly seeing how this will create conflicts.
>
> I like the fact it would allow to do
>
> record = db.table[request.args[0]] or redirect(...)
>
> when you expect a valid record_id in request.args[0]. It is much
> shorter than
>
> record = db.table[request.args[0] if request.args else None] or
> redirect(...)
>
> which would not work on python 2.4.
>
> List only breaks checking for existence using try/except but using try/
> except to determine whether args[i] is a valid argument is not a good
> programming style in my opinion (although I am as guilty of using it
> as anybody else).
>
> Let's wait for more comments anyway.
>
> Massimo
>
> On May 23, 11:15 am, AchipA <attila.cs...@gmail.com> wrote:
>
> > Env and vars are somewhat different, being dicts. The Proper (TM) way
> > for those would be target = request.vars.get('myoptionalvar', None).
> > The reason this is the Proper (TM) way is that you *have* to know when
> > you're handling undefined data (is that a None ? Or a '' ? Maybe 0 ?)
> > You can't just throw in a None in a middle of a controller and hope it
> > works out (often trading an IndexError for an even harder to debug
> > 'unsupported operand type for None'. That would be the PHP way. Easy
> > on beginners - yes, effect on code quality - terrible. But let's wait
> > on further comments.
>
> > On May 23, 5:42 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > > yes but we do this already for request.vars and request.env
>
> > > anyway, I am not sure about myself about this. Let's here a few
> > > comments about this can I can revert it.
>
> > > Massimo
>
> > > On May 23, 10:29 am, Alexey Nezhdanov <snak...@gmail.com> wrote:
>
> > > > On Saturday 23 May 2009 18:42:58 AchipA wrote:> Tt does break existing
> > > > properly written python code (and is very non-
> > > > > pythonesque).
>
> > > > +1 except for harshness. Masking exceptions is a BAD THING (TM)
>
> > > > > Think:
>
> > > > > try: target = request.args[0]
> > > > > except:
> > > > > response.flash = 'No target specified'
> > > > > return
>
> > > > > do_something(target)
> > > > > If this is an issue for people, I think they should improve their
> > > > > python skills (learn exceptions, for arg in request.args constructs),
> > > > > and not fight the language by framework-specific workarounds. They
> > > > > will benefit from it much more on the long run (as they are bound to
> > > > > have the same IndexError or KeyError problem anyway, just someplace
> > > > > else). My 0.02c.
>
> > > > --
> > > > Sincerely yours
> > > > Alexey Nezhdanov
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
