For a standalone instance, you would need to let the Zope/Plone server perform the action to avoid stopping the server. This means that the server must be prepared for this.
One option would be to have a special view (e.g. "@@create_users") which you can activate as usual (for a view) via your browser. It would look somewhere for instructions which users it should create -- and do it. The view code itself could be quite similar to that you executed in the interactive interpreter (in fact simpler because you are already in a request and portal context).
Views are really elementary to modern Zope/Plone versions. Almost everything (related to user interaction) uses views, including Plone itself. Therefore, reading view related documentation is a good investment.
There are probably several ways to do what you want.
Maybe you can explain your use case?
Personally, I would make a browser view if you plan to do this a lot.
If you (for some weird reason) have a list of uses that you want to add to a lot of sites, this can even be done in a profile ( I think ).
Although probably not a very 'correct way', at least it would be very easy to make.
Then you could just edit the xml file and reinstall it when you need new users.
The entry point to the Plone RESTful API is the portal root. The client can ask for a REST API response by setting the 'Accept' HTTP header to 'application/json' : GET /plone HTTP/1.1 Accept: application/json Authorization: Basic YWRtaW46c2VjcmV0
I have to add about one hundred users and I would like to not do it by hand. Because my site is a Plone 5.2/python3 one, I guess I could not use collective.mass_subscriptions that in addition seems to have some issues.
I came across the nice way of programmatically create users given in my OP so I wanted to do it but my site is a standalone one and is already in production. Hence I'm reluctant to stopping it.
I plan to this not a lot, but regularly (each year when we have to add new students to our intra/extranet. I guess immersing myself in browser views would be less time consuming than in REST API. So I will probably go that way.
It worked great for me with 5.1. Have you tried it with 5.2 ?
There is not much code, so the best (for everyone) would be if it could be upgraded to 5.2.
Indeed, the add-on installs smoothly but it cannot be used:
Traceback (innermost last):
Module ZPublisher.WSGIPublisher, line 155, in transaction_pubevents
Module ZPublisher.WSGIPublisher, line 337, in publish_module
Module ZPublisher.WSGIPublisher, line 255, in publish
Module ZPublisher.mapply, line 85, in mapply
Module ZPublisher.WSGIPublisher, line 61, in call_object
Module collective.mass_subscriptions.browser.subscriptions, line 33, in __call__
Module collective.mass_subscriptions.browser.subscriptions, line 106, in _importUsers
_csv.Error: iterator should return strings, not bytes (did you open the file in text mode?)