C++ equivalent of comp.lang.python?
Hopefully this isn't too OT. One thing I like about comp.lang.python is the breadth of topics discussed here. People can ask about Python installation and configuration issues on specific platforms, compare third party libraries, ask for book recommendations, and discuss current Python projects. Lurking here has greatly increased my understanding of Python over the last year or so. I also do a lot of C++ development, but I've never found a similar discussion group for that language. comp.lang.c++ isn't what I'm looking for. I find it hard to get practical advice on that group because its focus is so narrow. I frequently see posters there redirect people to one of the OS-specific C++ groups, but most of my projects are cross-platform, so hanging out on one of those doesn't make sense either. As an example, I was recently trying to get information about writing cross-platform code for dynamic linking, but I couldn't find anywhere appropriate to ask about it. For those of you who work in C++, where do you go to discuss it online? I'm interested in any newsgroups, mailing lists, or web boards you can recommend. Thanks, Casey -- http://mail.python.org/mailman/listinfo/python-list
Re: Code Management
On Nov 20, 4:09 pm, Jens [EMAIL PROTECTED] wrote: Dear Reader, I'm writing some modules in Python, and I'm also using unittests. I'm wondering about some things: I'd love to hear how others manage this sort of thing as well. I'll describe what I've found works best for me, and if others do the same, maybe we can all learn from each other. 1) Should I put my unittests in a subdirectory? Does the subdirectory have to be a package? I put them in a subdirectory and make it a package. The biggest advantage I see of using a subdirectory is that I can have lots of test scripts and it's easy to keep them organized separately from production code. The biggest disadvantage is that if I run the test scripts from inside that subdirectory, they need to import modules from their parent directory, and I'm using Python 2.4 which doesn't have relative imports. So I put a .pth file in my site-packages directory that adds the top-level package of my project to the pythonpath. Then the test modules can import production code using the fully qualified package.subpackage.module name for each production module being tested. 2) Does the main folder /myproject have to be a package? Should I put my modules directly under /myproject, or should I create a subfolder, for example /myproject/modules I make all non-trivial projects into packages. It allows me to do the trick with a .pth file I described above. It makes it easier to reuse all or part of my project as a component of a second project. And it makes creating documentation with epydoc easier. I typically lay out a project directory something like this: projectname/ setup.py dev_install.py # automatically creates .pth file in site-packages alltests.py # runs all unit tests main_package_name/ __init__.py module1.py module2.py doc/ img/ subpackage1/ __init__.py module3.py module4.py tests/ __init__.py test1.py test2.py subpackage2/ etc With this setup, tests are organized by subpackage, and each test script can be run by itself, or all together from alltests.py. If a module in subpackage2 needs to import a module from subpackage1 (generally a sign of poor design, but it happens), it would need to use the fully qualified import main_package_name.subpackage1.module1. Each time I check a new copy of the project out from version control to a new location, I have to make that the active version by running dev_install.py, which puts a .pth file in site-packages that adds the newly checked out path to the pythonpath. As long as I remember that step, this approach works well. Does anyone have any best practices as to how to manage your code? Thanks! If anyone does, I'd love to hear about them. -Casey Raymondson -- http://mail.python.org/mailman/listinfo/python-list
Re: Linking debug C++ DLL with python dlls
On Nov 8, 4:07 am, [EMAIL PROTECTED] wrote: I tried to change the code above (just for fun) so in both cases i'll use python25.lib and in debug compilation I got linker errors on unresolved externals. seems like the debug version exports more methods than the release version. I usually just build my extensions in release mode and avoid using the debugger. Getting a copy of python24_d.lib (in my case) and building a debug version of my extension isn't a big deal, but afaik all my other extensions (wxPython, numpy, etc) have to be built in debug mode as well in order for things to work. If you find a good solution, please post it to the group because I'd like to know how to do this as well. -Casey -- http://mail.python.org/mailman/listinfo/python-list
Re: Tracebacks for `exec`ed code?
On Apr 29, 2:40 am, Martin v. Löwis [EMAIL PROTECTED] wrote: Adam Atlas schrieb: Is it possible to make more traceback information available for exceptions code dynamically run via `exec`? Normally it just says things like File 'string', line 3, in ?, which is not very helpful. I'm looking for a way for it to show the line of source code below it, like it would for an exception in a physical file. Is this possible? Yes. You will need to print the traceback yourself; see traceback.print_tb for an example. Regards Martin You could also write the code you want to execute to a temporary file, then use execfile() on that file. -Casey -- http://mail.python.org/mailman/listinfo/python-list
Re: comparison with None
On Apr 18, 3:19 pm, Steven Howe [EMAIL PROTECTED] wrote: I've read and found that 'None' comparisons is not always a good idea. Better to: from types import NoneType x = None if type( x ) == NoneType: # true code else: # false; do something else. more code Steven Howe Is that any better than this? if x is None: # do something else: # do something else -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie - needs help
On Apr 3, 4:28 pm, 7stud [EMAIL PROTECTED] wrote: Learning Python can be purchased at amazon.com. Or, not as good: Beginning Python: From Novice to Professional. If you get the second one, you'll need Python in a Nutshell: A Desktop Quick Reference to fill in all the gaps. If you already have experience with other programming languages, I think you might find that Learning Python is a bit too beginner- oriented. Dive into Python is probably a better choice for a first reading, IMO. -- http://mail.python.org/mailman/listinfo/python-list
