On Sat, May 23, 2009 at 11:34 AM, 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(...)
I think the argument of terseness is the wrong argument here....
I do not like terse if it obfuscates intent (it _has_ to be readable).
I think what is the strongest argument here, Massimo, is what you say
but NOT because it is shorter
RATHER because it is EASIER TO READ THE CODE AND UNDERSTAND THE INTENT
The problem which remains is this:
- Given the two idioms presented above, the first is clearly more readable;
- BUT WHO WILL THINK TO WRITE THIS WAY?
So we are introducing a new programming pattern - a class that has one
(trivial) extension.
I would like to consider if "List" is the strategically correct thing to
extend;
What about extending storage-class deque instead?
A storage-deque class with this behavior seems like it would be more
appealing.
Thoughts?
>
>
> 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
-~----------~----~----~----~------~----~------~--~---
