ok, I think I found a better solution:
request.args stays as originally was
but I will also define
request.arg0 as request.args[0] or None
request.arg1 as request.args[1] or None
request.arg2 as request.args[2] or None
Massimo
On May 23, 12:13 pm, Yarko Tymciurak <yark...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
