Dan Sanderson: Thanks for the nice feedback and understanding.
We need to have a smart way of maintaining versions. What if Google Upgrades the version of Python Intrepreter to a higher version when the code is written for lower version? We see Deprecated modules changing between higher versions. You think we need to store our own Python binaries of that version to keep it running? I have a very basic question, What happens if there is a bug (BETA) in GData module and the website is not updated with that gdata update. 1. Do they have to shut the website down? 2. What if someone exploits of a known bug and misuse the poor website infrastructure, why you make the user as a victim of such happenings. If someone want to use higher version of the API, we need to come up with a solution of Managing different versions. like, import gdata2 to use the extra facilities offered by gdata higher versions. I'm not discussing about integrating a third party module. It is their own services and accessing their own products, mounting extra work to it in the user side in maintaining the version of the code. What a service :) /Kannaiyan On Nov 4, 9:23 am, Dan Sanderson <[EMAIL PROTECTED]> wrote: > On Mon, Nov 3, 2008 at 11:42 PM, Kannaiyan <[EMAIL PROTECTED]> wrote: > > As a software developer I would allow users to reuse the same code. I > > won't make million copies of the same code. (If used by millions of > > people). If Python does not allow such sharing model, then the > > language is a total CRAP. > > Bundling a bunch of libraries with the runtime environment could be a bad > idea in the long run. For example, consider the case where version 1 of the > runtime environment includes version 1.0 of module A and version 1.0 of > module B, and you write an app that uses these modules. Then later, App > Engine releases version 2 of the runtime environment, which includes version > 2.0 of module A and version 2.0 of module B. Perhaps your app is > incompatible with module A v2.0 and would take several weeks to port, but > there's nothing in A v2.0 that you need so you'd prefer to just stay with A > v1.0. But you desperately need a feature in module B v2.0. > > Thankfully, in Python it's easy to stay with version 1 of the runtime > environment then add your own copy of B v2.0 to your app. But you can > imagine that with many modules and many versions, this could get extremely > difficult to manage very quickly, and you'll soon be including all of your > dependencies with your app. > > Bundled libraries make it easy to get started, and it's a good suggestion > for App Engine to include the gdata library with the runtime as a starting > point. Feel free to create an issue in the issue tracker for this. But > beyond getting started, you probably won't want to use bundled libraries. > > -- Dan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en -~----------~----~----~----~------~----~------~--~---
