Re: [web2py] Re: wrong decisions and backward compatibility
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. +-[ 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 athttp://groups.google.com/group/web2py?hl=en. -- 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. -- 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. -- 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.
Re: [web2py] Re: wrong decisions and backward compatibility
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.
Re: [web2py] Re: wrong decisions and backward compatibility
No, you cannot rely on the user. Users are stupid. The system needs to be as simple as possible for the users to use the system to get their work done. There is no need to bother the user with Form errors: Value must be uppercase. This wastes the users time to have to remember to input in upper case. You could also argue that there are lots of functions in django that don't do what you expect them to do. We can't change documented functionality of web2py just because one user does not expect it to work the way it does. The keyword here is documented, IS_UPPER is documented to act this way. using strict=True is good. but how can we assure this change does not get lost in the google group never to arise again until you look at the source code and realize its there. -Thadeus On Sun, Feb 7, 2010 at 8:32 PM, mdipierro mdipie...@cs.depaul.edu wrote: We could add an option like strict=False that if true does what you ask. 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 athttp://groups.google.com/group/web2py?hl=en. -- 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. -- 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.
Re: [web2py] Re: wrong decisions and backward compatibility
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 athttp://groups.google.com/group/web2py?hl=en. -- 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. -- 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.
Re: [web2py] Re: wrong decisions and backward compatibility
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. -- 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.
