On Feb 8, 2010, at 12:59 AM, KONTRA, Gergely wrote: > Hi! > > Yes, I must admit it, that a validator like IS_UPPER(), which checks > only whether the input is uppercase is less useful, than an another, > which actually converts to uppercase. > > OTOH if you haven't used the function, you expect the former.
It might be appropriate to provide aliases for filter-only validators along the lines of TO_UPPER(), change the docs, and deprecate IS_UPPER() on the grounds of ambiguity. But I don't see a motivation for changing the semantics of IS_UPPER(), since there's no real benefit to be had, and it would break a lot of existing code. Notice that some validators do both. That is, they validate their input, and also transform it. This is one of those cases where it's advisable for a developer to read the docs. > > +-[ Gergely Kontra <pihent...@gmail.com> ]------------------+ > | | > | Mobile:(+36 20)356 9656 | > | | > +- "Olyan lángész vagyok, hogy poroltóval kellene járnom!" -+ > > > > On Mon, Feb 8, 2010 at 04:17, Jonathan Lundell <jlund...@pobox.com> wrote: >> On Feb 7, 2010, at 6:32 PM, mdipierro wrote: >> >>> We could add an option like "strict=False" that if true does what you >>> ask. >> >> What's the use case? I'm having trouble seeing what such an option would do >> for you. >> >> Sure, IS_UPPER() should probably have been named TO_UPPER(). But at this >> point.... >> >>> >>> On Feb 7, 8:22 pm, Iceberg <iceb...@21cn.com> wrote: >>>> But in this case (provided that we really change IS_UPPER() as >>>> Pihentagy suggested), you can rely on the human, because they can not >>>> input lower case. Your app still need not to edit a single line. :) >>>> >>>> Well, sounds like I support changing IS_UPPER() 's behavior. But >>>> actually I am neutral to this proposal. >>>> >>>> On Feb7, 3:24pm, Thadeus Burgess <thade...@thadeusb.com> wrote: >>>> >>>>> It will break backwards compatibility. >>>> >>>>> I have apps that rely on the functionality of IS_UPPER applying >>>>> .upper() to the incoming variables. Anything that requires me to edit >>>>> a single line of code on my app to just upgrade web2py breaks >>>>> backwards compatibility, unless it was a bug to begin with. >>>> >>>>> -Thadeus >>>> >>>>> On Sat, Feb 6, 2010 at 11:33 PM, Iceberg <iceb...@21cn.com> wrote: >>>>>> @Pihentagy: >>>> >>>>>> Besides, the current IS_UPPER() (and IS_LOWER()) is not that bad, >>>>>> IMHO. What is the real difference between alarm end user to change his >>>>>> input into upper case, or just silently change his input into upper >>>>>> case? >>>> >>>>>> To say the least, we can really change IS_UPPER() to just warning, and >>>>>> perhaps another UPPERCASE() to uppercase. As long as the old apps do >>>>>> not really break, but just sightly change its behavior in acceptable >>>>>> range, I consider web2py is still backward compatible. >>>> >>>>>> About web3py, Renato says all. :) >>>> >>>>>> On Feb6, 8:24pm, Renato-ES-Brazil <renatoa...@gmail.com> wrote: >>>>>>> Web3py is an alternative, check this: >>>> >>>>>>>> When GAE moves to 3.0 and the database drivers for all supported >>>>>>>> backends become available we will release something like web3py (TM). >>>>>>>> Since we are going to break language backward compatibility that will >>>>>>>> also be a good time to include other non-backward compatible changes. >>>>>>>> 2010-2011 are reasonable dates but just a guess. >>>> >>>>>>> URL:http://www.mail-archive.com/web2py@googlegroups.com/msg09344.html >>>> >>>>>>> On 6 fev, 08:12, pihentagy <pihent...@gmail.com> wrote: >>>> >>>>>>>> Hi! >>>> >>>>>>>> Looking into the code of IS_UPPER I realized, that this function does >>>>>>>> not do, what I expect to do. >>>>>>>> I thought it only allows strings, which does not have lowercase >>>>>>>> letters, but it actually converts the string to uppercase. >>>> >>>>>>>> Since web2py promises backwards compatibility, and here IMHO this >>>>>>>> method is mis-named, how would you solve the situation? >>>> >>>>>>>> BTW when I come across the fact, that web2py will be always backwards >>>>>>>> compatible, a loud alarm began to horn in my head: then how would you >>>>>>>> maintain the code in 2, 3, 10 years? It will blow up. >>>> >>>>>>>> Or, when it becomes hard to maintain, you began a new project named >>>>>>>> web3py? :) >>>> >>>>>>>> Gergo -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@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.
