*** derek has joined #gnuenterprise
*** derek has quit IRC
*** johannesV has joined #gnuenterprise
<johannesV> good morning
*** reinhard has joined #gnuenterprise
*** btami has joined #gnuenterprise
<btami> good morning
<reinhard> good morning all
<johannesV> good morning again ... :)
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
*** kilo has joined #gnuenterprise
*** johannesV has quit IRC
<kilo> good morning
*** yure has joined #gnuenterprise
*** johannesV has joined #gnuenterprise
<johannesV> reinhard, have you already posted the pylint config ?
<reinhard> oops no
<reinhard> will do in a second
<johannesV> how do we use it ? symlink to ~/.pylintrc ?
<johannesV> ah, ok ... saw it in the header
<johannesV> reinhard, how to use pylint with gcvs ?
<reinhard> gcvs /usr/bin/pylint file.py
<reinhard> or
<reinhard> gcvs /usr/bin/pylint -rn file.py
<johannesV> wow, that's simply great :)
<johannesV> hm, what about having constant names built from uppercase letters ?
<johannesV> *lol* Not enough public methods (0/2)
<johannesV> i feel i'll love pylint ...
<reinhard> what do you mean with "contant"?
<reinhard> in python, everything is a variable, isn't it?
<johannesV> constants
<johannesV> like SIOCGIFCONF = ...
<reinhard> ah
<reinhard> you could add that to the regex for variable names
<reinhard> line 138 in .pylintrc
<reinhard> I'm sure that you can build a regex to match words that are either all lowercase or all uppercase
<reinhard> lol
<reinhard> # Bad variable names which should always be refused, separated by a comma
<reinhard> bad-names=foo,bar,baz,toto,tutu,tata
<johannesV> :)
<johannesV> hm, so i changed a try: ... except: ... into a try: ... except Exception: ... and i still get a warning ??
<johannesV> how to solve a catch-all then ?
<reinhard> what kind of warning?
<johannesV> and another one ... why should we *not* use the builtin functions map and filter ?
<johannesV> W0703:239:NetworkInterfaces.__load_via_ifconf: Catch "Exception"
<johannesV> and what about the usage of acronyms within function names ?
<johannesV> like "generate_SHA1" or "generate_MD5" ?
<johannesV> should the be called generate_sha1 and generate_md5 instead ?
<reinhard> I think yes
<reinhard> for example the command is "md5sum" not "MD5sum"
<reinhard> so I think it's ok to change those acronyms to lowercase
<reinhard> you can do pylint --help-msg W0703 to get more detail about a message
<reinhard> (which doesn't help much in this specific case)
<kilo> lol
<reinhard> ok, W0703 only happens if Exception is caught via "except Exception" and there is no "raise" in the handling code
<reinhard> which I agree is something that is unusual and in most cases not wanted
<reinhard> you could disable that check for this module then
<reinhard> # pylint: disable-msg=W0703
<reinhard> somewhere in the code
<johannesV> be more precise about 'somewhere' please :)
<reinhard> I'm not sure where
<reinhard> just thinking about what would be best
<reinhard> maybe at the very end of the file?
<reinhard> or after the gpl header?
<johannesV> i think after gpl header, as we might have module-selftesting code at the end
<reinhard> fine with me
<johannesV> ok, another situation
<johannesV> i need to iterate some statements for a given number of times
<johannesV> but the iteration-index isn't use at all
<johannesV> which leads to a W0612
<johannesV> like: for i in range(12): print "Blabla"
<reinhard> for dummy in range(12): print "Blabla"
<reinhard> # List of variable names used for dummy variables (i.e. not used).
<reinhard> dummy-variables=_,dummy
<johannesV> ah, ok, great
<johannesV> hm, ok, so i'm at 9.91/10 now
<johannesV> F0401: 46: Unable to import 'win32com.client.GetObject' (No module named win32co
<johannesV> m)
<reinhard> FWIW, I always run it with "-rn"
<reinhard> then it only displays warnings
<johannesV> is still in there as that module is not available on  linux
<johannesV> hm, no same messages but no statistics
<reinhard> yes
<reinhard> that's what I meant, sorry
<reinhard> it displays messages, but not the whole blurb at the end
<johannesV> ok
<reinhard> F0401 might go away if you do
<reinhard> import win32com
<reinhard> and then later
<reinhard> err
<reinhard> sorry, forget what I said
<reinhard> I think you have to disable this check, too
<johannesV> but then the same check isn't applied to all the other modules ...
<reinhard> yes
<reinhard> I don't like this, either
<johannesV> ok, and then there's the design checker complaining about the number of attributes
<johannesV> R0902:344:Generator: Too many instance attributes (10/7)
<reinhard> we might globally want to icrease that number
<johannesV> hm, yeah
<reinhard> maybe jamest has some experience here
*** jamest has joined #gnuenterprise
*** jamest has left #gnuenterprise
*** sjc has joined #gnuenterprise
*** jamest has joined #gnuenterprise
<reinhard> good morning jamest
<jamest> morning
<reinhard> do you have any experiences with the "design" pylint checks?
<reinhard> min/max number of instance attributes, public methods etc
<reinhard> the checks seem pretty limiting, and I wonder whether we should fiddle with the knobs a little bit there
<jamest> i'd just been trying to hit it's defaults
<jamest> and if I can't on a function then I live with it :)
<jamest> which ones you wanting to tweak?
<reinhard> I was hoping for your experiences on exactly *that* question :)
<jamest> lol
<jamest> honestly, i figured anywhere I was against the defaults then I was probably following bad design
<johannesV> hm, it took me about an hour to make pylint being happy with uuid.py (and that is 9.95/10)
<johannesV> but i think it is worth the additional work ... as this amount should shrink the longer we're using pylint
<johannesV> and it's just impressive to see pylint working ... as it is really able to detect bugs
<jamest> yes!
<jamest> i'm no longer the only one saying that now! :)
* jamest was lonely
<johannesV> :)
<jcater> johannes: did you get an answer on why it complains about map and filter?
<johannesV> yes
<jcater> okay
<johannesV> doing a pylint --help-msg W.... it said that one should better use list comprehension
<jcater> well, the real reason I think
<jcater> is that Guido wants those dropped from Python 3
<johannesV> so instead of map(int, [16, 16, 16], data) one should do [int(a, 16) for a in data]
<jcater> http://www.artima.com/weblogs/viewpost.jsp?thread=98196
<kilo> whois this Guido and why does he want to change Python :D:D
<johannesV> and after comparing that snippets i think the list comprehension looks better
*** kilo has quit IRC
<jcater> lambda, reduce, map, and filter will all be dropped in python 3
<jcater> I've never used reduce, map, and filter
<jcater> (on purpose)
<jcater> but I'll miss anonymous methods in event-driven systems like wx
<johannesV> nice article ...
<johannesV> hm, i don't like lambda very much and i'm not using it at all ...
<johannesV> i think it makes stuff unreadable
<jcater> true
<jcater> I won't argue with you there
<jcater> but honestly, I find list comprehensions equally unreadable
<jcater> (but am starting to like them too)
<johannesV> hm, it takes some time to get used to it
<johannesV> but i like it
<johannesV> (after getting used to it :))
*** yure has quit IRC
<reinhard> is it correct that different triggers of the same object don't share the execution context?
<reinhard> and if yes, is this on purpose?
<jcater> by context, you mean a shared namespace dictionary?
<reinhard> I mean an ExecutionContext object
<reinhard> that - in the case of python - more or less is only a wrapper around the namespace dictionary
<jamest> i'm not familiar with the ExectoinContext
*** derek has joined #gnuenterprise
*** klasstek has joined #gnuenterprise
*** johannesV has quit IRC
*** johannesV has joined #gnuenterprise
<reinhard> why is "apply" also listed as a bad function?
*** sacha has quit IRC
<reinhard> oh, found it
*** klasstek has quit IRC
*** btami has quit IRC
<johannesV> why?
*** yure has joined #gnuenterprise
<reinhard> apply(func, args, params) is equivalent to func(*args, **params)
<reinhard> and the latter is preferred
<reinhard> apply is depreciated
<jamest> though pylint complains about the use of  func(*args, **params) as well
<jamest> kind of a catch 22 isn't it?
<jcater> yeah, I didn't quite understand that
<reinhard> yes
<reinhard> well
<jcater> apply() iirc has been discouraged since python 2.0, though
<reinhard> I think that targets at things like "__init__(self, *args, **params):"
<reinhard> where you're just too lazy to look up the param list of the parent
<jcater> lol
<jcater> fwiw, when I do that
<jcater> it's never out of laziness
<jcater> it's that I don't want my class to track stuff it has no business/need to track
<jcater> (just for the record)
<reinhard> j/k
<jamest> jcater: nice cover
<jcater> okay, maybe I occasionally do it out of laziness
* jcater points over there
<jcater> look,?a goat!
<reinhard> ah yes
<reinhard> that reminds me of something
<jamest> boy
<jcater> lol
<jamest> you don't see that conversation thread often
<reinhard> http://goatonapole.com/
<jcater> lol
<jamest> sombody had too much free time
*** Morphous has joined #gnuenterprise
*** Amorphous has quit IRC
*** klasstek has joined #gnuenterprise
*** yure has quit IRC
*** Morphous is now known as Amorphous
*** lupo__ has joined #gnuenterprise
*** yure has joined #gnuenterprise
*** johannesV has quit IRC
*** d4rkstar has joined #gnuenterprise
<d4rkstar> good evening
<d4rkstar> there is someone out there?
<reinhard> yes
<d4rkstar> hi reinhard
<d4rkstar> i'm searching for info about gnu/bayonne
<reinhard> hmmm
<reinhard> not exactly my field of expertise...
<d4rkstar> it seems that from the version 2 there isn't documentation
<d4rkstar> or it hasn't been updated
<d4rkstar> so the software is unusable
<d4rkstar> i think i've entered the wrong channel :D
<reinhard> most probably
<reinhard> maybe there is a #bayonne
<d4rkstar> yeah man
<d4rkstar> thanks for the first hint
<jcater> reinhard: may queens?
<reinhard> I was just remembering led zeppelin
<jcater> ah
<jamest> lol
<jcater> cool
<jcater> but with that
<jcater> no one can tease me about "synching machines" again
<jcater> :)
<jamest> well
<jamest> i took that commit msgs to mean "cleanup and pep8-ification"
<jcater> I said not again
* jcater covers his ears
<jamest> where as "synching machines" translates to
<reinhard> jamest: you're right :)
*** d4rkstar has left #gnuenterprise
<jamest> "james, i'm breaking all your existing apps"
<reinhard> a propos app breaking
<reinhard> jamest: did you read the logs about trigger namespace?
<jcater> jamest: I'd consider those to be spring cleaning too
<jcater> how else would you be reminded about scripts you haven't looked at in years?
<jamest> reinhard: no, i've been preping to roll out new sales app tonight
<jamest> so haven't looked at anything GNUe since friday
<reinhard> jamest: pasted you in private window
<reinhard> if you have a minut
<reinhard> it's not urgent however
<jamest> so
<jamest> self.firstRecord() works but firstRecord() doesn't?
<reinhard> jamest: I've undone that change
<reinhard> because of jcater's remark
<jamest> lol
<jcater> reinhard: I'm not opposed to breaking massive amounts of jamest's forms
<jcater> I hope you didn't get that impression
<jcater> just ask him
<jamest> honestly, i think I've got in the habbit of working from form
<jamest> because things were flaky for awhile
<reinhard> I would like to know if adding self.__dict__ to the local namespace is intentional or should be depreciated
<jamest> so most my stuff is form.block.firstRecord()
<jamest> or block.firstRecord()
<jamest> i don't think I ever just assume a function is callable at the level I'm at
<jamest> well
<jamest> except for the ones declared global
<jamest> so that change should be the least of my worries regarding svn head forms :)
<jcater> reinhard: it was intentional
<reinhard> so I should remove it again?
<jcater> the question is, was it a good idea?
<reinhard> lol
<jamest> reinhard: i'm ok with the removal
<jamest> i would prefer to do self.function() in those cases anyway
<reinhard> ok
<jamest> so I could tell the form level global built-ins from the widget specific functions
<jamest> i should probably svn up soon and start testing :)
<jamest> as there are some issues here I told accounting they were going to live with for a few months
<reinhard> changed back
<reinhard> jamest: any feedback welcome
<reinhard> I think nobody uses triggers as much as you do
<jamest> i luvs my triggers
*** jamest has left #gnuenterprise
*** yure has quit IRC
*** kilo has joined #gnuenterprise
*** jcater has quit IRC
*** klasstek has quit IRC
*** lupo__ has quit IRC
*** sjc has quit IRC
<reinhard> good night all
*** reinhard has quit IRC
*** kilo has left #gnuenterprise
*** jcater has joined #gnuenterprise
*** derek has quit IRC
*** jcater has left #gnuenterprise
*** sacha has joined #gnuenterprise
*** derek has joined #gnuenterprise