On Monday March 23, 2009 16:58:17 Jorge Vargas wrote: > On Mon, Mar 23, 2009 at 8:02 AM, Gustavo Narea <[email protected]> wrote: > > On Monday March 23, 2009 07:29:54 Jorge Vargas wrote: > >> Please explain me why this is API change? > >> <snip> > >> please tell me how the calling code changes from A to B ? It doesn't! > >> so please do not say that is an api change, it isn't. > > > > I repeat: If you add two public modules and two public functions, then > > you're changing the API. I'd say it's pretty obvious. > > then stick a _ in there and add a __all__ and they are not "public" > anymore, you can't seriously think they are "public" api in python > there is no such thing about that. And those functions are never > called from the outside unless you are doing something special (like > pages, which is a prototype of a tg2.1 app)
By "public" I meant user-accessible, not the sense of "public" in programming languages like Java or PHP. Every single function/class/module in quickstarted applications are public because they are all user-accessible. So, if you add functions and modules, they'll be public. And if they're public, you _modified_ the API to add services. > > You seem to believe that API change == backwards-incompatible change, and > > you'd be wrong. You can make backwards compatible changes in the API -- > > for example, the one we're talking about. > > I have never seen adding a method as a bad API change, if you use it > it's because you need it if you don't use it then what's the big deal? Heh... Now you're implicitly accepting it was an API change, but not a bad one. ;) I agree, it's not bad, but it's late to go in TG 2.0. > > My point is that it's an API change and that always outdates text written > > relying on the part of the API that changed. Period. I didn't say that > > function has to be called differently since that change. > > how? did you quoted the whole file in the article? that's the only way > I can see that your "text is outdated" if you simply said "now add to > your websetup at the end of it the following code" they should be no > outdated article. You're talking about my article in particular, while I'm talking in a more general sense: If you change an API, it's *very* likely that you'll outdate somebody else's text on the part of the API that changed; I'd say that's a rule of thumb. Regarding my article in particular, I explained what the "websetup.py" file was for and also asked to add some lines in setup_app() (referring to the file as "websetup.py"). > >> The only think that could be affected by that change is that if you > >> told someone to edit websetup.py instead of websetup. > > > > Why? Because it's an API change! > > YES, which I propose a way to fix that and you totally ignored it on > your response. At last! You accepted it was an API change! And apologies, I slipped in that part while trying to trim the email. My thoughts on your proposal: 1.- It'd still be an API change, it just happens to be smaller: no new modules, but two new functions. 2.- It'd still outdate some texts, like mine where I say something like "Add the contents of Listing N right before DBSession.flush() and commit()". > > For your information, those three items were taken as *blocker* *issues* > > and I had *explicit* *permission* to implement them right away. > > The above *also* had *explicit* permission, just look at the top of > this thread. that's everyone saying +1 ... until we saw what the change was exactly about... > >> so what's it going to be are we willing to "lose" all the last changes > > > > Will you continue referring to moving that enhancement to 2.1 as a "lost" > > or "discard"? > > yes you will lose it for 2.0. "For 2.0", yes, that is accurate. > >> (and confuse everyone running trunk) > > > > Confuse everybody running trunk? Here and in every single project it's > > more than explicit that if you use the mainline development, you'd be > > doing it at your own risk. > > not if you are careful a ton of projects are very trunk stable and I > believe TG is one of those. Here and _everywhere_ "trunk" is a "use it at your own risk" branch. That developers are committed to keep it stable is another topic. > > So that's not a reason to be taken into account. > > > >> or we are going to look for a solution? > > > > I think that's what we're doing. > > I think not, as your last response was a full "complain" of everything > I got "wrong" and yet it seems you skip the sole paragraph where I > proposed a solution that will get everyone happy. Sorry again, above I explained what happened. And it doesn't make everybody happy. Cheers. -- Gustavo Narea <xri://=Gustavo>. | Tech blog: =Gustavo/(+blog)/tech ~ About me: =Gustavo/about | --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
