On Mar 23, 4:22 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > 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=.
yes, I suppose it would need some way to find the balancing paren, in general, to correctly accomplish this (and it might not be on the same line)... You are right - this can be a real pain... > > 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. Yes, I think I agree - having a migration guide would have considered the impact of this kind of change... Of course, having a central repository of "free apps", and migrating them would help... As it is, many of those "free apps" are no more than store-front dressing: hit-or-miss as to which ones will work out of the box. At least testing would facilitate saying things like "ltest web2py tested with: xxxx" - Yarko > 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 > > 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.
