On Nov 19, 2010, at 5:57 PM, Chris McDonough wrote:
> AFAICT, matching and conversion are totally separate concepts. Despite
> some conversions having a relationship with some matchings, there are
> times when you want a match filter without a conversion, and vice
> versa. And there are times when you don't want to stop to create a new
> converter just to make a matching assertion.
That's true, so declaring a match assertion should prolly always be an option.
On the other hand, the performance freak in me is screaming that we shouldn't
be running all these converter predicates without easily screening out more
cases where the converter shouldn't even bother.... that a match assertion
could've stopped.
> If we consider conversion-marker-in the pattern a must-have (I don't
> think it is TBH, because we already have it via custom route
> predicates), whatever solution we come up with should take into account
> the case of someone just wanting to do an unanticipated matching
> (probably via a regex) without stopping to create a converter/matcher
> utility.
Actually, routehelper was going to pre-parse the pattern for
conversion-marker-in-pattern and toss in the appropriate marker._regex and then
put a matching predicate for the converter into the route predicates. But
calling more functions for *every single route* when a simple regular
expression bit that was already called to match.... could've kicked it out.
It's just such horrible inefficiency I could never in good conscious propose
anyone actually use it.
Saying something like:
def month_converter(value):
min = 1
max = 12
value = int(value)
if min <= value <= max:
return value
r = routehelper(config, converters=dict(int="\d+", month=my_month_converter)
r.add_handler('articles', '/articles/{action}/{id:int}', handler=....)
r.add_handler('month_archives', '/archives/{month:month}'...)
Routehelper would then take:
'/articles/{action}/{id:int}'
And turn it int '/articles/{action}/{id:\d+}', and then attach a custom
predicate that will call the int converter. So route helper is merely acting as
a macro system to make doing a bunch of those conversion a simple matter rather
than building up lists of custom predicates (running O(n) with n as the amount
of parts, UGH).
Every little bit at this level will be multiple a ton as the resource macro and
other ppl do things adding a bunch of routes. Adding 2, then 3, then 5 function
calls per missed route is going to be bad bad bad for performance. I really
don't want the routing system to be so horribly inefficient. Maybe a little of
this might be premature optimization, but I've seen a lot of use-cases in the
wild that leads me to believe the way people will actually use it will result
in horrible inefficiencies unless the system can streamline it some.
Sure, every route could have a custom predicate list of a half dozen functions,
multiple that by the amount of routes... and... ugggggg. I really don't want to
think of the inefficiency we're talking about.
That's really the main reason I'd like a 'converter' to be able to specify a
regex for its part so you didn't have to manually type it over and over again.
I don't want to be typing it over and over again, and its nice to have the
converter specify some basic minimum set of requirements that can be taken care
of in the regex match *before* all the conversion processes actually run.
Cheers,
Ben
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-de...@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
