Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

There's a random chance that the superclass isn't linked #482

Closed
not-my-profile opened this issue Feb 6, 2022 · 2 comments · Fixed by #488
Closed

There's a random chance that the superclass isn't linked #482

not-my-profile opened this issue Feb 6, 2022 · 2 comments · Fixed by #488
Labels
bug

Comments

@not-my-profile
Copy link
Contributor

not-my-profile commented Feb 6, 2022 •
edited
Loading

To reproduce this we need a package with three files:

example/__init__.py

from . import bar

example/foo.py

from . import xxx

class Foo(object):
	pass

example/bar.py

from . import foo

class Bar(foo.Foo):
    pass

Running pydoctor example has a random chance that it fails to link the superclass:

correct bugged
image image

The bug is difficult to debug since it doesn't always occur, running pydoctor with PYTHONHASHSEED=0 or PYTHONHASHSEED=1 does however seem to help with reproducing.

The underlying issue is that how pydoctor currently handles cyclic imports is not reproducible.
@not-my-profile not-my-profile changed the title There's a random chance that the superclass isn't recognized There's a random chance that the superclass isn't linked Feb 6, 2022
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 6, 2022
@not-my-profile
Add workaround for missing baseobjects
f9f4fc4 
Closes twisted#482.
@tristanlatr
Copy link
Contributor

Probably linked to #429 and #412.

Know that I’m working on a new ast builder that should solve a lot of our problems. See #430

@not-my-profile not-my-profile mentioned this issue Feb 6, 2022
Closed
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 6, 2022
@not-my-profile
Fix random module processing order
a8a0874 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
@not-my-profile not-my-profile mentioned this issue Feb 6, 2022
Closed
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 6, 2022
@not-my-profile
Fix random module processing order
d07de61 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
This was referenced Feb 6, 2022
Closed
Closed
@tristanlatr tristanlatr added the bug label Feb 7, 2022
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
56fc734 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
1045e2d 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
32f6af1 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
8362512 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
d057c84 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
17662b4 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
05d7f04 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
db86c46 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
b1e2785 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
60e3090 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
529d96e 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
391f7f1 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
not-my-profile added a commit to not-my-profile/pydoctor that referenced this issue Feb 7, 2022
@not-my-profile
Fix random module processing order
1eed3ca 
Previously modules to be processed were stored in a set.
A set however is an unordered collection (and adding items
can completely change the order depending on the object hash).

Since the Module class did not implement __hash__ every time
there was more than one module to be processed the order
in which they were processed was effectively random leading
to very hard to reproduce bugs.

Fixes twisted#482 and twisted#429.
@tristanlatr tristanlatr mentioned this issue Feb 8, 2022
Merged
@tristanlatr
Copy link
Contributor

tristanlatr commented Feb 10, 2022 •
edited
Loading

Note that solving the processing order does not solve the import cycles handling.

What would solve this issue is a major refactoring if the builder. Thing that I’m doing with pydocspec

see #430

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
2 participants
@tristanlatr @not-my-profile