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.

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

About unfolding the CATEGORIES #61

Open
iamgodot opened this issue Mar 5, 2022 · 4 comments
Open

About unfolding the CATEGORIES #61

iamgodot opened this issue Mar 5, 2022 · 4 comments

Comments

@iamgodot
Copy link
Contributor

iamgodot commented Mar 5, 2022

Proposal(more like a feature request)

Current categories make the result of pdir() a bit confusing, at least for myself. The original dir() doesn't have the problem since it outputs a simple alphabetized list, which is why pdir() could do much better.
An idea of mine is to extend categories as different levels, and keep them orthogonal at each level. For example:

  • property
  • function
  • class
    • public
    • private
  • special
    • arithmetic
    • context_manager
    • coroutine
  • more..
@laike9m
Copy link
Owner

laike9m commented Mar 6, 2022

Fine with adding more categories to properties and special attributes, the more fine grained categorization actually already exists. The proposal on "class" doesn't make much sense to me, because right now we only show classes' names, and it's not clear what "private" and "public" means.

@iamgodot
Copy link
Contributor Author

iamgodot commented Mar 7, 2022

Fine with adding more categories to properties and special attributes, the more fine grained categorization actually already exists. The proposal on "class" doesn't make much sense to me, because right now we only show classes' names, and it's not clear what "private" and "public" means.

Thanks for the reply, and let me explain myself clearer:

  1. Yes, I can see from the code that categories are getting layered, while it could also make a difference in the output, e.g. with less/more indents.
  2. The public/private class is only an example so it's totally arguable. What I meaned was those prefixed with _, for classes/functions/variables.

@laike9m
Copy link
Owner

laike9m commented Mar 12, 2022

I'm generally ok with supporting 1, though I anticipate the change to be non-trivial, and I may not have enough time to work on it at this moment.

for 2, I'd hold it. It is true that there's convention to treat the _ prefix as private, but it still is not a feature that we have in the language.

@iamgodot
Copy link
Contributor Author

I'm generally ok with supporting 1, though I anticipate the change to be non-trivial, and I may not have enough time to work on it at this moment.

for 2, I'd hold it. It is true that there's convention to treat the _ prefix as private, but it still is not a feature that we have in the language.

Cool, I get your point with the prefix matter. You're right about the changes this unfolding/indenting might've brought, I'll come up with more details to sort out what needs to be done.

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

No branches or pull requests

2 participants