As far as I understand, there's no ready solution for this, so here're my thoughts on how that could be done.

The simplest solution could be exposing the <script> element for the module as

pyscript.web.script: Element

Then everything needed can be extracted from that element using its .getAttribute() method.

However, this approach would fail e.g. if the worker is created via pyscript.create_named_worker() and no <script> tag ever existed.

Another approach could be exposing particular tag attributes (or create_named_worker() arguments) as objects in pyscript.web module or in pyscript.config dictionary.

The latter is probably better. It could be a

pyscript.config.script: dict[str, Any]

where all Element.getAttribute() values can be stored.

Maybe script (relating to the <script> tag) is not the perfect name, maybe arguments/args/attributes/attrs would be better.

• target could be used by Python code, for example, to log its messages to the same container.

Oh, I've just noticed pyscript.current_target() in the docs. :) That's kind of mapping I was talking about.

none? mind to elaborate in here?

Well, I tried, but then decided that it would be too complicated anyway, never mind.

if the worker was started via pyscript.create_named_worker(), there's no <script> tag to query via CSS, at all

Sorry, that was my bad – I've just checked the create_named_worker() source, only to find that it actually creates a <script> tag. :)
So, anything that's working for <script> tags should work for create_named_worker() also, that's good.

you have document.currentScript

Whoa! I didn't know about it, it seems never mentioned in the docs.

And also, it returns jsnull for me, could I be doing something wrong?

Also, would it be available without CORS, with sync_main_only = true?

Oh, by the way, pyscript.web.page.find('script[type="py"]') also doesn't work with sync_main_only = true without CORS.
And this is one more reason to give workers their tag attributes while they're being created and are not behind the No-DOM wall.

it might have race conditions ... because you might create many scripts at once and who knows which one starts first

Oh, I don't care about that (yet?). For now, I'm looking at a situation where I have 4 <script type="py" worker> tags in static index.html, and all of them have the same src (and, consequently, the same code), but different names, and I want each worker instance to use its "name" in logging. And HTML <script name=""> attribute looks like a perfect way to give worker a name! Why do something in runtime, when it can be found in static configuration?

Passing an ID for the created element to the worker is a sync pollution away

Well, (almost) anything is possible. The questions I'm thinking are: Is it easy? Particularly for a novice? Is this answer easy to find? And to implement? Would a novice be comfortable implementing it? Would they feel the process as comfortable? Accessible? Intuitive? Would they feel PyScript as wowcool or as complicated and cumbersome in the end? Would they ask a ton of tech support questions? :) And also – is it pythonic? Is it comfortable and intuitive for a Python person who doesn't know a lot of JS? Because if a person knows JS well, what would they need PyScript for?

For example, you're talking about "sync pollution" – I couldn't understand what that is. I've found worker = await pyscript.worker['workerName'] and await worker.exportedFunctionName(...) in the docs, and it's perfect, I'm fine with it – it's clear, concise and pythonic. I'd prefer to know as little as possible about JS under the hood. And that "sync pollution" you're talking about would take some serious effort to grasp from EACH non-JS person who would try to solve the issue I'm talking about.

why do you think we need to offer everything that's already possible via an API?

Well, you definitely don't NEED that. That would just make PyScript more comfortable, intuitive and easy to use from Python side.

You know, a LOT of stuff in PyScript is already AMAZING, from Python view. I've written some stuff on JS in the past, and I have my reasons to hate it. So being able to have a wonderful GUI that HTML&Browser are from the comfort of Python – is SO much better! So get me right, I'm not saying PyScript API is poor or not capable. It just has its imperfections, "incompletenesses" in connecting Python logic with HTML GUI, and when I see those, I report them. But they're FEW in number, really. Most of the stuff if just working ™ and that's amazing, I'm having so much fun coding in PyScript! It's great!

wouldn't that invalidate the fact the API can give you already everything you want?

Well, if it's a logical and understandable thing, and there is a reliable, but long way to achieve, the question I'd ask is as follows: what is easier, to create a short and precise way to achieve it, or having to document a long way around, or answering the support questions for anybody who couldn't find that long way on their own? Your choice. :)

For example, you have pyscript.current_target() in your API, right? Why? That is possible to extract from <script> element too. But that would be cumbersome, and non-pythonic. So you've created a short, direct solution for clear, understandable task. Other <script> attributes are no worse, from my POV.