--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-appengi...@googlegroups.com.
To post to this group, send email to google-a...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-appengine?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Python 2.5 applications are no longer officially supported on the new Development Server in line with our deprecation announcement (although they may still be run)
--
If you'd like to take a look now, I would point you to this discussion https://code.google.com/p/appengine-devappserver2-experiment/issues/detail?id=28 and in particular the document linked there that summarizes our proposed debugging approach and provides some sample code to get started.
No one forces anyone to use anything, you can always use previous versions of SDK/Devappserver
They've stated why It's currently not possible to debug with devappserver2, as someone watching the development of devappserver2 closely, I'm sure they will come up with a way to satisfy your debugging needs in future - if possible
I think the illogical-thing to do, at this point, is to bundle the latest version of Devappserver1 with SDK and provide it as an option, but depreciate it at the same time, would solve all current problems
( Apart from all this, as a personal opinion: I've never used a debugger, used many languages, I find print/log statements much more useful, especially with a language like python )
--
- We’ve cleaned up many command line flags and arguments
In the 1.7.6 release of App Engine we’ve included a major upgrade to the Development Server in the Python SDK, designed to make development faster and more faithfully reproduce the production App Engine runtime environment. The new version more faithfully simulates elements of the production App Engine environment, such as concurrent requests and backends, and in most cases this will also mean your apps run faster. We previously included this in the 1.7.5 release as dev_appserver2.py, in this release it has become the default dev_appserver.py
While we're confident the improvements are substantial, as with any major change, some things work a little differently with the new dev_appserver. Here’s a few changes to watch out for:
- Your local development admin console will run on it’s own server and port, rather than under /_ah/admin
- We’ve changed the defaults for new applications, such as using HRD rather than Master/Slave, and using SQLlite to emulate the datastore.
- We’ve cleaned up many command line flags and arguments
- Python 2.5 applications are no longer officially supported on the new Development Server in line with our deprecation announcement (although they may still be run)
Good news everyone!
We just wanted to give you a quick update on PDB debugging support in the new dev_appserver.
One of the key design goals of the new dev_appserver was to provide a more faithful emulation of how your application performs in production - including servicing each incoming request in a separate thread or process. This not only makes your local development faster, but also means issues (such as race conditions) that may arise from concurrent requests executing in parallel can be more easily identified and corrected.
However a development environment with multiple concurrent threads and processes can present a challenge when using a command line debugger such as PDB. We’ve been working on reconciling our design goal of a dev_appserver that supports production-like concurrency while still allowing developers to use tools like PDB to introspect and debug their code in a sensible, serialised way.
We’ve made some progress on this front recently, and wanted to share it with you.
The latest release 1.8.3 of the Python SDK supports PDB. That is you can add a line such as:
import pdb; pdb.set_trace();
into your code, and dev_appserver2 will break at this point, and drop into the PDB REPL, allowing you to debug your code from the command line.
However, a note of caution - if you make multiple simultaneous requests that invoke pdb.set_trace(), then two debugging sessions will start concurrently and both will send output to STDOUT. This can lead to unpredictable debugging experiences.
To help prevent this, you can also disable some of the dev_appserver’s multi-threading and multi-processing support.
Multi-threading can be disabled by modifying your app.yaml and setting thread_safe to false.
For a given module, you can disable multi-processing using the --max_module_instances=1 flag.
Using these techniques you can serialize your requests. Note that, if you are using App Engine modules in your application, the dev_appserver will still serve multiple requests simultaneously for different modules.
We hope you enjoy this early support for pdb in dev_appserver2. Please let us know what you think.