Op maandag 9 juli 2012 14:54:03 UTC+2 schreef Jean-Michel Pichavant het volgende: > Kruptein wrote: > > Op maandag 9 juli 2012 13:05:58 UTC+2 schreef Jean-Michel Pichavant het > > volgende: > > > >> Kruptein wrote: > >> > >>> Hey I released a new version of my python-focused text-editor. > >>> you can download it at http://launchpad.net/deditor > >>> > >>> What is it? > >>> Deditor is aimed to be a text-editor which can be used as a basic > >>> text-editor as gedit or with the right plugins become a full-feature ide. > >>> I focus on making it a python specific editor but you can use it to edit > >>> other files as well. > >>> It is python specific because the plugin system that is used (DPlug) is > >>> written in python and thus all plugins are written in python. Also some > >>> of the plugins there is one plugin that comes bundled with deditor that > >>> adds some python specific features like code-analyzing, code-inspection, > >>> auto-completion etc. > >>> > >>> So plugins are the main core of the program you can disable and enable > >>> plugins at your will. The plugins that come bundled are made to increase > >>> the joy of programming. > >>> > >>> NOTICE that this I don't regard this as a stable product yet. There is > >>> no high risk in data loss and there are definitely no privacy concerns > >>> but you should still be aware that there are bugs/malfunctions and that > >>> you will encounter them. > >>> > >>> I hope some of you like it and if you don't try to give some constructive > >>> criticism :) > >>> > >>> > >>> Most changes in regard to previous release are under the hood. so > >>> existing users might not notice a lot. > >>> Also the customize plugin's second configuration tab: syntax highlighting > >>> is bugged try to avoid it :p > >>> > >>> > >> Good job. > >> > >> I have 2 question: > >> Aren't you reinventing the wheel ? > >> No way to use tabs for tabulation ??? (I'm CEO of the 'space haters club') > >> > >> Otherwise, I found this bug : > >> Start the editor, click twice on 'Analyse code', and you'll get a > >> traceback. > >> I looked into the related code: > >> > >> def dUpdate(self, trig, value=None): > >> if trig == "tabclosed": > >> return self.tabClosed(value) > >> > >> def tabClosed(self, tab): > >> """Checks if the tab that is closing is a project""" > >> if tab.parentTab == None: > >> pass > >> > >> > >> Your method interfaces are quite inconsistent, I sense this is quite > >> global to your code: > >> > >> 1/ dUpdate has None as default value for 'value' > >> 2/ tab.parentTab will fail if tab is None > >> 3/ on the traceback you get from the bug above, a bool has been given, > >> bool has no parentTab. > >> > >> > >> Here are 2 advices: > >> > >> 1/ Default values are for the fool/weak/noob/..., your pick. I tend to > >> use them only for backward compatibilty or for interface stability. > >> Otherwise, it's better not to use them. Some people still use them > >> appropriately but in your I think it may help. > >> > >> 2/ In your docstrings, note down the expected type of your parameters > >> (only 1 type ! (except for the None alternative)) and stick to it. > >> > >> Regards, > >> > >> JM > >> > > > > To begin with not everything that I want to see is yet implemented. A lot > > still has to be done for example indentation although I really hate tabs ;D > > I will give the option in a future release maybe even the next one. > > > > I'll check the bug as it probably is indeed a bug. > > > > Regarding the default value dUpdate is a method from the plugin system and > > is called when a trigger is updated. some triggers give an additional > > value for example a trigger that registers pressed buttons could > > potentially give which exact key as value. However some triggers don't > > need this additional value. If a plugin needs both types of triggers the > > method will need this default value to work. Also the dev version already > > changed that there always will be sent a value so no need for the default > > value anymore. > > > > > If you can, use the **kwargs syntax. > def foo(tabs, **kwargs): > # optional arg > if kwargs.get('saveFile', False): > self.saveFile(tab.file) > # required arg > if kwargs['saveFile']: > self.saveFile() > > > The type of kwargs will be consistent, it will be always a dictionnary, > possibly an empty one, but still a dictionnary, and best part of it, if > you change the number of argument in the call, you don't break your > interface. > > > Regarding the docstrings: as deditor still is under heavy development not > > all docstrings are correct or even there. > > > > > Yep, but writing the expected type of your parameters always help, in > particular during the dev phase. you can save the verbose part of the > documentation for later. > > Cheers, > > JM
Yeah I started to use kwargs in some methods but it's only usefull in some cases imo. I'm a pretty decent python dev imo but I know that there is still a lot that I've to learn so often if I get to know something knew I tend to rewrite a large portion of my program(s) and thus I often am too lazy to write proper docstrings as they would change anyway (<- very bad coding practice though ^^) Thanks for the feedback anyways :) -- http://mail.python.org/mailman/listinfo/python-list
