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

added a bullet dict class as #27 requested #30

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

CurtisPreston99
Copy link

the way this works is you define a dict the keys are shown to the user but the values are returned when selected. i think this would be nice to have.
added it to client file as class BulletDict, and set up in init, also added an example feel free to give me advice on how to improve this class

the way this works is you define a dict the keys are shown to the user but the values are returned when selected. i think this would be nice to have
added it to client file as class BulletDict, and set up in init, also added an example feel free to give me advice on how to improve this class
from .client import ScrollBar
from .client import BulletDic
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your class is named BulletDict, not BulletDic

@@ -0,0 +1,16 @@
from bullet import BulletDic
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Class name again

bullet/client.py Outdated
@@ -224,6 +224,127 @@ def launch(self, default = None):
if ret is not None:
return ret


@keyhandler.init
class BulletDict:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a lot of repeated code for what seems like it should just be a child class that overrides accept().

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah okay that makes sense ill do that now thank you.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what are your thoughts on it now? any improvements you would recommend me trying to do?

fixing what was suggested by rcfox on pull request bchao1#27
@rcfox
Copy link
Contributor

rcfox commented Mar 8, 2019

(I should point out that I have no authority on this project, I'm just a random guy commenting on someone else's repo.)

After sleeping on this, it seems like it would be best if this were rolled into the main classes. (Sorry for the runaround) It's simple enough to detect the type of variable being passed into the constructor.

It also seems like list choices would be the special case. If you get a list, you could just make a dict out of it: {c: c for c in choices} With that, we could standardize the rest of the code on dictionaries.

@rcfox
Copy link
Contributor

rcfox commented Mar 8, 2019

Actually, it would probably be better to store choices as a list of (key, value) pairs. That way duplicate list items won't be lost, and you avoid the weirdness of trying to index into a dictionary at a certain position.

@CurtisPreston99
Copy link
Author

thats okay im just trying to improve my code, it was my new years resolution to contribute to things, also im still at University so learning better ways of doing things is always nice. also that two list idea seams pretty good so you would just have a list for displaying and a list for return values

Copy link
Contributor

@rcfox rcfox left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly looks good, just needs a bit of polish.


#test flag also return objects
self.objects=[]
if(type(choices) is dict):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

isinstance(obj, cls) is generally preferable to type(obj) is cls since it supports subtypes. (For instance, OrderedDict)

self.objects=[choices[x] for x in self.choices]
else:
self.choices = choices

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you set self.objects = choices, you wouldn't need the extra check in accept(), you could also just return from self.objects

bullet/client.py Outdated
self.objects=[]
if(type(choices) is dict):
self.choices = list(choices.keys())
self.objects=[choices[x] for x in self.choices]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about list(choices.values()) for consistency?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

did not know that there was a .values() function

bullet/client.py Outdated
@@ -197,7 +205,11 @@ def moveDown(self):
def accept(self):
utils.moveCursorDown(len(self.choices) - self.pos)
cursor.show_cursor()
ret = self.choices[self.pos]
#flag check and return ether objects or just choices
if(self.objects):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpicking, but you generally leave off parentheses on if statements in Python for simple conditions like this.

Also, try to be consistent with whitespace to match the surrounding code.

removed flag statement from accept
by making objects the same as choices if its a list
@tdh8316
Copy link

tdh8316 commented Mar 10, 2019

You should use tools such as PEP8 to maintain a consistent code style.

I think pylint, yapf would be good for this :)

@CurtisPreston99
Copy link
Author

You should use tools such as PEP8 to maintain a consistent code style.

I think pylint, yapf would be good for this :)

ah okay ill look into this

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.

None yet

3 participants