It is not so trivial to search and replace. For one, you cannot place keyword arguments before non-keyword args. So it is not a simple matter of find/replace IS_IN_SET(... with IS_IN_SET(zero=None..., there will have to be parsing of the syntax to determine where to place zero=.
I am perfectly capable of making the changes, and most likely will. Other frameworks, have version upgrades that happen once a month at the very least frequency, with migration guides, change logs, and previous version supported bug fixes. Web2py cannot do this, for one the development cycle is more along the lines of hours/days instead of months, there are no migration logs, there are no change logs, there is no point of reference for upgrading version to version. As I have asked before, if Massimo would place an operational definition of "backwards compatibility" in the context of web2py, otherwise it is open to interpretation, and will be judged as those interpretations are assumed. If you are going to set a standard and a promise, you either define the parameters of that standard, or uphold it to the highest and most rigid interpretations. Here we realize the reason for religious debate and war, the absence of scientific definitions that allow individuals from all walks of life to understand from the same perspective and context. My interpretation is of not having to change a line of code to upgrade my application and have it look _exactly_ the same after the upgrade. The majority of use cases is 50/50 and depends on the context of the form. Even for me, the use cases differ from hobby applications to professional applications. -Thadeus On Tue, Mar 23, 2010 at 2:54 AM, Yarko Tymciurak <resultsinsoftw...@gmail.com> wrote: > 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. > > -- 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.
