PyDev adventures (original) (raw)

tag:blogger.com,1999:blog-85509622026-03-18T04:40:01.106-07:00PyDev adventuresPosting about venturing (and creating) PyDev.

LINKS: PyDev.org Blog RSS Twitter RSS

I just stumbled upon a code in Python that uses a simple `Path(...).resolve()` after receiving a path in an API and suddenly reminded myself on the many the bugs I've tripped over due to it, so, decided to share  why I hope at some point this function stops being so pervasive as it's usually the wrong thing to call.. (maybe because when Python went from os.path to pathlib they added no real replacement and now you need to use both).

The main reason of bugs for that is that when you call Path.resolve() it'll actually resolve symlinks (and substs on Windows).

This means that if the user crafted some structure as

/myproject

/myproject/package.json

/myproject/src -> symlink to sources in /allmysources/temp

 If you resolve `/myproject/src/myfile.py` to `/allmysources/temp/myfile.py` and actually want to get to the `package.json`, it'll never be found!

 I was even looking at the python docs and found this nugget when talking about `Path.parent`:

If you want to walk an arbitrary filesystem path upwards, it is recommended to first call Path.resolve() so as to resolve symlinks and eliminate ".." components.

And that's completely why you shouldn't use it because if you do, then the parents will be completely off!

So, what should you do?

Unfortunately pathlib is not your friend here, you need to use `os.path.normpath(os.path.abspath(...))` to remove `..` occurrences from the string and make it absolute (and then after, sure, use pathlib for the remainder of your program) -- possibly you even want to get the real case in the filesystem if you're on Windows (which is very annoying as then you end up needing to do a bunch of listdir() calls to get the case stored in the filesystem).

 -- but also, keep in mind you usually just need to do that on boundaries (i.e.: when you receive a relative path as an argument in the command line for instance, not when you receive an API call from another program -- chances are, the cwd of that program and your own are different and thus calls to `absolute()` or `resolve()` are actually bugs).

But isn't there any use-case for `Path.resolve()`?

As far as I know, the only case where it's valid is if you do want to create a cache of sorts where any representation of that file is considered the same (i.e.: you really want the canonical representation of the file). 

Say, in an IDE you opened your `subst` in `x:` and then you have `c:\project\foo.py` and `x:\foo.py` in a debugger and you want to always show the version that's opened under your IDE, you need to build that mapping so that regardless of the version that's accessed you will open the version that's being seen in your IDE (and oh my god, I've seen so many IDEs get that wrong and the effect is usually you'll have the same file opened under different names in the IDE -- I know that in the pydevd debugger this is especially tricky because the name of the file is gotten from a .pyc file, which depends on how it was generated and the cached version may not match the version that the user is currently seeing -- the  debugger goes through great lengths to have an internal canonical representation and a different version which should be what the user sees, but it's not perfect and IDEs which actually open the file afterwards don't make the due diligence to try to do the proper mapping afterwards -- even worse when they fail because the path is the same but the drive is uppercase and internally the path they have has the drive in lowercase).

Maybe even then it'd be better to use the inode of the file for a reference (gotten from `Path.stat()`)...

Anyways, to sum up, in its current format, I'd just recommend to ALMOST NEVER use `resolve()` as it's usually just the source of bugs, keep to `Path(os.path.normpath(os.path.abspath(...)))` on program boundaries as that's just saner in general (and when you want to pass files among APIs, make sure paths are already absolute and normalized and fail if they aren't).

p.s.: just as a disclaimer, I've also seen a very minor subset of users on Linux (just one so far really, but maybe there are others that want that behavior out there) that say they want the symlinks resolved as the created structure they have is always final and the symlinks are just a commodity to avoid having to cd into that structure so that they can freely cd into symlinks (and as such they don't want to affect the structure when they created symlinks), but I don't think this is the most common behavior (and if it is, then programs probably need to have a flag determining on whether to use it or not (for instance, I know vite from javascript has a resolve.preserveSymlinks setting so that the user can decide if they want it or not) -- although it's also true that most users don't even care, because they don't put their source code in a symlink or Windows subst 😊

The latest release of PyDev (12.0.0) is now available and it brings a really nice speed improvement for those who are already in Python 3.12! -- If you're a LiClipse user, it's now available in LiClipse 11.

