Skip to content

Conversation

@JamesHutchison
Copy link

@JamesHutchison JamesHutchison commented Sep 18, 2025

Addresses #2609

The underlying issue seemed to be some inconsistency with __initialized__ and __initializing__ variables. I'm under the impression these are both Brython internals.

It's possible these were separated on purpose.

I think the "from" import is potentially incorrect, or at least could be reorganized to make its intent clearer, but it looks like simply updating everything to __initialized__ fixed the VFS issue I was seeing. It's probably hiding an issue with the logic.

I also changed the logic to what I thought it was trying to do and found that lazy (file based, not VFS) imports broke (see the revert here: 6a6a678)

I'm guessing this logic is important to keep as-is but didn't look into why. Having it also check for __file__ breaks this:

                try{
                    __path__ = $B.$getattr($B.imported[_mod_name], "__path__")
                }catch(e){
                    // If this is the last but one part, and the last part is
                    // an attribute of module, and this attribute is a module,
                    // return it. This is the case for os.path for instance
                    if(i == len - 1 &&
                            $B.imported[_mod_name][parsed_name[len]] &&
                            $B.imported[_mod_name][parsed_name[len]].__class__ ===
                                $B.module){
                        return $B.imported[_mod_name][parsed_name[len]]
                    }

@JamesHutchison JamesHutchison marked this pull request as draft September 18, 2025 21:53
@JamesHutchison JamesHutchison marked this pull request as ready for review September 18, 2025 23:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant