[issue40386] Strange behavior during invalid import of modules without if __name__ == "__main__"

Raymond Hettinger added the comment: Trying using "import this" instead of "import this.main". The latter does an "import this" and then attempts to load a "main" package that doesn't exist. You're observed the expected behavior. See

[issue40386] Strange behavior during invalid import of modules without if __name__ == "__main__"

Change by wyz23x2 : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40386] Strange behavior during invalid import of modules without if __name__ == "__main__"

wyz23x2 added the comment: Sorry, it's "of 'this' is run", not "un". -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40386] Strange behavior during invalid import of modules without if __name__ == "__main__"

Change by wyz23x2 : -- components: +Library (Lib) versions: +Python 3.7, Python 3.8, Python 3.9 ___ Python tracker ___ ___

[issue40386] Strange behavior during invalid import of modules without if __name__ == "__main__"

d "this" isn't actually imported after that; stranger is when you perform the correct import, it doesn't run. Is this right? -- messages: 367253 nosy: wyz23x2 priority: normal severity: normal status: open title: Strange behavior during invalid import of

Re: name 'aLOCK' is not defined When I add aLOCK = threading.RLock() behind if __name__ == "__main__"

On Fri, 10 Aug 2018 08:15:09 +0200, Karsten Hilbert wrote: > On Fri, Aug 10, 2018 at 12:24:25AM +0800, xuanwu348 wrote: > >> Yes, move the code from positionA(can run normally) to >> positionB(exception with name undefined) I find this content >>

Re: Re: name 'aLOCK' is not defined When I add aLOCK = threading.RLock() behind if __name__ == "__main__"

On Fri, Aug 10, 2018 at 12:24:25AM +0800, xuanwu348 wrote: > Yes, move the code from positionA(can run normally) to positionB(exception > with name undefined) > I find this content > "https://docs.python.org/3.3/tutorial/classes.html#python-scopes-and-namespaces; > But I still don't undewrstand

回复： Re: name 'aLOCK' is not defined When I add aLOCK = threading.RLock() behind if __name__ == "__main__"

Thanks, I think I get the answer. thanks all, have a good day! 从三星移动设备发送 原始邮件 发件人： MRAB 日期:2018-08-10 03:05 (GMT+08:00) 收件人： python-list@python.org 主题： Re: name 'aLOCK' is not defined When I add aLOCK = threading.RLock() behind if __name__ == "__main__" On

Re: name 'aLOCK' is not defined When I add aLOCK = threading.RLock() behind if __name__ == "__main__"

erence for the code between 'if __name__ == "__main__:"', can you help me, thanks! The file I was attached, please change the extend ".pyx" to ".py", thanks, code as below, tried python2.7 and python3.4: import threading import time from multiprocessing import

Re:Re: name 'aLOCK' is not defined When I add aLOCK = threading.RLock() behind if __name__ == "__main__"

scope. > > /python3-doc/html/tutorial/classes.html#python-scopes-and-namespaces > >> but when I change this code to PositionA, it can run normally, is there any >> difference for the code between 'if __name__ == "__main__:"', can you help >> me, thanks! >

Re: name 'aLOCK' is not defined When I add aLOCK = threading.RLock() behind if __name__ == "__main__"

/python3-doc/html/tutorial/classes.html#python-scopes-and-namespaces > but when I change this code to PositionA, it can run normally, is there any > difference for the code between 'if __name__ == "__main__:"', can you help > me, thanks! > > The file I wa

name 'aLOCK' is not defined When I add aLOCK = threading.RLock() behind if __name__ == "__main__"

Hi team Good day The problem I meet when I add "aLOCK = threading.RLock()" to PositionB, the program will report error "name 'aLOCK' is not defined ", but when I change this code to PositionA, it can run normally, is there any difference for the code between 'if __name__

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 12/01/2014 05:15 PM, Chris Angelico wrote: On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman wrote: Put the above somewhere in your path (e.g. /usr/local/bin), make it executable, and then instead of shebanging your scripts with `/usr/local/bin/python` you can use `/usr/local/bin/py_main`,

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 02Dec2014 02:17, Ethan Furman et...@stoneleaf.us wrote: On 12/01/2014 05:15 PM, Chris Angelico wrote: On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman wrote: Put the above somewhere in your path (e.g. /usr/local/bin), make it executable, and then instead of shebanging your scripts with

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 11/13/2014 10:32 AM, Ethan Furman wrote: On 11/12/2014 01:51 PM, Ian Kelly wrote: On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote: A decorator is an interesting idea, and should be easy to implement (only lightly tested): def main(func): if func.__module__ == __main__:

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 12/01/2014 03:19 PM, Ethan Furman wrote: Well, I've tried this out, and it's only okay. As soon as interesting things start happening, spurious errors about thread IDs start printing, which really messes up the user experience [...] So here's another thought: Have a small python

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Tue, Dec 2, 2014 at 11:45 AM, Ethan Furman et...@stoneleaf.us wrote: Put the above somewhere in your path (e.g. /usr/local/bin), make it executable, and then instead of shebanging your scripts with `/usr/local/bin/python` you can use `/usr/local/bin/py_main`, which will load and execute

Re: How about some syntactic sugar for __name__ == '__main__' ?

Steven D'Aprano wrote: Chris Kaynor wrote: I was thinking along the lines of replacing: if __name__ == __main__: block of code with @main def myFunction() block of code Both blocks of code will be called at the same time. You can't guarantee that, because you cannot tell

Re: How about some syntactic sugar for __name__ == '__main__' ?

Ian Kelly wrote: def main(func): if func.__module__ == __main__: func() return func # The return could be omitted to block the function from being manually called after import. Just decorate the main function of the script with that, and it will be automatically called

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Sun, Nov 16, 2014 at 3:39 AM, Vito De Tullio vito.detul...@gmail.com wrote: for the right time you can choose to spin a thread and wait to the end of the load of the module Yuck. Just add threads is /not/ the answer to everything. This case looks fairly harmless on the surface, although I

Re: How about some syntactic sugar for __name__ == '__main__' ?

John Ladasky wrote: I have taught Python to several students over the past few years. As I have worked with my students, I find myself bothered by the programming idiom that we use to determine whether a module is being executed or merely imported: if __name__ == '__main__': The use

Re: How about some syntactic sugar for __name__ == '__main__' ?

Chris Kaynor wrote: I was thinking along the lines of replacing: if __name__ == __main__: block of code with @main def myFunction() block of code Both blocks of code will be called at the same time. You can't guarantee that, because you cannot tell ahead of time when

Re: How about some syntactic sugar for __name__ == '__main__' ?

Steven D'Aprano steve+comp.lang.pyt...@pearwood.info: if __name__ == '__main__' or condition(): print still executing main() print done loading (I haven't ever done *all* of these things in a *single* file, but I have done all these things at one time or another.) There's no way

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 6:23 PM, Cameron Simpson c...@zip.com.au wrote: Indeed. This aspect is a deal breaker for me; I'd never use it. I make a point of putting the module's main function right up the top, immediately after the imports and any constants (let's not dither over that term). I

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 13Nov2014 19:04, Chris Angelico ros...@gmail.com wrote: On Thu, Nov 13, 2014 at 6:23 PM, Cameron Simpson c...@zip.com.au wrote: Indeed. This aspect is a deal breaker for me; I'd never use it. I make a point of putting the module's main function right up the top, immediately after the

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 7:47 PM, Cameron Simpson c...@zip.com.au wrote: My view is that if there's a main (i.e. the module implements a small app all on its own, however tiny), then the main program logic should come first. The details follow later. Ah, I see. Makes sense. It's kinda like an

Re: How about some syntactic sugar for __name__ == '__main__' ?

), then the main program logic should come first. The details follow later. Ah, I see. Makes sense. It's kinda like an executable docstring. Still not my preferred style, but makes its own sense. ChrisA I generally define a main() routine up near the top, then put if __name__ == '__main__': main

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Fri, Nov 14, 2014 at 12:33 AM, Roy Smith r...@panix.com wrote: ... you also get to not worry about what order things are defined. That's only as regards the interpreter, though. My point has nothing to do with the order the interpreter sees things, it's all about how they're laid out for

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 11/12/2014 01:51 PM, Ian Kelly wrote: On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote: A decorator is an interesting idea, and should be easy to implement (only lightly tested): def main(func): if func.__module__ == __main__: func() return func # The return could

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 11:32 AM, Ethan Furman et...@stoneleaf.us wrote: On 11/12/2014 01:51 PM, Ian Kelly wrote: On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote: A decorator is an interesting idea, and should be easy to implement (only lightly tested): def main(func): if

Re: How about some syntactic sugar for __name__ == '__main__' ?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/13/2014 12:33 PM, Ian Kelly wrote: On Thu, Nov 13, 2014 at 11:32 AM, Ethan Furman et...@stoneleaf.us wrote: On 11/12/2014 01:51 PM, Ian Kelly wrote: On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor wrote: A decorator is an interesting idea,

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 2:33 PM, Ian Kelly ian.g.ke...@gmail.com wrote: ... other things decorated with atexit.register might actually be called before the main function I don't think that will happen. The atexit module is documented to execute its exit functions in reverse order. What's not

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 2:44 PM, Skip Montanaro skip.montan...@gmail.com wrote: What's not documented is the behavior of calling atexit.register() while atexit._run_exitfuncs is running. That's an implementation detail, and though unlikely to change, it might be worthwhile getting that

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 1:44 PM, Skip Montanaro skip.montan...@gmail.com wrote: On Thu, Nov 13, 2014 at 2:33 PM, Ian Kelly ian.g.ke...@gmail.com wrote: ... other things decorated with atexit.register might actually be called before the main function I don't think that will happen. The atexit

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 1:53 PM, Skip Montanaro skip.montan...@gmail.com wrote: On Thu, Nov 13, 2014 at 2:44 PM, Skip Montanaro skip.montan...@gmail.com wrote: What's not documented is the behavior of calling atexit.register() while atexit._run_exitfuncs is running. That's an implementation

How about some syntactic sugar for __name__ == '__main__' ?

I have taught Python to several students over the past few years. As I have worked with my students, I find myself bothered by the programming idiom that we use to determine whether a module is being executed or merely imported: if __name__ == '__main__': The use of two dunder tokens -- one

Re: How about some syntactic sugar for __name__ == '__main__' ?

or merely imported: if __name__ == '__main__': The use of two dunder tokens -- one as a name in a namespace, and the other as a string, is intimidating. It exposes too much of Python's guts. As such, I think that it is less Pythonic than we might want. Myself, I've been programming

Re: How about some syntactic sugar for __name__ == '__main__' ?

It appears that I'm not the first person to have thoughts along these lines. Here's a relevant article: http://aliles.tumblr.com/post/7455032885/sugar-for-pythons-main -- https://mail.python.org/mailman/listinfo/python-list

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 11/12/2014 01:02 PM, John Ladasky wrote: I would like to start a discussion about whether Python should include a function which executes this evaluation, and hides all of the unfriendly dunderish details. And if that's a good idea, I would invite a discussion of how, exactly, it should

Re: How about some syntactic sugar for __name__ == '__main__' ?

by the programming idiom that we use to determine whether a module is being executed or merely imported: if __name__ == '__main__': The use of two dunder tokens -- one as a name in a namespace, and the other as a string, is intimidating. It exposes too much of Python's guts. As such, I think

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor ckay...@zindagigames.com wrote: A decorator is an interesting idea, and should be easy to implement (only lightly tested): def main(func): if func.__module__ == __main__: func() return func # The return could be omitted to

Re: How about some syntactic sugar for __name__ == '__main__' ?

John Ladasky john_lada...@sbcglobal.net: I find myself bothered by the programming idiom that we use to determine whether a module is being executed or merely imported: if __name__ == '__main__': I find the idiom cute and loveably silly. A typing tongue twister of sorts. That boilerplate

Re: How about some syntactic sugar for __name__ == '__main__' ?

def main(func): if func.__module__ == __main__: func() return func # The return could be omitted to block the function from being manually called after import. Just decorate the main function of the script with that, and it will be automatically called when ran as a

Re: How about some syntactic sugar for __name__ == '__main__' ?

script may not have been defined yet. One could place the main function last, but it would be preferable not to be forced. I was thinking along the lines of replacing: if __name__ == __main__: block of code with @main def myFunction() block of code Both blocks of code will be called

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Wed, Nov 12, 2014 at 3:09 PM, Chris Kaynor ckay...@zindagigames.com wrote: I was thinking along the lines of replacing: if __name__ == __main__: block of code with @main def myFunction() block of code Both blocks of code will be called at the same time. 99% of the time

Re: How about some syntactic sugar for __name__ == '__main__' ?

an implicit if __name__ == '__main__': main() at the end. I think this would not have to be added to the bytecode. This magical invocation mimics C and some other languages, and I think it works well. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list

Re: How about some syntactic sugar for __name__ == '__main__' ?

an implicit if __name__ == '__main__': main() at the end. I think this would not have to be added to the bytecode. This magical invocation mimics C and some other languages, and I think it works well. Yes, but it conflicts with the existing and common usage of having that explicitly in the code. Safer

Re: How about some syntactic sugar for __name__ == '__main__' ?

'. The simplest proposal is that modules have an implicit if __name__ == '__main__': main() at the end. I think this would not have to be added to the bytecode. This magical invocation mimics C and some other languages, and I think it works well. Yes, but it conflicts with the existing and common usage

Re: How about some syntactic sugar for __name__ == '__main__' ?

On Thu, Nov 13, 2014 at 11:35 AM, Terry Reedy tjre...@udel.edu wrote: Safer - and more in line with the way other such functions are written - would be a dunder function: if __name__ == '__main__': __main__() I presume you mean that calling __main__ implicitly would be both consistent

Re: How about some syntactic sugar for __name__ == '__main__' ?

On 12Nov2014 14:51, Ian Kelly ian.g.ke...@gmail.com wrote: On Wed, Nov 12, 2014 at 2:33 PM, Chris Kaynor ckay...@zindagigames.com wrote: A decorator is an interesting idea, and should be easy to implement (only lightly tested): [...] Just decorate the main function of the script with that, and

Re: Class changes in circular imports when __name__ == '__main__'

All right, thank you for helping! I'd had a little voice in the back of my mind nagging me that it might not be logical to include a bunch of classes and function definitions in my startup file, but I never got around to splitting it up. The module/script distinction makes sense, and it seems more

Re: Class changes in circular imports when __name__ == '__main__'

On 2:59 PM, Carl Banks wrote: On Sep 5, 5:07 pm, Dave Angelda...@ieee.org wrote: On 2:59 PM, Carl Banks wrote: All of this gets a lot more complicated when packages are involved. Perhaps a better answer would be to import __main__ from the second module. Then what if the module is

Re: Class changes in circular imports when __name__ == '__main__'

On Sep 6, 4:44 pm, Dave Angel da...@ieee.org wrote: On 2:59 PM, Carl Banks wrote: On Sep 5, 5:07 pm, Dave Angelda...@ieee.org   wrote: On 2:59 PM, Carl Banks wrote: All of this gets a lot more complicated when packages are involved. Perhaps a better answer would be to import __main__ from

Class changes in circular imports when __name__ == '__main__'

Hi! I'm writing a package with several files in it, and I've found that isinstance doesn't work the way I expect under certain circumstances. Short example: here are two files. # fileone.py import filetwo class AClass( object ): pass if __name__ == '__main__': a = AClass

Re: Class changes in circular imports when __name__ == '__main__'

if __name__ == '__main__': a = AClass() filetwo.is_aclass( a ) # filetwo.py import fileone def is_aclass( a ): print The argument is, ( if isinstance(a, fileone.AClass) else not), an instance of fileone.AClass If you run fileone.py, it will tell you that The argument

Re: Class changes in circular imports when __name__ == '__main__'

( object ):   pass if __name__ == '__main__':   a = AClass()   filetwo.is_aclass( a ) # filetwo.py import fileone def is_aclass( a ):   print The argument is, ( if isinstance(a, fileone.AClass) else not), an instance of fileone.AClass If you run fileone.py, it will tell you

Re: Class changes in circular imports when __name__ == '__main__'

filetwo class AClass( object ): pass if __name__ ='__main__': a =Class() filetwo.is_aclass( a ) # filetwo.py import fileone def is_aclass( a ): print The argument is, ( if isinstance(a, fileone.AClass) else not), an instance of fileone.AClass If you run fileone.py, it will tell

Re: Class changes in circular imports when __name__ == '__main__'

On Sep 5, 5:07 pm, Dave Angel da...@ieee.org wrote: On 2:59 PM, Carl Banks wrote: All of this gets a lot more complicated when packages are involved. Perhaps a better answer would be to import __main__ from the second module. Then what if the module is imported from a different script?

if __name__ == '__main__':

Hi, I am new to the python and not getting meaning of following line, if __name__ == '__main__': main() Thanks in advance. -- http://mail.python.org/mailman/listinfo/python-list

Re: if __name__ == '__main__':

On Thu, Mar 20, 2008 at 4:12 PM, Bhagwat Kolde [EMAIL PROTECTED] wrote: Hi, I am new to the python and not getting meaning of following line, if __name__ == '__main__': main() http://www.python.org/doc/faq/programming/#how-do-i-find-the-current-module-name -- Cheers, Simon B. [EMAIL

Re: if __name__ == '__main__':

Well, consider this: you have a file named mymodule.py, built like this: ~ #!/usr/bin/python def function: return data if __name__==__main__: print Unit test else: pass #module imported by another module/script ~~ If you type

Re: if __name__ == '__main__':

On Mar 20, 10:21 am, Simon Brunning [EMAIL PROTECTED] wrote: On Thu, Mar 20, 2008 at 4:12 PM, Bhagwat Kolde [EMAIL PROTECTED] wrote: Hi, I am new to the python and not getting meaning of following line, if __name__ == '__main__':       main() The if statement is used to skip the code

Re: if __name__ == '__main__':

meaning of following line, if __name__ == '__main__': main() The if statement is used to skip the code after the if statement in certain situations. If that if statement is in a file named test1.py, and you issue this command: $ python test1.py then the code after

Re: Replacing 'if __name__ == __main__' with decorator (was: Double underscores -- ugly?)

@mainmethod def main(...) and like this: @mainmethod(parser=myparser) def main(...) then you cannot use that decorator for a function that expects or allows a function as its first argument? Because how and If it's called with only one non-keyword parameter, then the language might have

Replacing 'if __name__ == __main__' with decorator (was: Double underscores -- ugly?)

On Feb 19, 10:01 am, Duncan Booth [EMAIL PROTECTED] wrote: Berwyn [EMAIL PROTECTED] wrote: Is it just me that thinks __init__ is rather ugly? Not to mention if __name__ == '__main__': ...? That ugliness has long been my biggest bugbear with python, too. The __name__ == '__main__' thing

The __name__ == '__main__' hack (was: Double underscores -- ugly?)

benhoyt [EMAIL PROTECTED] writes: Not to mention if __name__ == '__main__': ...? Unlike the double-underscore attribute names for signalling special meaning, that particular hack is IMO unnecessarily ugly. I don't, however, think it's likely to go away any time soon. If that's the ugliest

[ python-Feature Requests-1637365 ] if __name__=='__main__' missing in tutorial

=='__main__' missing in tutorial Initial Comment: I could not find any reference to the big idiom: if __name__==__main__: xxx() inside the Python tutorial. Of course it is documented in the Library Reference and the Reference Manual, but such an important idiom should be on the Tutorial

[ python-Feature Requests-1637365 ] if __name__=='__main__' missing in tutorial

=='__main__' missing in tutorial Initial Comment: I could not find any reference to the big idiom: if __name__==__main__: xxx() inside the Python tutorial. Of course it is documented in the Library Reference and the Reference Manual, but such an important idiom should be on the Tutorial

[ python-Feature Requests-1637365 ] if __name__=='__main__' missing in tutorial

: if __name__=='__main__' missing in tutorial Initial Comment: I could not find any reference to the big idiom: if __name__==__main__: xxx() inside the Python tutorial. Of course it is documented in the Library Reference and the Reference Manual, but such an important idiom should

newb: What is the purpose of if __name__ == __main__:

What is the purpose of if __name__ == __main__: If you have a module, does it get called automatically? -- http://mail.python.org/mailman/listinfo/python-list

Re: newb: What is the purpose of if __name__ == __main__:

johnny wrote: What is the purpose of if __name__ == __main__: If you have a module, does it get called automatically? http://docs.python.org/lib/module-main.html -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own

Re: newb: What is the purpose of if __name__ == __main__:

johnny wrote: What is the purpose of if __name__ == __main__: If you have a module, does it get called automatically? It is a common pattern to make one and the same source file usable as a program and as a module. When you import some python module its __name__ is never __main__. When

Re: newb: What is the purpose of if __name__ == __main__:

johnny [EMAIL PROTECTED] writes: What is the purpose of if __name__ == __main__: URL:http://www.python.org/infogami-faq/tutor/tutor-what-is-if-name-main-for/ -- \ He that would make his own liberty secure must guard even his | `\ enemy from oppression

Re: doctest, unittest, or if __name__='__main__'

Fredrik Lundh [EMAIL PROTECTED] writes: http://ianbicking.org/docs/pytest-presentation/pytest-slides.html (see the why not unittest slide for a list of issues with unittest) To see many of these points rebutted, see this post:

Re: doctest, unittest, or if __name__='__main__'

In article [EMAIL PROTECTED], Paul Rubin http://[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] [EMAIL PROTECTED] writes: I have noticed some distinctly funny and confused feelings I get when using the unittest module, stuff that feels clunky and odd about how it is set-up, however I thought

Re: doctest, unittest, or if __name__='__main__'

Paul The unpythonicness stems from it being basically a Paul reimplementation of JUnit, which was designed for use with Java. I think there are a few modules in Python which suffer that affliction. Skip -- http://mail.python.org/mailman/listinfo/python-list

Re: doctest, unittest, or if __name__='__main__'

Christoph Zwerschke wrote: Is this 'consensus opinion' or mainly your own opinion? It is just a consequence from the fact that unittest is actually a port from JUnit (Java) to Python, i.e. a consequence of trying to emulate a standard framework that many programmers are already familiar

Re: doctest, unittest, or if __name__='__main__'

Hi there Christopher, I was wondering if you (or anyone reading this ) could quickly summarize the ways in which unittest is unpythonic, or point me to somewhere which discusses this. Is this 'consensus opinion' or mainly your own opinion? Is there a summary somewhere (in addition to the Zen of

Re: doctest, unittest, or if __name__='__main__'

Terry Hancock wrote: When you get into stickier stuff like graphics and web programming, the formal structure of pyunit can be easier to adapt than something which is intrinsically based on string processing. As pointed out earlier in this thread, Zope 3 has embraced doctests in a big way

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] [EMAIL PROTECTED] writes: I have noticed some distinctly funny and confused feelings I get when using the unittest module, stuff that feels clunky and odd about how it is set-up, however I thought that this was just due to *my personal* lack of understanding of the deep

Re: doctest, unittest, or if __name__='__main__'

Marc 'BlackJack' Rintsch wrote: I see it this way: `unittest` is for testing code and `doctest` is for testing examples in docstrings. If you put all your tests in the docstrings there will be much code that's quite irrelevant for documenting the function/method/class. so put the tests in

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] wrote: and you can kill two birds with one stone. By that, do you mean you can write your tests and your docstrings in one shot with doctest? Exactly. '\n'.join(['Doctests are absolutely brilliant!'] * 100) They combine two brilliant ideas that are hard to do in

Re: doctest, unittest, or if __name__='__main__'

so you think that a why all this creativity when you could just standardize on something ported from java, and throw away every- thing else post is friendly ? really ? Sorry for the sloppy writing. Thanks for clarifying. I wrote: If unittest is the standard way to write test code, why do we

Re: doctest, unittest, or if __name__='__main__'

In [EMAIL PROTECTED], john_sips_tea wrote: For writing testcode, it looks like there's three ways that it's typically done: (1). using the doctest module, (2). using the unittest module (i.e. pyunit), or else (3). just putting an if __name__ = '__main__': at the bottom of your module

doctest, unittest, or if __name__='__main__'

For writing testcode, it looks like there's three ways that it's typically done: (1). using the doctest module, (2). using the unittest module (i.e. pyunit), or else (3). just putting an if __name__ = '__main__': at the bottom of your module containing code to manually run your class through

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] wrote For writing testcode, it looks like there's three ways that it's typically done: (1). using the doctest module, (2). using the unittest module (i.e. pyunit), or else (3). just putting an if __name__ = '__main__': at the bottom of your module containing code

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] wrote: If unittest is the standard way to write test code, why do we still have doctest? (I notice there's no mention in PEP 3000 of deprecating the doctest module). Because both have their pros and cons and their right to exist. Doctest is really easy to use and you can

Re: doctest, unittest, or if __name__='__main__'

On Mar 21, 2006, at 1:12 PM, Fredrik wrote: (I notice there's no mention in PEP 3000 of deprecating the doctest module). why is it that comp.lang.python is suddenly full of folks who want to deprecate anything they don't understand ? don't you have better things to do with your time ?

Re: doctest, unittest, or if __name__='__main__'

because it's a vastly superior way to write tests ? Well, since this is a mailing list where this sort of thing is discussed, and since I was was asking about which way is preferred, could you tell us why you (presumably) think doctest is vastly superior to unittest? why is it that

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] a écrit : For writing testcode, it looks like there's three ways that it's typically done: Actually, there's at least one more (1). using the doctest module, (2). using the unittest module (i.e. pyunit), or else (3). just putting an if __name__ = '__main__

Re: doctest, unittest, or if __name__='__main__'

and you can kill two birds with one stone. By that, do you mean you can write your tests and your docstrings in one shot with doctest? I would like to see yet another alternatise such as py.test in the standard lib, Ah: http://codespeak.net/py/current/doc/home.html --

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] [EMAIL PROTECTED][ For writing testcode, it looks like there's three ways that it's typically done: (1). using the doctest module, (2). using the unittest module (i.e. pyunit), or else (3). just putting an if __name__ = '__main__': at the bottom of your module containing

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] schrieb: Anyhow, I'm not attacking doctest, but rather, just trying to understand why there seems to be two very similar ways of testing your code built into the system (considering that one motto around here is There should be one -- and preferably only one -- obvious way

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] wrote: By that, do you mean you can write your tests and your docstrings in one shot with doctest? Right. The tests serve also as usage examples. -- http://mail.python.org/mailman/listinfo/python-list

Re: doctest, unittest, or if __name__='__main__'

On Tue, 21 Mar 2006 22:26:57 +0100 Christoph Zwerschke [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: If unittest is the standard way to write test code, why do we still have doctest? (I notice there's no mention in PEP 3000 of deprecating the doctest module). Because both have their

Re: doctest, unittest, or if __name__='__main__'

[EMAIL PROTECTED] wrote: Well, since this is a mailing list where this sort of thing is discussed, and since I was was asking about which way is preferred, could you tell us why you (presumably) think doctest is vastly superior to unittest? doctest comes with extensive documentation, which,