The PyDev Debugger now uses sys.monitoring, which enables faster debugging (on my tests it can be up to 15 times faster than the version using sys.setttrace, depending on the use case -- kudos to Mark Shannon for PEP 669 😉).

It took me a while to cover the many scenarios that pydevd deals with, but the good thing is that most of the infrastructure available in pydevd didn't need changes (the debugger already had all the concepts needed as it already tried to trace only the frames which were actually needed, which definitely helped a lot as this is now pretty central in how to deal with the tracing using sys.monitoring)

Given that it's now out, I'll talk about how it works and some of the caveats when using it.

So, the first thing to note is that PEP 669 defines a bunch of callbacks which are now related to the code object (and not the frame as happened with sys.settrace) and when inside one of those callbacks the debugger can react to decide what should happen.

Some things that could happen could be pausing due to a breakpoint or a step instruction or deciding that the given code should not be traced again (by returning a DISABLE).

The reason it becomes faster than the previous approach is that the DISABLE is then considered by the Python interpreter which then bakes that DISABLE into the code when it's executing (up until sys.monitoring.restart_events() is called again). This does come with a big caveat though: if there are multiple threads running the program and one of those threads returns a DISABLE instruction then the related callback will actually be disabled for all the threads. Note that if DISABLE is not returned, the speed ends up being close to what was available with sys.settrace (which wasn't all that bad in pydevd already, but definitely a step down from what is now available).

