Thadeus - I initially commiserated with you: "backward compatipility is backward compatibility" --- but I alwasy thought Massimo held on to that phrase too strongly, too tightly. It's important for the "big" things, but it _always_ gets in the way of meaningful, useful change...
I think perhaps Massimo's bordering on being dogmatic about "backward compatibiliy" may have an affect on how people react to this. But Jonathan gives an important insight: "I always specify zero=..." Even as "zero=..." didn't exist before, it's easy enough to do globeal search and modify to put it in - it's _really_ not a big deal; it's one of those things where dogmatically holding to the "compatability principle" is more trouble than adapting to this change. If it was happening all the time, often... this would be annoying; but occasionally, it is more than tolerable - it can even be a good thing, in the big scheme of things. You are, of course, free to see it in whatever way you happen to see it. I'm just offering a summary of a counterpoint for consideration. Kind regards, Yarko On Mar 23, 2:22 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > weheh, Massimo, > > The issue is the same for me, I have several web2py applications, each > commanding over 20 forms which make use of IS_IN_SET. I am dealing > with a sizable number of forms that I need to update just to fix this. > The fact is that web2py changed the output of how drop boxes are > rendered, and in turn it has broken my forms that relied on the first > element being selected. > > Aside from the time to alter my forms, this is an issue of promise, > and principle that separate web2py from other python frameworks. To > take a few quotes and give my interpretations of them. > > "" Another feature of web2py, is that we, its developers, commit to > maintain backward compatibility in future versions. We have done so > since the first release of web2py in October, 2007. New features have > been added and bugs have been fixed, but if a program worked with > web2py 1.0, that program will still work today. "" - Massimo Di > Pierro, Web2py Book, Chapter 1, Introduction > > This is the kicker, my programs no longer "work" as intentionally > designed. Perhaps you should re-word this as "will still > compile/execute/not crash" instead of "work". > > ""web2py has never broken backwards compatibility, and it will not > break compatibility when additional functionality is added in the > future. "" - Massimo Di Pierro, Web2py Book, Chapter 1.4, Why Web2py > > The definition of compatibility is very loosely defined. This quote is > in response to the one made that "web2py never controlled this before, > now it is". Regardless of if web2py controlled something previously or > not, it cannot change the compatibility with older versions. > > Given the scope of the web2py applications that I develop, and the > sheer principle of the matter, do you understand where I am coming > from? > > I seem to be left with the following options > > A) Update my 100+ forms and set zero=None. I view this as a complete > waste of my time, either manually or working a search/replace and then > re-testing all of my forms. > B) Use a patched version of web2py that does what I want, zero=None. > This is not a desired option since keeping up with updates gets quite > complex when branching the codebase (DVCS or not). A continuous waste > of my time. > C) Re-define IS_IN_SET in one of my models, however since web2py now > assumes* requires, I need to make sure and define this for my foreign > key relationships, since sql.py uses the imported version of IS_IN_SET > instead of the global version. > > * I could also make the same argument for this as it did change the > functionality of forms that used to render as text boxes but now > render as select since they are FK relationships. > > -Thadeus > > On Tue, Mar 23, 2010 at 1:29 AM, weheh <richard_gor...@verizon.net> wrote: > > Thadeus, it's 6 of one, half-dozen of the other to me. I use both. So > > in theory, it doesn't really matter which is the default. Therefore, I > > prefer that the default remain whatever it currently is so that I > > don't have to change any of my code. > > > -- > > 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.
