Provide searchable listing indicating the "scopes" in which Python libraries are supported

Feature Requests
1

Feature Request:

Provide a searchable listing indicating the scope(s) in which Python libraries are supported.

Example scopes:

  • If at runtime the library would emit NotImplementedImportError, then its scopes would be None.

  • If at runtime the library could emit SuspensionError, this its scopes would – in some way – detail the situation(s) in which that would occur.

  • And so on.

Such a listing enables users to inspect the “support level” of a Python library, prior to writing code that depends on it.

Importantly, the listing should be kept fresh, otherwise users may be tempted to try an unsupported library, knowing that the listing isn’t kept up-to-date.

Benefits:

  • The time & effort to implement this pays for itself by way of reduced Forum Q&As, as well as by eliminating lost time coding items destined to fail.

Thank you.

3 Likes
2

I’ll second this.

Note, some libraries are present Client-side, but not fully supported. For example, the standard array module exists, and can create arrays; but (if I remember correctly) their signed ints go up to 32 bits (not 64), and they’re not subscriptable!

In that case, a listing of features (however coarse- or fine-grained) may be more useful than a listing of library names.

1 Like
3

I understand anvil is frequently behind or ahead of skulpt at certain times, but I have trouble even finding out what is supported through the Skulpt documentation. Even a list of what from pythons standard library is available could help. Maybe in the Anvil docs similar to this page: Anvil Docs | List of Packages

Right now all I really do is type import blah into a form in the IDE and run it and see if it quacks at me.

2 Likes
4

Your example is a good one because, even though import blah may succeed there, it’s import or usage elsewhere may very well fail. I saw this with, I think, the numbers library in different situations. (I wish I had saved the snippet). Whatever it was, it initially worked on a cursory check (like an import), but its usage elsewhere raised an exception.

Anyway, this is why I framed the feature request in terms of scope(s) (ie, the contexts / situations ) in which a library will and won’t work (if at all).

1 Like
5

An alternative workaround to putting that temporary code in a form:

1 Like
6

That (the REPL) is what I’ve been using as the first step (… the “does it import at all scope”).

1 Like
7

Another workaround I once found helpful:

A more up-to-date way to determine with confidence what Skulpt implements (and sometimes get an indication of what it doesn’t) is to look at what’s included (and what standard Python tests are commented out) in the Skulpt tests here: skulpt/test/unit3 at master · skulpt/skulpt · GitHub .

3 Likes