This means that the debugger is really much faster when going for a breakpoint (because it can DISABLE many of the tracing instructions), but after a breakpoint is hit, if one thread is doing a step operation, then the speed reverts back to being close to the sys.settrace variant (the debugger can still DISABLE tracing for places it knows the user never wants to stop, but it cannot DISABLE the tracing for any code in any thread where the user may want to stop, because the thread which is stepping could be affected by a DISABLE in another thread which is not stepping, or at least the stepping must be considered for all threads even if a given thread hasn't really stopped and is not stepping).

Also, it's worth to mention that sys.monitoring has finer grained events vs. the ones available in sys.settrace, which is good as for instance, it's possible to get events from exceptions separate from events related to entering/returning from a function or lines, which helps the debugger in tracing only what's actually needed (the tracing debugger had to do lots of gymnastics to create a separate tracer just for exceptions when there would be no need to trace a given scope for lines, so, the new code ends up being both simpler and faster).

Note however that in pydevd I've done some other improvements and stepping should be more responsive even when using sys.settrace with older versions of Python!

p.s.: the attach to process is still not available for Python 3.12. 

Note: back in the day other players which make use of pydevd such as JetBrains and Microsoft did step up to finance it, but at this point the only support it has is from backers in the community.

So, if you enjoy using pydevd please consider becoming a supporter... I've actually just setup sponsoring through GitHub sponsorships (https://github.com/sponsors/fabioz). Any takes on becoming one of the first backers there 😉?

It's been a while since I don't post, so, I decided to shed some details on what I'm working now (which I think is a really nice -- open source -- tool for the Python ecosystem -- in my view it's something close to a "Time travel debugger" for Python, although it's mostly labelled as automatic logging for Python 😄).

I'll start with a bit of history though: I'm working with Robocorp right now (Robocorp is a company which focuses on automation projects -- it leverages and provides many open source tools, especially in the Python ecosystem).

A few years back Robocorp approached me to do a language server for Robot Framework (which started as a testing framework done in Python and right now is also used for doing automations, which Robocorp recommends for many clients doing automations -- although many clients also prefer to just use Python directly). 

Now, one of the strong points of Robot Framework is that it generates an output which provides information on everything that happened during its execution (Keyword calls -- which is how "methods" are called in Robot Framework, if statements, return values, etc), so, it's almost a "Time travel" debugger as it records and shows information on everything that happened in the execution.

Now, this brings me to what I'm working right now: a library which records what happens inside a Python process -- along with a UI which makes it possible to inspect it afterwards (its the Python log counterpart of Robot Framework).

For those curious I've created a repo with one example showing the output from Robot Framework and from the one generated by the Robocorp's Python Framework: https://github.com/fabioz/log_examples.

You can also see a live example (which solves the https://rpachallenge.com/) output of Robot Framework log.html as well as the output of Robocorp's Python Framework log.html.

The easiest way to use it right now is by using the tasks from Robocorp's Python Framework (see: https://github.com/robocorp/robo/tree/master/tasks as the log will be automatically generated for tasks run through it -- mostly, mark your entry points with @task (from robocorp.tasks import task) and run with `python -m robocorp.tasks run` and get your `log.html` in the `output` showing method calls, if statements, assigns, returns, etc that happened in your run).

One question I got a few times is how does it work... Well, after working quite a bit on pydevd and debugpy one of the things scratched right from the start was trying to use Python debugger infrastructure due to a simple fact: if the debugger infrastructure was used then no one could actually debug the code while using the logging framework.

In the end, inspiration ended up coming from PyTest. p.s.: thanks to Bruno Oliveira for a discussion back in the day about how assertions were rewritten using import hooks to provide nicer messages in assertion failures in PyTest.

robocorp.log uses the same approach as PyTest (import hooks + ast rewriting), but instead of rewriting asserts it rewrites the whole method to add callbacks on what's happening.

So, something as:

roughly becomes something as:

The real output is a bit more contrived as it needs to deal with exceptions, yields, making sure the stack is correct, but I hope you get the idea.

Then, the callbacks are converted into a kind of journal of what happens and that is then fed to the log.html (the idea is having it directly in a view in VSCode in the future so that you can see the log being created in real time -- right now the info is added to a bunch of "robolog" files and embedded into the final log.html).

Now, the approach does come with one caveat: import hooks need to be setup prior to importing a module, code imported before setting it up won't be traced -- it's one of the reasons why it's recommended to use robocorp.tasks to do the launching instead of bolting the logging manually as it makes sure things happen in the proper order.

The second caveat is related to the object __repr__. The framework is quite keen on getting the representation from objects at various times, so, if the __repr__ is too slow the execution may be much slower or even worse, if it has side-effects bad things will happen (thankfully most objects do the right thing as a __repr__ with side effects is a bug and the program would misbehave on debuggers too).

The third caveat is that right now it needs to be told what needs to be traced (by default full logging is available for all code which is considered user code and libraries need to be manually specified to be logged when it's called directly from a function which is considered user code -- this may change in the future, but it's the current state of affairs).

The final caveat is that right now it'll only trace what's happening in the main thread. Other threads won't appear in the log.

Well, I guess this post is already a bit bigger than I planned so I'll stop here. For those interested in testing or reporting enhancements/bugs see: https://github.com/robocorp/robo/.

Enjoy!

 In Python asyncio land it's always a bit of a hassle when you have existing code which runs in sync mode which needs to be retrofitted to run in async, but it's usually doable -- in many cases, slapping async on the top of a bunch of definitions and adding the needed await statements where needed does the trick -- even though it's not always that easy.

Now, unfortunately a debugger has no such option. You see, a debugger needs to work on the boundaries of callbacks which are called from python (i.e.: it will usually do a busy wait from a line event from a callback registered in sys.settrace which is always called as a sync call).

Still, users still want to do some evaluation in the breakpoint context which would await... What now? Classic questions of how to go from async to sync say this is not possible.

This happens because to run something in asynchronous fashion an asyncio loop must be used to run it, but alas, the current loop is paused in the breakpoint and due to how asyncio is implemented in Python the asyncio loop is not reentrant, so, we can't just ask the loop to keep on processing at a certain point -- note that not all loops are equal, so, this is mostly an implementation detail on how CPython has implemented it, but unless we want to monkey-patch many things to make it reentrant, this would be a no-no... also, even if possible, it's not possible in asyncio to force a given coroutine to execute, rather we schedule it and asyncio decides when it'll run afterwards).

My initial naive attempt was just creating a new event loop, but again, CPython gets in the way because 2 event loops can't even coexist in the same thread. Then I thought about recreating the asyncio loop and got a bit further (up to being able to evaluate an asyncio.sleep coroutine), but after checking the asyncio AbstractEventLoop it became clear that the API is just too big to reimplement safely (it's not just about implementing the loop, it's also about implementing network I/O such as getnameinfo, create_connection, etc).

In the end the solution implemented for the debugger is that to support await constructs for evaluation, a new thread is created with a new event loop and that event loop in that new thread will execute the coroutine (with the context of the paused frame passed to that thread for the evaluation).

This is not perfect as there are some cons, for instance, evaluating the code in a thread can mean that some evaluations may not work because some frameworks such as qt consider the UI thread as special and won't work properly, checks for the current thread won't match the thread paused and probably a bunch of other things, but I guess it's a reasonable tradeoff vs not having it at all as it should work in the majority of cases.

Keep an eye open for the next release as it'll be possible to await coroutines in the debugger evaluation and watches ;)

p.s.: For VSCode users this will also be available in debugpy.

PyDev 9.3.0 is now available.

The main changes in this release are related to the debugger, with improvements such as:

• Major issue fixed issue where variable children sometimes wouldn't expand correctly.
• Fixed some case where automatic connection to subprocesses wouldn't work.
• Debugging with Pandas is much improved with the addition of some custom converters.
• Opt-in support to show paused greenlets by setting GEVENT_SHOW_PAUSED_GREENLETS=1.
• Support for newer versions of gevent.
• Information on user settings paths is cached to fix issue with slow debugging using pipenv project.
• A warning is shown if getting some attribute / getting its repr is slow.
• Interactively inspect matplotlib plots when the QtAgg backend is used.
• Support for PySide2.
• Better error messages in case Python 3.11 frozen modules are being used.

Also noteworthy is that this will be the last release supporting older versions of Python including Python 2.7 up to Python 3.5. Newer releases will only support Python 3.6 onwards.

PyDev 8.3.0 is now available!

Let me start with some warnings here:

First, PyDev now requires Java 11. I believe that Java 11 is pretty standard nowadays and the latest Eclipse also requires Java 11 (if you absolutely need Java 8, please keep using PyDev 8.2.0 -- or earlier -- indefinitely, otherwise, if you are still using Java 8, please upgrade to Java 11 -- or higher).

Second, Eclipse 2021-03 (4.19) is broken and cannot be used with any version of PyDev due to https://bugs.eclipse.org/bugs/show_bug.cgi?id=571990, so, if you use PyDev, please keep to Eclipse 4.18 (or get a newer if available) -- the latest version of PyDev warns about this, older versions will not complain but some features will not function properly, so, please skip on using Eclipse 4.19 if you use PyDev.

Now, on to the goodies ;)

On the linters front, the configurations for the linters can now be saved to the project or user settings and flake8 has an UI for configuration which is much more flexible, allowing to change the severity of any error.

A new option which allows all comments to be added to a single indent was added (and this is now the default).

The code-completion and quick fixes which rely on automatically adding some import will now cache the selection so that if a given token is imported that selection is saved and when asked again it'll be reused (so, for instance, if you just resolved Optional to be typing.Optional, that'll be the first choice the next time around).

