On Thu, Jul 7, 2011 at 7:18 AM, Grant Edwards wrote:
> On 2011-07-06, Waldek M. wrote:
>> Dnia Wed, 06 Jul 2011 03:36:24 +1000, Steven D'Aprano napisa?(a):
>
>>> Because unless you are extremely disciplined, code and the comments
>>> describing them get out of sync. [...]
>
>> True, but that gets
On 2011-07-06, Waldek M. wrote:
> Dnia Wed, 06 Jul 2011 03:36:24 +1000, Steven D'Aprano napisa?(a):
>> Because unless you are extremely disciplined, code and the comments
>> describing them get out of sync. [...]
> True, but that gets far worse with external docs. Do you have in mind
> any bette
Dnia Wed, 06 Jul 2011 03:36:24 +1000, Steven D'Aprano napisał(a):
> Because unless you are extremely disciplined, code and the comments
> describing them get out of sync. [...]
True, but that gets far worse with external docs.
Do you have in mind any better replacement?
Br.
Waldek
--
http://mail.
On Wed, Jul 6, 2011 at 3:36 AM, Steven D'Aprano
wrote:
>
> Because unless you are extremely disciplined, code and the comments
> describing them get out of sync. Quote:
>
> "At Resolver we've found it useful to short-circuit any doubt and just
> refer to comments in code as 'lies'. "
> --Michael F
On 2011-07-05, Waldek M. wrote:
> Dnia Tue, 5 Jul 2011 14:11:56 + (UTC), Grant Edwards napisa?(a):
>> Because those specially-formatted comments are wrong.
>
> ... because?
In my experience, they're wrong because somebody changes the code and
not the comments.
> Not in sarcasm mode; just cur
Waldek M. wrote:
> Dnia Tue, 5 Jul 2011 14:11:56 + (UTC), Grant Edwards napisał(a):
>> Because those specially-formatted comments are wrong.
>
> ... because?
> Not in sarcasm mode; just curious why you don't like them.
Because unless you are extremely disciplined, code and the comments
descr
Dnia Tue, 5 Jul 2011 14:11:56 + (UTC), Grant Edwards napisał(a):
> Because those specially-formatted comments are wrong.
... because?
Not in sarcasm mode; just curious why you don't like them.
Br.
Waldek
--
http://mail.python.org/mailman/listinfo/python-list
On 2011-07-05, Tim Johnson wrote:
> * Ian Kelly [110704 20:37]:
>>
>> It sounds like what you really want is to detect the names *exported*
>> by the module, then. i
> Yes!
>> Why not do it the same way Python does it? If
>> the module defines an "__all__" attribute, then it is taken to be
* Ian Kelly [110704 20:37]:
>
> It sounds like what you really want is to detect the names *exported*
> by the module, then. i
Yes!
> Why not do it the same way Python does it? If
> the module defines an "__all__" attribute, then it is taken to be a
> sequence of strings which are the export
On 2011-07-05, Chris Angelico wrote:
> On Tue, Jul 5, 2011 at 10:01 AM, Tim Johnson wrote:
>>>Steven, I'm building a documentation system. I have my own MVC
>>>framework and the goal is to have a documentation module for each
>>>project.
>>
>
> Is there a reason for not using Doxygen / Autodoc /
On Mon, Jul 4, 2011 at 6:01 PM, Tim Johnson wrote:
>> Yes, but what are you actually *trying to do*? "Detecting data members" is
>> not an end in itself. Why do you think you need to detect data members?
>
> Steven, I'm building a documentation system. I have my own MVC framework
> and the goal
* Chris Angelico [110704 16:19]:
> On Tue, Jul 5, 2011 at 10:01 AM, Tim Johnson wrote:
> > Steven, I'm building a documentation system. I have my own MVC framework
> > and the goal is to have a documentation module for each project.
> >
>
> Is there a reason for not using Doxygen / Autodoc / e
On Tue, Jul 5, 2011 at 10:01 AM, Tim Johnson wrote:
> Steven, I'm building a documentation system. I have my own MVC framework
> and the goal is to have a documentation module for each project.
>
Is there a reason for not using Doxygen / Autodoc / etc, or at least
something in the same style? T
* Steven D'Aprano [110704 15:48]:
> Tim Johnson wrote:
>
> >> It seems to me that your approach here is unnecessarily complex and
> >> fragile. I don't know what problem you are trying to solve, but trying to
> >> solve it by intraspecting differences that aren't differences is surely
> >> the wr
Tim Johnson wrote:
>> It seems to me that your approach here is unnecessarily complex and
>> fragile. I don't know what problem you are trying to solve, but trying to
>> solve it by intraspecting differences that aren't differences is surely
>> the wrong way to do it.
> See my last post...
Yes
* Steven D'Aprano [110704 15:18]:
>
> You are mistaken. TestAddresses is *not* a member of an imported module. It
> is a member of the current module, which may or may not happen to point to
> the same object as the other module as well.
You are correct. I mispoke or misapplied. See my last post
Tim Johnson wrote:
> dir() will also show globals from other modules imported
> by the target module. So I would need a way to distinguish between
> those imported and those defined in
Why would you want to do that? Importing *is* a definition in
.
Consider these two code snippets:
#1
fr
* rantingrick [110704 13:47]:
> On Jul 4, 3:30 pm, Tim Johnson wrote:
> >
> > Thanks for the reply: *but*
> > dir() will also show globals from other modules imported
> > by the target module. So I would need a way to distinguish between
> > those imported and those defined in
>
> Okay,
* Chris Rebert [110704 13:16]:
> >
> > What else can I do here?
>
> Look at the names in the module's import statements using the `ast`
> module, and exclude those from the set of names defined in the module.
> Won't work for `from foo import *`, but that's bad practice and should
> be refactored
On Jul 4, 3:30 pm, Tim Johnson wrote:
>
> Thanks for the reply: *but*
> dir() will also show globals from other modules imported
> by the target module. So I would need a way to distinguish between
> those imported and those defined in
Okay, then do some processing on the source. You can
On Mon, Jul 4, 2011 at 11:11 AM, Tim Johnson wrote:
> Using Python 2.6 on ubuntu 10.04.
> inspect module :
> I want to 'inspect' a module and get a list of all
> functions, classes and global variables in that module.
You meant "first defined in" that module.
> Example, for a module name `mvcInst
* rantingrick [110704 12:00]:
> On Jul 4, 1:11 pm, Tim Johnson wrote:
>
> Well if you follow the python style guide (and most accepted styles
> for global notation) then it's a trial exercise. You don't even have
> to import anything!!! :)
>
> >>> GLOBAL_STR = 'str'
> >>> GLOBAL_FLOAT = 1.3
On Jul 4, 1:11 pm, Tim Johnson wrote:
> Using Python 2.6 on ubuntu 10.04.
> inspect module :
> I want to 'inspect' a module and get a list of all
> functions, classes and global variables in that module.
>
> ## A module has been imported, and we call `getmembers'
> members = inspect.getmembers(mod
Using Python 2.6 on ubuntu 10.04.
inspect module :
I want to 'inspect' a module and get a list of all
functions, classes and global variables in that module.
## A module has been imported, and we call `getmembers'
members = inspect.getmembers(mod)
## While iterating thru `members', we test to see
24 matches
Mail list logo