Environment variables are now properly supported in .pydevproject. The expected format is: ${env_var:VAR_NAME}.

Acknowledgements

Thanks to Luis Cabral, who is now helping in the project for doing many of those improvements (and to the Patrons at https://www.patreon.com/fabioz which enabled it to happen).

 Enjoy!

 PyDev 8.2.0 is now available for download.

This release has many improvements for dealing with external linters.

The main ones are the inclusion of support for the Flake8 linter as well as using a single linter call for analyzing a directory, so, that should be much faster now (previously it called external linters once for each file) .

Note: to request code analysis for all the contents below a folder, right-click it and choose PyDev > Code analysis:

Another change is that comments are now added to the line indentation... 

This means that some code as:

 def method(): if True: pass

Will become:

 def method(): # if True: # pass

p.s.: it's possible to revert to the old behavior by changing the preferences at PyDev > Editor > Code Style > Comments. 

Also note that after some feedback, on the next release an option to format such as the code below will also be added (and will probably be made the default):

 def method(): # if True: # pass

Interpreter configuration also got a revamp:

Path mappings for remote debugging can now (finally) be configured from within PyDev itself, so, changing environment variables is no longer needed for that:

Note that Add path mappings template entry may be clicked multiple times to add multiple entries.

That's it... More details may be found at: http://pydev.org.

Hope you enjoy the release 😊

 PyDev 8.1.0 is now available for download.

As a note, I didn't really create a post on 8.0.1, so, I'm covering some of the features in that version in this blog post too! 😊

Some nice things added: 

• Python 3.9 is officially supported in PyDev -- definitely a must if you plan on using Python 3.9!

• There are quick-fixes (Ctrl+1) to convert a string into an f-string (see image below):
  

Note that even if there's no formatting in the string, with this it's possible to write some string as: "Value is {value}" and then use the quick fix just to add the "f" to the front of the string (which is quite handy if you weren't initially planning to create it as an f-string).

• When starting the interactive console, it's now possible to save how the interactive console should be initialized (see image below):

Note that it's also possible to change those settings in the interactive console preferences if you want to change them after the initial selection (hint: after the interactive console is created it's possible to use F2 to send a line from the editor for execution to the interactive console for notebook-like evaluation).

Besides this there are many other improvements, such as improved conda activation, rerunning pytest parametrized tests from the PyUnit view, MyPy integration improvements, support for from __future__ import annotations in code analysis and debugger improvements, among many others.. see: https://pydev.org for more details.

Enjoy!

Wow, PyDev is turning 8.0... the 8.0 version probably doesn't do much justice as it's actually being developed for 17 years already! 😊

I'm actually pretty happy on how things are working around it right now... Some interesting points:

• Many users now support PyDev through Patreon or PayPal -- so, it's been a while since I spent time to do a dedicated crowdfunding campaign (which usually demands quite a bit of time). That funding also allows having additional help (it's what currently sponsors the work of Luis Cabral in PyDev).
• It has a good amount of users (although it doesn't have as much users as it did in the past as there are many good Python IDEs available in the Python ecosystem now) -- I'm actually quite happy with this as for some time it seems like Eclipse had such a big market share that users that didn't like it had to bear with it, so, I'm pretty glad that there are alternatives now, even if it means its market share isn't as big as at was -- so, although this may mean less users it also means happier users.

• Microsoft is currently sponsoring my work on the pydevd debugger (as it's also used in the Python in Visual Studio and the Python Extension for Visual Studio Code), so, this actually translates into a high quality debugger for the whole Python ecosystem!
  

Ok, on to news on the PyDev 8.0 release...

As with the previous release, this release keeps on improving the support for type hinting and MyPy.

On the MyPy front, besides showing an error it will also show the related notes for a message on the tooltip (which would previously be available only in the output view) and MyPy processes are no longer launched in parallel when using the same cache folder (as this could end up making MyPy write wrong caches which required the cache folder to be manually erased).

In the type inference front there are multiple improvements to take advantage of type hints (such as support for Optional[] in code completion, handle types given as string and following type hints when presenting an option to create a new method in a class).

The debugger had a critical fix on the frame-evaluation mode (the mode which works by adding programmatic breakpoints by manipulating bytecode) which could make it skip breakpoints or even change the behavior of a program in extreme cases.

Besides this, other niceties such as code-completion inside f-strings are now available and this release had many other fixes (see: https://www.pydev.org for more details).

 So, thank you to all PyDev users and here's to the next 17 years, hope you enjoy using it as much as I enjoy making it!

🥂

• Grouping variables which were previously hidden -- note that they can be hidden/shown when debugging from the variables view dropdown menu as shown in the screen below:

• Better support for PySide2;
• Show the disassembly of frames when sources aren't available:

• #region / #endregion comments can now be used by the code-folding engine.

• An action to easily switch the default interpreter is now available (default binding: Ctrl+Shift+Alt+I -- note that it must be executed with an opened editor).

• It's possible to create local imports from global imports (use Ctrl+1 on the name of a given global import and select "Move import to local scope(s)" -- although note that the global import needs to be manually deleted later on).

• The interactive interpreter now has scroll-lock.

• The debugger is much more responsive!

• Thread creation is notified as threads are created instead of synchronized afterwards.
• Support for using frame evaluation disabled by default as it made the debugger much slower on some cases.
• Fixed case where breakpoint was missed if an exception was raised in a given line.
• Properly break on unhandled exceptions on threads.
• Add missing import which affected repl with IPython.
• Fix for case where breakpoints could be missed.

  { 'type': 'PyDev', 'label': 'PyDev (Python)', 'languages': ['python'], 'adapterExecutableCommand': 'pydev.start.debugger', # Note: adapterExecutableCommand will be replaced by a different API (right now still in proposal mode). # See: https://code.visualstudio.com/updates/v1\_20#\_debug-api # See: https://github.com/Microsoft/vscode/blob/7636a7d6f7d2749833f783e94fd3d48d6a1791cb/src/vs/vscode.proposed.d.ts#L388-L395 'enableBreakpointsFor': { 'languageIds': ['python', 'html'], }, 'configurationAttributes': { 'launch': { 'required': [ 'mainModule' ], 'properties': { 'mainModule': { 'type': 'string', 'description': 'The .py file that should be debugged.', }, 'args': { 'type': 'string', 'description': 'The command line arguments passed to the program.' }, "cwd": { "type": "string", "description": "The working directory of the program.", "default": "${workspaceFolder}" }, "console": { "type": "string", "enum": [ "integratedTerminal", "externalTerminal" ], "enumDescriptions": [ "VS Code integrated terminal.", "External terminal that can be configured in user settings." ], "description": "The specified console to launch the program.", "default": "integratedTerminal" }, } } }, "configurationSnippets": [ { "label": "PyDev: Launch Python Program", "description": "Add a new configuration for launching a python program with the PyDev debugger.", "body": { "type": "PyDev", "name": "PyDev Debug (Launch)", "request": "launch", "cwd": "^\"\\${workspaceFolder}\"", "console": "integratedTerminal", "mainModule": "", "args": "" } }, ] } 

  commands.registerCommand('pydev.start.debugger', () => { return { command: "C:/bin/python27/python.exe", // paths initially hardcoded for simplicity args: ["X:/vscode-pydev/vscode-pydev/src/debug_adapter/debugger_protocol.py"] } }); 

  Content-Length: 312\r\n \r\n { "arguments": { "adapterID": "PyDev", "clientID": "vscode", "clientName": "Visual Studio Code", "columnsStartAt1": true, "linesStartAt1": true, "locale": "en-us", "pathFormat": "path", "supportsRunInTerminalRequest": true, "supportsVariablePaging": true, "supportsVariableType": true }, "command": "initialize", "seq": 1, "type": "request" }

  { "seq": 1, "request_seq": 1, "command": "initialize",  "body": {"supportsConfigurationDoneRequest": true,  "supportsConditionalBreakpoints": true},  "type": "response", "success": true } 

  {"type": "event", "event": "initialized", "seq": 2} 

  { "arguments": { "__sessionId": "474aa497-0a90-4b30-8cc6-edf3bebbe703", "args": "", "console": "integratedTerminal", "cwd": "X:\\vscode_example", "name": "PyDev Debug (Launch)", "program": "X:/vscode_example/robots.py", "request": "launch", "type": "PyDev" }, "command": "launch", "seq": 2, "type": "request" } 

  { "request_seq": 2, "command": "launch", "body": {}, "type": "response", "success": true } 

• Niceties from PyDev when typing such as auto-adding self where needed (note that having the editor.formatOnType setting turned on is a requisite for that to work).
• Really fast code-completion, code-analysis and code-formatting engines.
• Code completion provides options to import modules, top level classes, methods and variables (python.pydev.preferredImportLocation can be used to determine the location of the import).
• Quick fix which automatically allows adding an import for unresolved symbols.
• In-file navigation to previous or next class or method through Ctrl+Shift+Up and Ctrl+Shift+Down.

• After publishing the first time and installing, the extension wasn't working because I wrongly put a dependency from npm in "devDependencies" and not in "dependencies" (the console in the developer tools helped in finding out that the dependency wasn't being loaded after the extension was installed).
• When a dependency is added/removed, npm install needs to be called again, it's not automatic.
• When uploading the extension I had the (common) error of not generating a token for "all" ;)
• Apparently there's a "String" and a "string" in TypeScript (or at least within the dependencies when editing VSCode).
• The whole launching on VSCode seems a bit limited/ad-hoc right now (for instance, .launch files create actual launchers which can be debugged but the python extension completely bypasses that by doing a launch in terminal for the current file -- probably because it's a bit of a pain creating that .launch file) -- I guess this reflects how young VSCode is... on the other hand, it really seems it built upon previous experience as the commands and bindings seems to have evolved directly to a good design (Eclipse painfully iterated over several designs on its command API).
• Extensions seem to be limited by design. I guess this is good and bad at the same time... good that extensions should never slow down the editor, but bad because they are not able to do something which is not in the platform itself to start with -- for instance, I really missed a good unittest UI when using it... there are actually many other things I missed from PyDev, although I guess this is probably a reflect on how young the platform is (and it does seem to be shaping up fast).