New user group: Rochester, MN, USA
http://www.meetup.com/PyRochesterMN/ First meeting is Thursday 28th Jan 2016. -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
New user group: Rochester, MN, USA
http://www.meetup.com/PyRochesterMN First meeting planned for Thu 28th January 2016 -- Jonathan Hartley tart...@tartley.com +1 507-513-1101 -- https://mail.python.org/mailman/listinfo/python-list
Re: easy_install doesn't install non-package *.py file
Hey. I don't know the details, but your setup.py needs to use either the 'package_data' or the 'data_files' entry in the dict you pass to setup. These can specify files you want included in the sdist which aren't package files. There are many complications with using them though. One of them in particular (I don't remember which one) installs the files you specify in a different place depending on whether the user is installing the sdist from local files (python setup.py install) or using pip, so be sure to test both ways. -- http://mail.python.org/mailman/listinfo/python-list
Re: leftover pyc files
I like to install a Bash shell of some kind on windows boxes I work on, specifically so I can use shell commands like this, just like on any other operating system. Cywin works just fine for this. svn also has hooks, but sadly not a checkout hook: http://svnbook.red-bean.com/en/1.1/ch05s02.html I guess you could write your own two-line wrapper script which does the checkout and then deletes the pyc files. I don't understand why deleting only some pyc files is important. Can't you just delete them all and let Python re generate the ones you need? I once saw someone create the longest python file they could to see how long generating pyc files takes, and it is very very quick indeed. A human could not notice the delay even for the largest of projects. Finally, someone asked about skipping .svn dirs: find has a '-prune' option, you can read about it on the manpage. -- http://mail.python.org/mailman/listinfo/python-list
Re: leftover pyc files
Apologies for all my messasges appearing twice. I'm using google groups web ui and have no idea why it's doing that. I'll stop using it. -- http://mail.python.org/mailman/listinfo/python-list
Re: leftover pyc files
A task like this is more suited to bash than Python:
find . -name '*.pyc' -exec rm '{}' ';'
--
http://mail.python.org/mailman/listinfo/python-list
Re: leftover pyc files
This can be added to git as a post-checkout hook:
In your project's .git/hooks/post-checkout:
#!/usr/bin/env bash
cd ./$(git rev-parse --show-cdup)
find . -name '*.pyc' -exec rm '{}' ';'
--
http://mail.python.org/mailman/listinfo/python-list
Re: leftover pyc files
This can be added to your project's .git/hooks/post-checkout:
#!/usr/bin/env bash
cd ./$(git rev-parse --show-cdup)
find . -name '*.pyc' -exec rm '{}' ';'
--
http://mail.python.org/mailman/listinfo/python-list
Re: executing arbitrary statements
Fair points Steven. Thanks for further refining my initial refinement. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: executing arbitrary statements
On Saturday, October 1, 2011 8:06:43 AM UTC+1, Chris Rebert wrote: On Fri, Sep 30, 2011 at 11:31 PM, Jason Swails jason@gmail.com wrote: I'm probably missing something pretty obvious, but I was wondering if there was a way of executing an arbitrary line of code somehow (such as a line of code based on user-input). There's the obvious use of eval that will evaluate a function call, but that doesn't allow all things. snip Because write is a function eval works fine for it. But since print isn't (2.7), it throws a syntax error. Likewise, variable assignments aren't allowed either as they are also not functions and lack a return value: snip Use the `exec` statement, which is capable of executing statements (as opposed to just expressions): http://docs.python.org/reference/simple_stmts.html#the-exec-statement What I'm more or less looking to do is present a (limited) form of an interpreter inside the application I'm writing for the advanced user. I'm also interested to hear if this is a particularly bad idea for any reason, It's potentially rather hacky and ad-hoc to effectively directly inject arbitrary statements at certain points in your code. Assuming you were to trust the user-provided code, callbacks/hooks or plugin modules are typically much cleaner ways to integrate custom code from the user. Depending on your particular use case, the `cmd` module might also be a workable alternative: http://docs.python.org/library/cmd.html and if there are security issues involved with allowing users to execute their own code inside my program (keeping in mind that some people may donate their scripts to others that may run them as black boxes). It is *very much* a security issue! Is it enough to disallow import statements, thereby not giving direct access to the sys and os modules? Not by a long shot! There are a bunch of known tricks that exploit introspection to circumvent such restrictions. Secure execution of untrusted Python code is a difficult problem. Some have accomplished it to a degree, but typically only by modifying the interpreter itself or imposing relatively onerous restrictions on the untrusted code. I know more or less what I want to do, but I'd also appreciate any experienced input/advice/suggestions. I additionally came across this in researching my reply: http://pypi.python.org/pypi/RestrictedPython/ Apparently the speed of execution leaves something to be desired, but the package /supposedly/ works well otherwise. Cheers, Chris -- http://rebertia.com I (and many others) entirely avoid using 'eval' in all my code for many years, based on the security concerns that Chris rightly highlights. It's worth noting though, that RaymondH's talks last year on some valid uses of 'eval' and 'exec' have opened my eyes to it somewhat. In summary, while it's dangerous to execute user-submitted code, there are no security risks associated with executing code generated by your own program. It takes a while to see how this might be useful, if (like me) you're not used to thinking about it. Raymond's premier example was his implementation of namedtuple: (see http://hg.python.org/cpython/file/default/Lib/collections/__init__.py) This defines a string, the contents of which is a class definition, with some string formatting markers in it. These are replaced with known values on invocation of the namedtuple factory function, which then exec's the class-definition string and returns the resulting new type. This results in an implementation that is both simpler and faster than trying to simply write a general-purpose class that does at runtime all the things that 'namedtuple' does. -- http://mail.python.org/mailman/listinfo/python-list
Re: cause __init__ to return a different class?
Perhaps a more idiomatic way of achieving the same thing is to use a factory function, which returns instances of different classes: def PersonFactory(foo): if foo: return Person() else: return Child() Apologies if the code is messed up, I'm posting from Google groups web UI. -- http://mail.python.org/mailman/listinfo/python-list
Re: How to structure packages
On Thursday, September 8, 2011 1:29:26 AM UTC+1, Steven D#39;Aprano wrote: Steven D'Aprano wrote: Other than that, is there any justification for this rule? Any Java fans want to defend this? If one class per file, why not one method per class too? Why is the second rule any more silly than the first? Hey. I'm not a Java fan but I'll give it a go. One method per class is not a good idea because a class is a bunch of code that forms a coherent conceptual bundle of functionality. Often, to provide such a bundle, it requires more than one method. To split these methods across several classes would be splitting up a single coherent entity, which makes it harder to understand the purpose and identity of the entity, and more fiddly to delineate the boundary between one such entity and the next. On the other hand, IMHO one class per file is often a good idea. Since a class is a single coherent bundle, then the natural way to split a program into files is often to divide it into these same coherent bundles. Sometimes you have two or more classes that are conceptually very tightly coupled, and it makes sense to gather them up into a single file. However, for me, this is the exception rather than the rule, so in the general case, I usually end up with code that has one class per file. It's only a rule-of-thumb though, and should be broken whenever it seems appropriate. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can someone help please
Hey! Is Billy a responder, rather than the OP? Sorry then! My previous point is entirely nullified. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can someone help please
Hey Billy. That may not be the important part of the code, but the many people giving up their free time to read it and help you don't know that. It's probably most helpful to give them a working example so as not to waste their time. Just sayin for future, is all. :-) Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Functional style programming in python: what will you talk about if you have an hour on this topic?
On Jul 13, 1:39 pm, Anthony Kong anthony.hw.k...@gmail.com wrote:
(My post did not appear in the mailing list, so this is my second try.
Apology if it ends up posted twice)
Hi, all,
If you have read my previous posts to the group, you probably have some idea
why I asked this question.
I am giving a few presentations on python to my colleagues who are mainly
java developers and starting to pick up python at work.
personal opinion
So I have picked this topic for one of my presentation. It is because
functional programming technique is one of my favorite in my bag of python
trick. It also takes me to the rabbit hole of the functional programming
world, which is vastly more interesting than the conventional procedural/OO
languages.
/personal opinion
I think I will go through the following items:
itertools module
functools module
concept of currying ('partial')
I would therefore want to ask your input e.g.
Is there any good example to illustrate the concept?
What is the most important features you think I should cover?
What will happen if you overdo it?
Cheers
I'd think you'd want to at least mention the relatively new
'lru_cache' decorator, for memoizing the return value expensive
functions, providing they are deterministic / pure, etc.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Functional style programming in python: what will you talk about if you have an hour on this topic?
On Jul 14, 4:32 am, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: Anthony Kong wrote: So I have picked this topic for one of my presentation. It is because functional programming technique is one of my favorite in my bag of python trick. I'm not sure it's a good idea to emphasise functional programming too much. Python doesn't really lend itself to a heavily functional style. While you *can* write Python code that way, it's not idiomatic, and you're likely to give beginners a distorted idea of how Python is normally written. -- Greg Maybe the talk would work well if not aimed at complete all-round beginners, but instead aimed at Pythonistas who are interested in functional programming, or functionistas who are py-curious (I think the same talk would work well for both groups) -- http://mail.python.org/mailman/listinfo/python-list
Re: lightweight way to create new projects from templates
Hey Chris, Thanks for the thoughts. I must confess I had already given up on a 'single file' approach, because I want to make it easy for people to create their own templates, so I have to handle copying a template defined by creating a new directory full of diles. If I'm already handling this case, I thought, I might as well bundle the built-in default templates as a bunch of files. I'd hope to provide platform binaries to make download and install easy for end-users, regardless of what Python version they already have installed. Which reminds me, I should make sure the default template works on Python2.x as well as 3.x. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
lightweight way to create new projects from templates
Hi.
I'm looking for a quick way to create new Python projects from a template.
I understand that 'Paste' (http://pythonpaste.org/) is one way to do
this, but I find Paste very intimidating because of all the
functionality it includes. I'm not even sure whether 'creating new
projects from templates' is the central goal of Paste, or just an
incidental benefit that it provides while performing some other task.
As a lightweight alternative, I'm creating a project called 'Genesis'.
Functionally, it will be little more than a 'cp -r' followed by a few
search and replace operations.
I realise this idea is modest, but I think it could be helpful for:
a) people who are just getting started with Python, and want to see how
best to structure their projects, and
b) people who are already up-to-speed, and who want to create their own
templates and spawn projects from them with a minimum of effort.
c) for the community, to exemplify and publicise best practices for new
projects.
My goals include:
* Create a new project using the default template:
$ genesis myproj
* or using a particular project template:
$ genesis --template=mytemplate myproj
* Allow people to create their own templates, simply stored as
directories under '~/.genesis'
* Files in a template contain 'tags' of the form 'G{author}'. When a new
project is created, these tags are replaced. For example, G{author} will
be replaced with the value for 'author' supplied either on the command-line:
$ genesis myproj author=Jonathan
Or in your ~/.genesis/config file (a python file read using 'exec'):
author = 'Jonathan'
* The default template should embody good practices like those
demonstrated in the Python Project howto:
http://infinitemonkeycorps.net/docs/pph/
* The default template should include a setup.py, supporting sdist,
register and upload commands.
* I'd also like the default template to include things like creating
Windows binaries, so that it is easier for projects to include this out
of the box. It would be nice to extend this to binaries for other
platforms too.
* The default template for command-line applications should include an
acceptance test, which invokes the script in a new process and makes
assertions about stdout, stderr and exit value.
* One of my inspirations is to create a good template for events like
pyweek, where many people set out to write opengl or pyglet applications
from scratch, and yet every time, many entrants fail to properly create
binaries, etc.
Genesis is only partially written, so is not yet on PyPI, but is on
bitbucket:
https://bitbucket.org/tartley/genesis/overview
If you have any feedback, it would be very welcome. In particular:
What do you think about the approach in general?
What do you think about the contents of my default template:
https://bitbucket.org/tartley/genesis/src/tip/genesis/config/default/
Do you think a single default template containing all the above ideas is
viable? Or is it likely to be so idiosyncratic that I might be better
shipping with several built-in templates, including a 'minimal' one? Do
I need different templates for applications than for libraries? For
console apps vs GUI apps?
What do you think of my choice of 'G{name}' for replaceable tags in the
template? I wanted something that would not be valid Python, and would
be unlikely to occur naturally in a project.
Best regards,
Jonathan
--
Jonathan Hartleytart...@tartley.comhttp://tartley.com
Made of meat. +44 7737 062 225 twitter/skype: tartley
--
http://mail.python.org/mailman/listinfo/python-list
Re: Development tools and practices for Pythonistas
On Apr 26, 3:39 pm, snorble snor...@hotmail.com wrote: I appreciate any advice or guidance anyone has to offer. The 'Python Project HOWTO' gives good advice in terms of setting up a new project, what files and directories to create, what to put in version control, etc: http://infinitemonkeycorps.net/docs/pph/ Also, where I work we have tried many IDEs, but happily and productively use GVim and very little else, so don't feel you *have* to use an IDE. Best regards, Jonathan Hartley -- http://mail.python.org/mailman/listinfo/python-list
Re: Vectors
On Apr 20, 2:43 pm, Andreas Tawn andreas.t...@ubisoft.com wrote: Algis Kabaila akaba...@pcug.org.au writes: Are there any modules for vector algebra (three dimensional vectors, vector addition, subtraction, multiplication [scalar and vector]. Could you give me a reference to such module? NumPy has array (and matrix) types with support for these basic operations you mention. See the tutorial athttp://numpy.scipy.org/ You might also want to considerhttp://code.google.com/p/pyeuclid/ Cheers, Drea Stealing this from Casey Duncan's recent post to the Grease users list: - (ab)use complex numbers for 2D vectors (only). Very fast arithmetic and built-in to Python. Downside is lack of abstraction. - Use pyeuclid (pure python) if ultimate speed isn't an issue, or if compiled extensions are. It supports 3D and has a nice api - vectypes is a more recent project from the same author as pyeuclid. It offers a more consistent 'GLSL' like interface, including swizzling, and internally seems to have more maintainable code because it generates various sizes of vector and matrix from a single template. This is done without performance penalty because the generation is done at design time, not runtime. - Use pyeigen if you want fast vectors, and don't mind compiling some C/C++. I don't know how the Python api looks though - Use numpy if you want fast batch operations -- http://mail.python.org/mailman/listinfo/python-list
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
Changes by Jonathan Hartley tart...@tartley.com: -- nosy: +jonathan.hartley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9228] Make changes in the PATH and PATHEXT on installation
Changes by Jonathan Hartley tart...@tartley.com: -- nosy: +jonathan.hartley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9228 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11796] list and generator expressions in a class definition fail if expression condition refers to a class variable
Jonathan Hartley tart...@tartley.com added the comment: Is also exhibited by other class variable being used in the 'output' clause of the list comprehension: class C: ... x = 3 ... z = [z*x for z in range(4)] Traceback (most recent call last): File stdin, line 1, in module File stdin, line 3, in C File stdin, line 3, in listcomp -- nosy: +jonathan.hartley versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11796 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11407] unittest.TestCase.run should return result
Jonathan Hartley tart...@tartley.com added the comment: Attached patch fixes this. TestCase.run now returns its TestResult object, regardless of whether it was passed in or created internally. Test assertions added for this. Invoking an instance of TestCase already returned the return value of .run, so the result is correctly propagated. New test added that verifies that .__call__ delegates to .run. Fix for an unrelated minor typo in the docs also bundled into this patch: Fixed the versionchanged:: markup for class TestCase. This is my first patch submission, please help me out if I mess it up. Thanks. -- keywords: +patch nosy: +tartley Added file: http://bugs.python.org/file21131/issue11407.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Efficient python 2-d arrays?
On Jan 17, 10:20 pm, Jake Biesinger jake.biesin...@gmail.com wrote:
Hi all,
Using numpy, I can create large 2-dimensional arrays quite easily.
import numpy
mylist = numpy.zeros((1,2), dtype=numpy.int32)
Unfortunately, my target audience may not have numpy so I'd prefer not to use
it.
Similarly, a list-of-tuples using standard python syntax.
mylist = [(0,0) for i in xrange(1)
but this method uses way too much memory (4GB for 100 million items,
compared to 1.5GB for numpy method).
Since I want to keep the two elements together during a sort, I *can't* use
array.array.
mylist = [array.array('i',xrange(1)),
array.array('i',xrange(1))]
If I knew the size in advance, I could use ctypes arrays.
from ctypes import *
class myStruct(Structure):
_fields_ = [('x',c_int),('y',c_int)]
mylist_type = myStruct * 1
mylist = mylist_type()
but I don't know that size (and it can vary between 1 million-200 million),
so preallocating doesn't seem to be an option.
Is there a python standard library way of creating *efficient* 2-dimensional
lists/arrays, still allowing me to sort and append?
Thanks!
Since you can't depend on your users installing the dependencies, is
it vital that your users run from source? You could bundle up your
application along with numpy and other dependencies using py2Exe or
similar. This also means you wouldn't have to require users to have
the right (or any) version of Python installed.
--
http://mail.python.org/mailman/listinfo/python-list
Re: is py2exe still active ?
On Dec 8, 10:09 am, Octavian Rasnita orasn...@gmail.com wrote: Hi Steve, I may put some stupid questions because I am very new to Python, but... I heard about pypi/pip. Aren't all these Python libraries (like cxFreeze) provided on a central archive where we can get them and also report the bugs using a single request/issue tracker? Octavian - Original Message - From: Steve Holden st...@holdenweb.com Newsgroups: gmane.comp.python.general To: Octavian Rasnita orasn...@gmail.com Cc: python-l...@python.org Sent: Wednesday, December 08, 2010 12:56 AM Subject: Re: is py2exe still active ? Octavian: It's great that you want to let people know about bugs. Put yourself in the position of the package maintainer, however. She or he doesn't spend all day working on cxFreeze, and probably doesn't even do a Google search on cxFreeze very often. So they are unlikely to find out about this problem form your well-intentioned note. It's just possible nobody does care, as I can't find a link to an issue tracker - the best I could advise in this case would be to join the mailing list by visiting https://lists.sourceforge.net/lists/listinfo/cx-freeze-users regards Steve On 12/7/2010 6:49 PM, Octavian Rasnita wrote: This packager is also nice. If someone cares, I've discovered a small bug in it. If Python is installed on another drive than C under Windows, the cxfreeze.bat file still calls Python on the drive C and it doesn't work until it is corrected. Octavian - Original Message - From: Cbast sebastien.fri...@gmail.com Newsgroups: comp.lang.python To: python-l...@python.org Sent: Tuesday, December 07, 2010 5:00 PM Subject: Re: is py2exe still active ? On Dec 7, 8:23 am, Anders Persson anders.u.pers...@gmail.com wrote: Hi! When a look att py2exe homepage it is not looking like mutch happen, as a beginner i was thinking to start with Python 3, but i like to now if py2exe will be for 3 too. Is any one have any info ? I don't have the answer about py2exe, but I'm using cxFreeze to create executables with Python 3.1, if it's what you're looking for. http://cx-freeze.sourceforge.net/ -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ Hey, Yes, they are all Python packages or applications, and yes, PyPI aka The Cheese Shop is a single repository for them. However, they do not share mailing lists or issue trackers. Each project maintains its own bug tracking, etc. Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: is py2exe still active ?
On Dec 8, 10:09 am, Octavian Rasnita orasn...@gmail.com wrote: Hi Steve, I may put some stupid questions because I am very new to Python, but... I heard about pypi/pip. Aren't all these Python libraries (like cxFreeze) provided on a central archive where we can get them and also report the bugs using a single request/issue tracker? Octavian - Original Message - From: Steve Holden st...@holdenweb.com Newsgroups: gmane.comp.python.general To: Octavian Rasnita orasn...@gmail.com Cc: python-l...@python.org Sent: Wednesday, December 08, 2010 12:56 AM Subject: Re: is py2exe still active ? Octavian: It's great that you want to let people know about bugs. Put yourself in the position of the package maintainer, however. She or he doesn't spend all day working on cxFreeze, and probably doesn't even do a Google search on cxFreeze very often. So they are unlikely to find out about this problem form your well-intentioned note. It's just possible nobody does care, as I can't find a link to an issue tracker - the best I could advise in this case would be to join the mailing list by visiting https://lists.sourceforge.net/lists/listinfo/cx-freeze-users regards Steve On 12/7/2010 6:49 PM, Octavian Rasnita wrote: This packager is also nice. If someone cares, I've discovered a small bug in it. If Python is installed on another drive than C under Windows, the cxfreeze.bat file still calls Python on the drive C and it doesn't work until it is corrected. Octavian - Original Message - From: Cbast sebastien.fri...@gmail.com Newsgroups: comp.lang.python To: python-l...@python.org Sent: Tuesday, December 07, 2010 5:00 PM Subject: Re: is py2exe still active ? On Dec 7, 8:23 am, Anders Persson anders.u.pers...@gmail.com wrote: Hi! When a look att py2exe homepage it is not looking like mutch happen, as a beginner i was thinking to start with Python 3, but i like to now if py2exe will be for 3 too. Is any one have any info ? I don't have the answer about py2exe, but I'm using cxFreeze to create executables with Python 3.1, if it's what you're looking for. http://cx-freeze.sourceforge.net/ -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon 2011 Atlanta March 9-17 http://us.pycon.org/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ Hey, Yes, they are all Python packages or applications, and yes, PyPI aka The Cheese Shop is a single repository for them. However, they do not share mailing lists or issue trackers. Each project maintains its own bug tracking, etc. Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: unittests with different parameters
On Nov 22, 11:38 am, Ulrich Eckhardt ulrich.eckha...@dominolaser.com wrote: Hi! I'm writing tests and I'm wondering how to achieve a few things most elegantly with Python's unittest module. Let's say I have two flags invert X and invert Y. Now, for testing these, I would write one test for each combination. What I have in the test case is something like this: def test_invert_flags(self): test flags to invert coordinates tests = [((10, 20), INVERT_NONE, (10, 20)), ((10, 20), INVERT_X, (-10, 20)), ((10, 20), INVERT_Y, (10, -20))] for input, flags, expected in tests: res = do_invert(input, flags) self.assertEqual(res, expected, %s caused wrong results % (flags,)) So, what I do that I test the function 'do_invert' for different input combinations and verify the result. The ugly thing is that this will abort the whole test if one of the tests in the loop fails. So, my question is how do I avoid this? I know that I could write a common test function instead: def _test_invert_flags(self, input, flags, expected): res = do_invert(input, flags) self.assertEqual(res, expected) def test_invert_flags_non(self): test not inverting coordinates self._test_invert_flags((10, 20), INVERT_NONE, (10, 20)) def test_invert_flags_x(self): test inverting X coordinates self._test_invert_flags((10, 20), INVERT_X, (-10, 20)) def test_invert_flags_y(self): test inverting Y coordinates self._test_invert_flags((10, 20), INVERT_Y, (10, -20)) What I don't like here is that this is unnecessarily verbose and that it basically repeats information. Also, I'd rather construct the error message from the data instead of maintaining it in different places, because manually keeping those in sync is another, errorprone burden. Any suggestions? Uli -- Domino Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 The following is a bit ghastly, I'm not sure I'd recommend it, but if you are determined, you could try dynamically adding test methods to the test class. The following is untested - I suspect I have made a schoolboy error in attempting to make methods out of functions - but something like it might work: class MyTestClass(unittest.TestCase): pass testdata = [ (INPUTS, EXPECTED), (INPUTS, EXPECTED), (INPUTS, EXPECTED), ] for index, (input, expected) in enumerate(testdata): # the following sets an attribute on MyTestClass # the names of the attributes are 'test_1', 'test_2', etc # the value of the attributes is a test method that performs the assert setattr( MyTestClass, 'test_%d' % (index,), lambda s: s.assertEquals(METHOD_UNDER_TEST(*input), expected) ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Ways of accessing this mailing list?
On Nov 3, 9:27 pm, Ben Finney ben+pyt...@benfinney.id.au wrote: Grant Edwards inva...@invalid.invalid writes: On 2010-11-02, John Bond li...@asd-group.com wrote: My normal inbox is getting unmanageable, and I think I need to find a new way of following this and other lists. Point an NNTP client at new.gmane.org. Ditto, but the correct hostname is ‘news.gmane.org’. Hey. I'm was trying this, and got stuck for a while. I have found 'gmane.comp.python.devel', which looks great for lurking, along with many other entries under gmane.comp.python.*. But I couldn't find *this* list (comp.lang.python) for ages, despite scrutinising possible aliases. For anyone else in the same boat, you are looking for gmane.comp.python.general. Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: playful coding problems for 10 year olds
On Nov 1, 8:31 pm, Daniel Fetchinson fetchin...@googlemail.com wrote: Hi folks, My niece is interested in programming and python looks like a good choice (she already wrote a couple of lines :)) She is 10 and I thought it would be good to have a bunch of playful coding problems for her, stuff that she could code herself maybe after some initial help. Do you guys know problems like these? Or a good resource where to look them up? Cheers, Daniel -- Psss, psss, put it down! -http://www.cafepress.com/putitdown There's a great book valled 'Invent your own computer games using Python', aimed at kids, which teaches programming from tne ground up, in the context of writing games, starting with terminal word games, ending with Pygame fullscreen 2D vector graphic bitmaps affairs. http://inventwithpython.com/ The website says aimed at kids 'ages 10 to 12 and upwards', so it sounds like she's on the minimum cusp. (now I come to look at the website, one of the quotes he features is from an Amazon review I wrote months ago! :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: OO and game design questions
On Oct 20, 12:11 pm, dex josipmisko...@gmail.com wrote: On Oct 20, 12:25 pm, Jonathan Hartley tart...@tartley.com wrote: On Oct 18, 8:28 am, dex josipmisko...@gmail.com wrote: I'm building a turn based RPG game as a hobby. The design is becoming increasingly complicated and confusing, and I think I may have tendency to over-engineer simple things. Can anybody please check my problems-solutions and point me to more elegant solution? Every item/character/room is a separate object. Items/characters need to have references to room they are in, and room needs to have a list of references to items/characters that are contained within. I decided to use weak references. That way I can destroy object by deleting it, I don't have to destroy all references as well. In each object's __init__() that object is added to game_object list, and in each __del__() they are removed from game_object list. This mechanism keeps them safe from garbage collector. How pythonic is this design? In turn-based games, the order of action execution in battle can give unfair advantage to players. For example, if player's arm is crippled before his action is executed, he would do less damage. To offset this, I first execute all players' actions and calculate effects in first pass, then apply the effects in second pass. The effect can be health decrease by 15HP, item pick-up, 30p experience gain, etc. This means the player deals the same amount of damage no matter what happens to him in that turn. The difficult part is keeping track of various effects. I had to make separate class for various types of effects (ChangeAttributeEffect, GetItemEffect, LooseItemEffect). Each class stores weak reference to target object and has apply() method that applies the effect to object. I'm not satisfied with this as it's limiting, error-prone and uses metaprogramming. Is there a design pattern that would remember changes to an object, and apply them later? Sorry for the wall of text. One common way to store delayed actions is as a lambda (an anonymous function.) A lambda defines a new function: , and you can call this function later. The created function has no name, (but you can assign it to a variable to give it a name if you like) and can be called later: So in the game, you could have a collection 'effects', each one will be a lambda: effects = [] At the start of the round, as each entity makes its moves, they add lambdas to this collection. effects.append( lambda: decrease_hp(monster_a, 4) ) effects.append( lambda: lose_item(monster_a, item_b) ) Instead of appending it directly like this, I imagine the lambdas could be returned by the monster's 'act' or 'update' method: class Monster(): def act(self): # blah and finally return lambda: decrease_hp(monster_a, 4) Then for the start of a round, first you ask each monster what action it is going to perform: for monster in room.monsters: effects.append( monster.act() ) Then for the end of the round, call all the lambdas for effect in effects: effect() Mr. Roy Smith already proposed using closures. I already did a similar thing in my code, but instead of decrease_hp() I have AttributeEffect class which is able to modify any attribute (in old RPGs some monsters could drain your intelligence, in my game laser gun hit will decrease HP as well as armor integrity). The first version looks like this (missing few checks): class AttributeEffect(object): '''Effect changes object's attribute by delta''' def __init__(self, obj, attrib, delta): self.obj = obj # reference to object the effect applies to self.attrib = attrib # name of attribute that effect applies to self.delta = delta # change of value for object.attribute def apply(self): value = getattr(self.obj, self.attrib) # todo: try, except value += self.delta setattr(self.obj(), self.attrib, value) Yesterday I learned that Python 3.0 introduces nonlocal keyword which would simplify defining effect functions and passing them along. Nice improvement. Very cool, that looks like it would work. The thing I like about the lambda idea though, is that you don't have to write any classes like AttributeEffect, (and presumably other such classes, like LoseItemEffect, etc.) Instead of *modelling* the different kind of effects that could happen, you just write code that *performs* the desired effect. (e.g. monster.hp -= damage) To my eyes, lambda's are therefore more flexible and require less code. But I could be wrong, and obviously you should do what you think is best for your circumstances. Very best of luck with it. Out of interest, is there anywhere you blog about the game development, or are likely to make
Re: OO and game design questions
On Oct 20, 12:11 pm, dex josipmisko...@gmail.com wrote: On Oct 20, 12:25 pm, Jonathan Hartley tart...@tartley.com wrote: On Oct 18, 8:28 am, dex josipmisko...@gmail.com wrote: I'm building a turn based RPG game as a hobby. The design is becoming increasingly complicated and confusing, and I think I may have tendency to over-engineer simple things. Can anybody please check my problems-solutions and point me to more elegant solution? Every item/character/room is a separate object. Items/characters need to have references to room they are in, and room needs to have a list of references to items/characters that are contained within. I decided to use weak references. That way I can destroy object by deleting it, I don't have to destroy all references as well. In each object's __init__() that object is added to game_object list, and in each __del__() they are removed from game_object list. This mechanism keeps them safe from garbage collector. How pythonic is this design? In turn-based games, the order of action execution in battle can give unfair advantage to players. For example, if player's arm is crippled before his action is executed, he would do less damage. To offset this, I first execute all players' actions and calculate effects in first pass, then apply the effects in second pass. The effect can be health decrease by 15HP, item pick-up, 30p experience gain, etc. This means the player deals the same amount of damage no matter what happens to him in that turn. The difficult part is keeping track of various effects. I had to make separate class for various types of effects (ChangeAttributeEffect, GetItemEffect, LooseItemEffect). Each class stores weak reference to target object and has apply() method that applies the effect to object. I'm not satisfied with this as it's limiting, error-prone and uses metaprogramming. Is there a design pattern that would remember changes to an object, and apply them later? Sorry for the wall of text. One common way to store delayed actions is as a lambda (an anonymous function.) A lambda defines a new function: , and you can call this function later. The created function has no name, (but you can assign it to a variable to give it a name if you like) and can be called later: So in the game, you could have a collection 'effects', each one will be a lambda: effects = [] At the start of the round, as each entity makes its moves, they add lambdas to this collection. effects.append( lambda: decrease_hp(monster_a, 4) ) effects.append( lambda: lose_item(monster_a, item_b) ) Instead of appending it directly like this, I imagine the lambdas could be returned by the monster's 'act' or 'update' method: class Monster(): def act(self): # blah and finally return lambda: decrease_hp(monster_a, 4) Then for the start of a round, first you ask each monster what action it is going to perform: for monster in room.monsters: effects.append( monster.act() ) Then for the end of the round, call all the lambdas for effect in effects: effect() Mr. Roy Smith already proposed using closures. I already did a similar thing in my code, but instead of decrease_hp() I have AttributeEffect class which is able to modify any attribute (in old RPGs some monsters could drain your intelligence, in my game laser gun hit will decrease HP as well as armor integrity). The first version looks like this (missing few checks): class AttributeEffect(object): '''Effect changes object's attribute by delta''' def __init__(self, obj, attrib, delta): self.obj = obj # reference to object the effect applies to self.attrib = attrib # name of attribute that effect applies to self.delta = delta # change of value for object.attribute def apply(self): value = getattr(self.obj, self.attrib) # todo: try, except value += self.delta setattr(self.obj(), self.attrib, value) Yesterday I learned that Python 3.0 introduces nonlocal keyword which would simplify defining effect functions and passing them along. Nice improvement. Very cool, that looks like it would work. The thing I like about the lambda idea though, is that you don't have to write any classes like AttributeEffect, (and presumably other such classes, like LoseItemEffect, etc.) Instead of *modelling* the different kind of effects that could happen, you just write code that *performs* the desired effect. (e.g. monster.hp -= damage) To my eyes, lambda's are therefore more flexible and require less code. But I could be wrong, and obviously you should do what you think is best for your circumstances. Very best of luck with it. Out of interest, is there anywhere you blog about the game development, or are likely to make
Re: OO and game design questions
On Oct 20, 12:11 pm, dex josipmisko...@gmail.com wrote: On Oct 20, 12:25 pm, Jonathan Hartley tart...@tartley.com wrote: On Oct 18, 8:28 am, dex josipmisko...@gmail.com wrote: I'm building a turn based RPG game as a hobby. The design is becoming increasingly complicated and confusing, and I think I may have tendency to over-engineer simple things. Can anybody please check my problems-solutions and point me to more elegant solution? Every item/character/room is a separate object. Items/characters need to have references to room they are in, and room needs to have a list of references to items/characters that are contained within. I decided to use weak references. That way I can destroy object by deleting it, I don't have to destroy all references as well. In each object's __init__() that object is added to game_object list, and in each __del__() they are removed from game_object list. This mechanism keeps them safe from garbage collector. How pythonic is this design? In turn-based games, the order of action execution in battle can give unfair advantage to players. For example, if player's arm is crippled before his action is executed, he would do less damage. To offset this, I first execute all players' actions and calculate effects in first pass, then apply the effects in second pass. The effect can be health decrease by 15HP, item pick-up, 30p experience gain, etc. This means the player deals the same amount of damage no matter what happens to him in that turn. The difficult part is keeping track of various effects. I had to make separate class for various types of effects (ChangeAttributeEffect, GetItemEffect, LooseItemEffect). Each class stores weak reference to target object and has apply() method that applies the effect to object. I'm not satisfied with this as it's limiting, error-prone and uses metaprogramming. Is there a design pattern that would remember changes to an object, and apply them later? Sorry for the wall of text. One common way to store delayed actions is as a lambda (an anonymous function.) A lambda defines a new function: , and you can call this function later. The created function has no name, (but you can assign it to a variable to give it a name if you like) and can be called later: So in the game, you could have a collection 'effects', each one will be a lambda: effects = [] At the start of the round, as each entity makes its moves, they add lambdas to this collection. effects.append( lambda: decrease_hp(monster_a, 4) ) effects.append( lambda: lose_item(monster_a, item_b) ) Instead of appending it directly like this, I imagine the lambdas could be returned by the monster's 'act' or 'update' method: class Monster(): def act(self): # blah and finally return lambda: decrease_hp(monster_a, 4) Then for the start of a round, first you ask each monster what action it is going to perform: for monster in room.monsters: effects.append( monster.act() ) Then for the end of the round, call all the lambdas for effect in effects: effect() Mr. Roy Smith already proposed using closures. I already did a similar thing in my code, but instead of decrease_hp() I have AttributeEffect class which is able to modify any attribute (in old RPGs some monsters could drain your intelligence, in my game laser gun hit will decrease HP as well as armor integrity). The first version looks like this (missing few checks): class AttributeEffect(object): '''Effect changes object's attribute by delta''' def __init__(self, obj, attrib, delta): self.obj = obj # reference to object the effect applies to self.attrib = attrib # name of attribute that effect applies to self.delta = delta # change of value for object.attribute def apply(self): value = getattr(self.obj, self.attrib) # todo: try, except value += self.delta setattr(self.obj(), self.attrib, value) Yesterday I learned that Python 3.0 introduces nonlocal keyword which would simplify defining effect functions and passing them along. Nice improvement. Very cool, that looks like it would work. The thing I like about the lambda idea though, is that you don't have to write any classes like AttributeEffect, (and presumably other such classes, like LoseItemEffect, etc.) Instead of *modelling* the different kind of effects that could happen, you just write code that *performs* the desired effect. (e.g. monster.hp -= damage) To my eyes, lambda's are therefore more flexible and require less code. But I could be wrong, and obviously you should do what you think is best for your circumstances. Very best of luck with it. Out of interest, is there anywhere you blog about the game development, or are likely to make
Re: OO and game design questions
On Oct 18, 8:28 am, dex josipmisko...@gmail.com wrote: I'm building a turn based RPG game as a hobby. The design is becoming increasingly complicated and confusing, and I think I may have tendency to over-engineer simple things. Can anybody please check my problems-solutions and point me to more elegant solution? Every item/character/room is a separate object. Items/characters need to have references to room they are in, and room needs to have a list of references to items/characters that are contained within. I decided to use weak references. That way I can destroy object by deleting it, I don't have to destroy all references as well. In each object's __init__() that object is added to game_object list, and in each __del__() they are removed from game_object list. This mechanism keeps them safe from garbage collector. How pythonic is this design? In turn-based games, the order of action execution in battle can give unfair advantage to players. For example, if player's arm is crippled before his action is executed, he would do less damage. To offset this, I first execute all players' actions and calculate effects in first pass, then apply the effects in second pass. The effect can be health decrease by 15HP, item pick-up, 30p experience gain, etc. This means the player deals the same amount of damage no matter what happens to him in that turn. The difficult part is keeping track of various effects. I had to make separate class for various types of effects (ChangeAttributeEffect, GetItemEffect, LooseItemEffect). Each class stores weak reference to target object and has apply() method that applies the effect to object. I'm not satisfied with this as it's limiting, error-prone and uses metaprogramming. Is there a design pattern that would remember changes to an object, and apply them later? Sorry for the wall of text. One common way to store delayed actions is as a lambda (an anonymous function.) A lambda defines a new function: , and you can call this function later. The created function has no name, (but you can assign it to a variable to give it a name if you like) and can be called later: So in the game, you could have a collection 'effects', each one will be a lambda: effects = [] At the start of the round, as each entity makes its moves, they add lambdas to this collection. effects.append( lambda: decrease_hp(monster_a, 4) ) effects.append( lambda: lose_item(monster_a, item_b) ) Instead of appending it directly like this, I imagine the lambdas could be returned by the monster's 'act' or 'update' method: class Monster(): def act(self): # blah and finally return lambda: decrease_hp(monster_a, 4) Then for the start of a round, first you ask each monster what action it is going to perform: for monster in room.monsters: effects.append( monster.act() ) Then for the end of the round, call all the lambdas for effect in effects: effect() -- http://mail.python.org/mailman/listinfo/python-list
Re: OO and game design questions
On Oct 20, 11:25 am, Jonathan Hartley tart...@tartley.com wrote: On Oct 18, 8:28 am, dex josipmisko...@gmail.com wrote: I'm building a turn based RPG game as a hobby. The design is becoming increasingly complicated and confusing, and I think I may have tendency to over-engineer simple things. Can anybody please check my problems-solutions and point me to more elegant solution? Every item/character/room is a separate object. Items/characters need to have references to room they are in, and room needs to have a list of references to items/characters that are contained within. I decided to use weak references. That way I can destroy object by deleting it, I don't have to destroy all references as well. In each object's __init__() that object is added to game_object list, and in each __del__() they are removed from game_object list. This mechanism keeps them safe from garbage collector. How pythonic is this design? In turn-based games, the order of action execution in battle can give unfair advantage to players. For example, if player's arm is crippled before his action is executed, he would do less damage. To offset this, I first execute all players' actions and calculate effects in first pass, then apply the effects in second pass. The effect can be health decrease by 15HP, item pick-up, 30p experience gain, etc. This means the player deals the same amount of damage no matter what happens to him in that turn. The difficult part is keeping track of various effects. I had to make separate class for various types of effects (ChangeAttributeEffect, GetItemEffect, LooseItemEffect). Each class stores weak reference to target object and has apply() method that applies the effect to object. I'm not satisfied with this as it's limiting, error-prone and uses metaprogramming. Is there a design pattern that would remember changes to an object, and apply them later? Sorry for the wall of text. One common way to store delayed actions is as a lambda (an anonymous function.) A lambda defines a new function: , and you can call this function later. The created function has no name, (but you can assign it to a variable to give it a name if you like) and can be called later: So in the game, you could have a collection 'effects', each one will be a lambda: effects = [] At the start of the round, as each entity makes its moves, they add lambdas to this collection. effects.append( lambda: decrease_hp(monster_a, 4) ) effects.append( lambda: lose_item(monster_a, item_b) ) Instead of appending it directly like this, I imagine the lambdas could be returned by the monster's 'act' or 'update' method: class Monster(): def act(self): # blah and finally return lambda: decrease_hp(monster_a, 4) Then for the start of a round, first you ask each monster what action it is going to perform: for monster in room.monsters: effects.append( monster.act() ) Then for the end of the round, call all the lambdas for effect in effects: effect() Also, I second other people's suggestions that you almost never need to be using __del__ nor weak references in Python, unless you are writing a project that is specifically related to complex resource allocation issues. In an rpg game like this, just store references to the objects that you need (which you have to do anyway, to use them), and forget about allocation issues. Don't be afraid to post follow-up questions, (or even to mail me off list.) I make hobbyist OpenGL games in Python myself, and although I'm no expert, I'd love to chat more about this for our mutual benefit. -- http://mail.python.org/mailman/listinfo/python-list
Re: Hide DOS console for .pyc file
On Sep 11, 11:32 am, Lawrence D'Oliveiro l...@geek- central.gen.new_zealand wrote: In message i6fivp$76v$0...@news.t-online.com, Peter Otten wrote: Lawrence D'Oliveiro wrote: In message 3a2d194c-9b34-4b84-8680-28bdfb53b...@y3g2000vbm.googlegroups.com, Muddy Coder wrote: For a quick testing purpose, I deliver .pyc files to my customer. I don't want the black DOS console appearing behind my GUI, but I have no idea how to do it. Somebody can help? Thanks! Don’t run it on Windows. If you switch the OS for every minor problem you'll run out of operating systems pretty soon... Not if you choose a suitably flexible and portable one to begin with. It isn't the OP choosing, it's his client. Now, I dislike aspects of Windows as much as anybody, but even I can see that dictating which OS your client is allowed to use if they want to run your program is sometimes not a viable option. -- http://mail.python.org/mailman/listinfo/python-list
Re: Printing the name of a variable
On Sep 9, 9:11 pm, Albert Hopkins mar...@letterboxes.org wrote: On Thu, 2010-09-09 at 12:43 -0700, Stephen Boulet wrote: Does an arbitrary variable carry an attribute describing the text in its name? I'm looking for something along the lines of: x = 10 print x.name 'x' Perhaps the x.__getattribute__ method? Thanks. Variables are not objects and so they have no attributes. You can't really de-reference the object being referenced as it can potentially contain multiple references, but an innacurate way of doing this would be, e.g. x = [1, 2, 3] y = x g = globals() varnames = [i for i in g if g[i] is x] ['x', 'y'] But this cries the question: why do you want to do this? And usually that question is asked when someone thinks that a: you shouldn't need to do this and b: whatever the desired effect there is probably a better way of accomplishing it. I have in the past wondered about creating a kind of graphical debugger, that rendered representations of all the objects in globals and/or locals, to give you a visual representation of your variables and their states. Would this be a valid use case to try and look up the variable names which reference various in-memory objects? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is there no platform independent way of clearing a terminal?
On Jul 28, 8:08 am, Ulrich Eckhardt eckha...@satorlaser.com wrote: Daniel Fetchinson wrote: After getting the technicalities out of the way, maybe I should have asked: Is it only me or others would find a platform independent python API to clear the terminal useful? There are two kinds of programs: 1. Those that process input to output. If one of those suddenly started by clearing my screen, I'd just dump it. Also, if output is redirected to a file or piped into another program, that is basically useless or even hurting, since you then end up with control sequences in the file. 2. Those that provide a text-based interactive UI. Those typically not only clear the screen, but also control its whole layout and content, so there you don't only need ways to clear the screen but also to position the cursor or draw boxes etc. In that case you need a full curses library. Summary: No, I don't see the need for such an API. Cheers! Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 I don't know much, but just in case the following is useful to anyone: There is a Windows program called 'ansicon', which when installed (run with '-i'), will modify all future Windows cmd shells to correctly intercept and interpret ANSI escape codes for colors, cursor movement, and: \e[#J ED: Erase Display which I presume is what is under discussion here. I understand there are other historical ANSI drivers which were responsible for achieving a similar thing under Windows, but this is the method I currently use (on XP) and am very happy with. Also, and probably less usefully, personally I do wish Python provided a cross platform mechanism for simple terminal control like clearing and colored text. Since ANSI codes are used everywhere except Windows, it would make sense to base such a system on them. So I started a pure Python implementation of a crude ANSI driver, on PyPI as 'colorama'. It does nothing on non-windows systems, but on Windows it patches sys.stdout with a stream-like object, in order to filter out ANSI codes and convert them into Win32 terminal control calls. It currently only works with colors and brightness, but I would love to extend it to cover other ANSI codes such as 'clear screen'. It is doubtless riddled with errors and misunderstandings, and I would love any feedback helping me do a better job. Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is there no platform independent way of clearing a terminal?
On Jul 28, 8:08 am, Ulrich Eckhardt eckha...@satorlaser.com wrote: Daniel Fetchinson wrote: After getting the technicalities out of the way, maybe I should have asked: Is it only me or others would find a platform independent python API to clear the terminal useful? There are two kinds of programs: 1. Those that process input to output. If one of those suddenly started by clearing my screen, I'd just dump it. Also, if output is redirected to a file or piped into another program, that is basically useless or even hurting, since you then end up with control sequences in the file. 2. Those that provide a text-based interactive UI. Those typically not only clear the screen, but also control its whole layout and content, so there you don't only need ways to clear the screen but also to position the cursor or draw boxes etc. In that case you need a full curses library. Summary: No, I don't see the need for such an API. Cheers! Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 Hey, Your point seems good and I don't mean to contradict, but out of interest, what do you think about an example like the following: I want to write a quick script which, notices whenever I save my source code, and re-runs the unit tests, displaying the output. I think I'd like it to clear the terminal before each re-run of the tests, so that it's immediately obvious what is output from the current run, as opposed to previous runs. Then I can keep my editor focussed, but leave that running in a terminal and trust it to simply display the current output from my tests. I did dash off a quick and dirty version of this once which did a system 'clear' or 'cls' depending on the platform, but to my dismay I found that on Windows this caused focus to jump briefly to the terminal every time it ran 'clear' (!), making it extremely annoying in use. So I wished there had been a simple cross-platform way to clear the terminal. (this, and printing colored text, was my initial use case for starting 'colorama') Is this a silly desire of mine, or simply an uncommon edge case that therefore isn't really significant? Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is there no platform independent way of clearing a terminal?
On Jul 28, 4:45 pm, Jonathan Hartley tart...@tartley.com wrote: On Jul 28, 8:08 am, Ulrich Eckhardt eckha...@satorlaser.com wrote: Daniel Fetchinson wrote: After getting the technicalities out of the way, maybe I should have asked: Is it only me or others would find a platform independent python API to clear the terminal useful? There are two kinds of programs: 1. Those that process input to output. If one of those suddenly started by clearing my screen, I'd just dump it. Also, if output is redirected to a file or piped into another program, that is basically useless or even hurting, since you then end up with control sequences in the file. 2. Those that provide a text-based interactive UI. Those typically not only clear the screen, but also control its whole layout and content, so there you don't only need ways to clear the screen but also to position the cursor or draw boxes etc. In that case you need a full curses library. Summary: No, I don't see the need for such an API. Cheers! Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 Hey, Your point seems good and I don't mean to contradict, but out of interest, what do you think about an example like the following: I want to write a quick script which, notices whenever I save my source code, and re-runs the unit tests, displaying the output. I think I'd like it to clear the terminal before each re-run of the tests, so that it's immediately obvious what is output from the current run, as opposed to previous runs. Then I can keep my editor focussed, but leave that running in a terminal and trust it to simply display the current output from my tests. I did dash off a quick and dirty version of this once which did a system 'clear' or 'cls' depending on the platform, but to my dismay I found that on Windows this caused focus to jump briefly to the terminal every time it ran 'clear' (!), making it extremely annoying in use. So I wished there had been a simple cross-platform way to clear the terminal. (this, and printing colored text, was my initial use case for starting 'colorama') Is this a silly desire of mine, or simply an uncommon edge case that therefore isn't really significant? Best regards, Jonathan Oh, plus, while we're on this subject: Am I right that curses in Python stdlib doesn't work on Windows, and there is currently no simple way to fix this? Also, is it crazy to imagine that if colorama was pushed through to completion (ie. to support a majority of the relevant ANSI codes) then Python's stdlib curses module, unmodified, would suddenly just work on Windows? (after a call to 'colorama.init()') I presume these ideas are oversimplifications or just plain wrong. If anyone would care to correct my misunderstandings, I'd be very grateful. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why is there no platform independent way of clearing a terminal?
On Jul 28, 5:47 pm, Thomas Jollans tho...@jollans.com wrote: On 07/28/2010 06:01 PM, Jonathan Hartley wrote: Oh, plus, while we're on this subject: Am I right that curses in Python stdlib doesn't work on Windows, and there is currently no simple way to fix this? Also, is it crazy to imagine that if colorama was pushed through to completion (ie. to support a majority of the relevant ANSI codes) then Python's stdlib curses module, unmodified, would suddenly just work on Windows? (after a call to 'colorama.init()') I presume these ideas are oversimplifications or just plain wrong. If anyone would care to correct my misunderstandings, I'd be very grateful. Correct: it's not THAT simple. Python's curses module is a (I'm not sure how thin) wrapper around the good old UNIX curses (ncurses, ...) library. This is written in C, not Python, so it doesn't use Python's sys.stdout object to do I/O. I haven't had a look at colorama, but it sounds like it hooks into sys.stdout, or Python file objects anyway. Far, far above the layer curses does I/O on. So, if you ported a normal curses library to Windows, colorama wouldn't help you a bit. It might be possible to write a curses-compatible library that works with cmd.exe. Maybe. But, even if it's possible, I don't think it's easy, and I especially don't think it would be particularly rewarding. Also, I just stumbled uponhttp://adamv.com/dev/python/curses/-- this is probably the only reasonable way to get a useful curses API on Windows: forget the DOS box. ncurses ... is written in C, not Python, so it doesn't use Python's sys.stdout object to do I/O. Ah, I should have spotted that. Of course. Thanks for the enlightenment. And Neil Cerutti, I think I'll just email the whole source tree to myself, and have a script that scans my inbox, unzips source trees and runs their tests. Much nicer. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Jul 6, 4:50 pm, sturlamolden sturlamol...@yahoo.no wrote: Just a little reminder: Microsoft has withdrawn VS2008 in favor of VS2010. The express version is also unavailable for download. :(( We can still get a VC++ 2008 compiler required to build extensions for the official Python 2.6 and 2.7 binary installers here (Windows 7 SDK for .NET 3.5 SP1): http://www.microsoft.com/downloads/details.aspx?familyid=71DEB800-C59... Download today, before it goes away! Microsoft has now published a download for Windows 7 SDK for .NET 4. It has the VC++ 2010 compiler. It can be a matter of days before the VC ++ 2008 compiler is totally unavailable. I presume this problem would go away if future versions of Python itself were compiled on Windows with something like MinGW gcc. Also, this would solve the pain of Python developers attempting to redistribute py2exe versions of their programs (i.e. they have to own a Visual Studio license to legally be able to redistribute the required C runtime) I don't understand enough to know why Visual Studio was chosen instead of MinGW. Can anyone shed any light on that decision? Many thanks Jonathan Hartley -- http://mail.python.org/mailman/listinfo/python-list
Re: Download Microsoft C/C++ compiler for use with Python 2.6/2.7 ASAP
On Jul 7, 8:22 pm, Martin v. Loewis mar...@v.loewis.de wrote: I presume this problem would go away if future versions of Python itself were compiled on Windows with something like MinGW gcc. Also, this would solve the pain of Python developers attempting to redistribute py2exe versions of their programs (i.e. they have to own a Visual Studio license to legally be able to redistribute the required C runtime) I don't understand enough to know why Visual Studio was chosen instead of MinGW. Can anyone shed any light on that decision? sturlamolden has already given the primary reason: Python, traditionally, attempts to use and work with the system vendor's compiler. On Windows, that's MSC. It's typically the one that best knows about platform details that other compilers might be unaware of. In addition, it's also the compiler and IDE that Windows developers (not just Python core people, but also extension developers and embedders) prefer to use, as it has quite good IDE support (in particular debugging and code browsing). Perhaps more importantly, none of the other compilers is really an alternative. GCC in particular cannot build the Win32 extensions, since it doesn't support the COM and ATL C++ features that they rely on (and may not support other MSC extensions, either). So the Win32 extensions must be built with VS, which means Python itself needs to use the same compiler. Likewise important: gcc/mingw is *not* a complete C compiler on Windows. A complete C compiler would have to include a CRT (on Windows); mingw doesn't (cygwin does, but I think you weren't proposing that Python be built for cygwin - you can easily get cygwin Python anyway). Instead, mingw relies on users having a CRT available to them - and this will be a Microsoft one. So even if gcc was used, we would have versioning issues with Microsoft CRTs, plus we would have to rely on target systems including the right CRT, as we couldn't include it in the distribution. HTH, Martin I see. Thanks very much to both of you for the info, much appreciated. -- http://mail.python.org/mailman/listinfo/python-list
Re: if, continuation and indentation
On May 27, 1:57 pm, Jean-Michel Pichavant jeanmic...@sequans.com wrote: HH wrote: I have a question about best practices when it comes to line wrapping/ continuation and indentation, specifically in the case of an if statement. When I write an if statement with many conditions, I prefer to use a parenthesis around the whole block and get the implicit continuation, rather than ending each line with an escape character. Thus, using the example from the style guide (http://www.python.org/dev/peps/ pep-0008/) I would write: if (width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or highlight 100): raise ValueError(sorry, you lose) The problem should be obvious -- it's not easy to see where the conditional ends and the statement begins since they have the same indentation. Part of the problem, I suppose, is that Emacs indents 'height' and the other lines in the conditional to 4 spaces (because of the parenthesis). How do people deal with this situation? Thanks, Henrik One possible solution if ( width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or highlight 100 ): raise ValueError(sorry, you lose) JM I've always liked this, or even: if ( width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or highlight 100 ): raise ValueError(sorry, you lose) but my co-workers have uniformly gone bananas whenever I try it. -- http://mail.python.org/mailman/listinfo/python-list
Re: if, continuation and indentation
On 28/05/2010 11:34, Jean-Michel Pichavant wrote: Jonathan Hartley wrote: On May 27, 1:57 pm, Jean-Michel Pichavant jeanmic...@sequans.com wrote: HH wrote: I have a question about best practices when it comes to line wrapping/ continuation and indentation, specifically in the case of an if statement. When I write an if statement with many conditions, I prefer to use a parenthesis around the whole block and get the implicit continuation, rather than ending each line with an escape character. Thus, using the example from the style guide (http://www.python.org/dev/peps/ pep-0008/) I would write: if (width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or highlight 100): raise ValueError(sorry, you lose) The problem should be obvious -- it's not easy to see where the conditional ends and the statement begins since they have the same indentation. Part of the problem, I suppose, is that Emacs indents 'height' and the other lines in the conditional to 4 spaces (because of the parenthesis). How do people deal with this situation? Thanks, Henrik One possible solution if ( width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or highlight 100 ): raise ValueError(sorry, you lose) JM I've always liked this, or even: if ( width == 0 and height == 0 and color == 'red' and emphasis == 'strong' or highlight 100 ): raise ValueError(sorry, you lose) but my co-workers have uniformly gone bananas whenever I try it. I tried to give a layout that fits the OP way of doing, but I would not use what I described above, so I can understand why your co workers go bananas :) when it comes to extended conditions in if statement I prefer to write something like if self.haveLost(): raise ValueError(sorry, you lose) It drastically improves the reading Good point. +1 for naming the condition, hooray for self-documenting code. Sometime last year at my workplace, we started referring to comments as 'lies', we now always try to use techniques like this instead of comments. -- Jonathan Hartley Made of meat. http://tartley.com tart...@tartley.com +44 7737 062 225 twitter/skype: tartley -- http://mail.python.org/mailman/listinfo/python-list
Re: cross-platform coloured text in terminal
On Apr 17, 11:52 am, Jonathan Hartley tart...@tartley.com wrote:
On Apr 16, 5:59 pm, Lie Ryan lie.1...@gmail.com wrote:
On 04/16/10 19:28, Jonathan Hartley wrote:
I'm playing with ideas of what API to expose. My favourite one is to
simply embed ANSI codes in the stream to be printed. Then this will
work as-is on Mac and *nix. To make it work on Windows, printing could
be done to a file0-like object which wraps stdout:
The problem with that is you're simply reinventing ANSI.SYS device driver.
An alternative API is you could override .__add__(), like so (completely
untested):
classColor(object):
def __init__(self,color):
self.color= map_the_color(color)
self.string =
def __add__(self, string):
self.string += string
return self
def __str__(self):
if terminal_can_do_ansi_color:
return ansicolorescape(self.string, self.color)
elif windows:
syscalltocolor(self.color)
print self.string
syscalltocolor(reset thecolor)
return
GREEN =Color('green')
print GREEN + Great + Good
you can even go a bit further and allow chained calls (again, completely
untested, but you get the idea):
classColor(object):
def __init__(self,color):
self.color= map_the_color(color)
self.stack = []
def __add__(self, string):
if isinstance(string,Color):
# not a string, chain the calls
self.stack.append((string.color, []]))
else:
# a string,
self.stack[-1][1].append(string)
return self
def __radd__(self, string):
self.stack.append([self.default, string])
return self
def __str__(self):
if ansi_capable:
return colorescape(format, string)
elif windows:
for format, string in self.stack:
syscalltocolor(color)
print string
return
GREEN =Color('green')
RED =Color('red')
print Fairly + GREEN + Great + RED + Poor
or something like that, and you will have an API that works
transparently on all platforms. The downside is that you cannot call
str(GREEN + foo) on windows.
Hey Lie,
Thanks heaps for the reply!
The problem with that is you're simply reinventing ANSI.SYS device driver.
I don't see that as a problem - in fact I think it's exactly my
goal! :-)
The difference is that the ANSI driver requires installation and a
reboot on the end-user's computer, which is a fiddly and intrusive
thing for a Python developer to achieve. Whereas doing the same job in
a Python module is easy to use for the Python developer - they just
import the module, maybe call an 'init()' function, and then the ANSI
functionality works on all platforms.
Your ideas about generating and chaining the ANSI code strings are
great. I worry though, about intermingling the code that generates
ANSI escape sequences with the code which makes them work on Windows.
The problem is that then, only applications which use your ANSI-
generation library will work on Windows. Whereas if these two things
are kept separate, then applications which use any other ANSI-
generation techniques, such as using 'termcolor', or manaully printing
raw ANSI sequences, these can also all work on Windows too, simply by
adding an import and an 'init()' call to the start of the application.
Am I making sense? Many thanks for your thoughts.
Jonathan
I have implemented these ideas here. It seems to work.
http://pypi.python.org/pypi/colorama
--
http://mail.python.org/mailman/listinfo/python-list
Re: cross-platform coloured text in terminal
On Apr 16, 5:59 pm, Lie Ryan lie.1...@gmail.com wrote:
On 04/16/10 19:28, Jonathan Hartley wrote:
I'm playing with ideas of what API to expose. My favourite one is to
simply embed ANSI codes in the stream to be printed. Then this will
work as-is on Mac and *nix. To make it work on Windows, printing could
be done to a file0-like object which wraps stdout:
The problem with that is you're simply reinventing ANSI.SYS device driver.
An alternative API is you could override .__add__(), like so (completely
untested):
class Color(object):
def __init__(self, color):
self.color = map_the_color(color)
self.string =
def __add__(self, string):
self.string += string
return self
def __str__(self):
if terminal_can_do_ansi_color:
return ansicolorescape(self.string, self.color)
elif windows:
syscalltocolor(self.color)
print self.string
syscalltocolor(reset the color)
return
GREEN = Color('green')
print GREEN + Great + Good
you can even go a bit further and allow chained calls (again, completely
untested, but you get the idea):
class Color(object):
def __init__(self, color):
self.color = map_the_color(color)
self.stack = []
def __add__(self, string):
if isinstance(string, Color):
# not a string, chain the calls
self.stack.append((string.color, []]))
else:
# a string,
self.stack[-1][1].append(string)
return self
def __radd__(self, string):
self.stack.append([self.default, string])
return self
def __str__(self):
if ansi_capable:
return colorescape(format, string)
elif windows:
for format, string in self.stack:
syscalltocolor(color)
print string
return
GREEN = Color('green')
RED = Color('red')
print Fairly + GREEN + Great + RED + Poor
or something like that, and you will have an API that works
transparently on all platforms. The downside is that you cannot call
str(GREEN + foo) on windows.
Hey Lie,
Thanks heaps for the reply!
The problem with that is you're simply reinventing ANSI.SYS device driver.
I don't see that as a problem - in fact I think it's exactly my
goal! :-)
The difference is that the ANSI driver requires installation and a
reboot on the end-user's computer, which is a fiddly and intrusive
thing for a Python developer to achieve. Whereas doing the same job in
a Python module is easy to use for the Python developer - they just
import the module, maybe call an 'init()' function, and then the ANSI
functionality works on all platforms.
Your ideas about generating and chaining the ANSI code strings are
great. I worry though, about intermingling the code that generates
ANSI escape sequences with the code which makes them work on Windows.
The problem is that then, only applications which use your ANSI-
generation library will work on Windows. Whereas if these two things
are kept separate, then applications which use any other ANSI-
generation techniques, such as using 'termcolor', or manaully printing
raw ANSI sequences, these can also all work on Windows too, simply by
adding an import and an 'init()' call to the start of the application.
Am I making sense? Many thanks for your thoughts.
Jonathan
--
http://mail.python.org/mailman/listinfo/python-list
cross-platform coloured text in terminal
Hi, It irks me that I know of no simple cross-platform way to print colored terminal text from Python. As I understand it, printing ANSI escape codes (as wrapped nicely by module termcolor and others) works on Macs and *nix, but only works on Windows if one has installed the ANSI.SYS device driver, which most users have not. However, on Windows, there is an alternative method, which is to make win32 calls via ctypes. I'd like to try and unite these different implementations under a single cross-platform API. Has this been done already? I understand that the detailed capabilities of the two implementations (eg. dim/ bright colors) might not map neatly, but at least for simple colored text, it should be OK. I'm playing with ideas of what API to expose. My favourite one is to simply embed ANSI codes in the stream to be printed. Then this will work as-is on Mac and *nix. To make it work on Windows, printing could be done to a file0-like object which wraps stdout: class ColorStream(object): def __init__(self, wrapped): self.wrapped = wrapped def write(self, text): # magic goes here self.wrapped.write(text) def __getattr__(self, name): return getattr(self.wrapped, name) term = ColorTerm(sys.stdout) print term, ANSI.GREEN + hello The idea being that in place of 'magic goes here', there will be code that, on Windows, searches 'text' for ANSI escape codes, strips them from the text, and converts them into the appropriate win32 calls. For extra nasty magic, either the module or the user of the module could wrap sys.stdout globally: sys.stdout = ColoredStream(sys.stdout) Then print statements in the user's code would simply be: print ANSI.GREEN + hello and this would work on all platforms. No doubt there are many problems with these ideas. I would love to hear about them. Many thanks. -- http://mail.python.org/mailman/listinfo/python-list
Re: cross-platform coloured text in terminal
On Apr 16, 10:28 am, Jonathan Hartley tart...@tartley.com wrote: Hi, It irks me that I know of no simple cross-platform way to print colored terminal text from Python. As I understand it, printing ANSI escape codes (as wrapped nicely by module termcolor and others) works on Macs and *nix, but only works on Windows if one has installed the ANSI.SYS device driver, which most users have not. However, on Windows, there is an alternative method, which is to make win32 calls via ctypes. I'd like to try and unite these different implementations under a single cross-platform API. Has this been done already? I understand that the detailed capabilities of the two implementations (eg. dim/ bright colors) might not map neatly, but at least for simple colored text, it should be OK. I'm playing with ideas of what API to expose. My favourite one is to simply embed ANSI codes in the stream to be printed. Then this will work as-is on Mac and *nix. To make it work on Windows, printing could be done to a file0-like object which wraps stdout: class ColorStream(object): def __init__(self, wrapped): self.wrapped = wrapped def write(self, text): # magic goes here self.wrapped.write(text) def __getattr__(self, name): return getattr(self.wrapped, name) term = ColorTerm(sys.stdout) print term, ANSI.GREEN + hello The idea being that in place of 'magic goes here', there will be code that, on Windows, searches 'text' for ANSI escape codes, strips them from the text, and converts them into the appropriate win32 calls. For extra nasty magic, either the module or the user of the module could wrap sys.stdout globally: sys.stdout = ColoredStream(sys.stdout) Then print statements in the user's code would simply be: print ANSI.GREEN + hello and this would work on all platforms. No doubt there are many problems with these ideas. I would love to hear about them. Many thanks. Sorry, I forgot to mention: The reason I like this idea is that, in theory, all existing libraries like termcolor will then work, unmodified, on all platforms. -- http://mail.python.org/mailman/listinfo/python-list
Re: missing dll follow-up
Alex Hall wrote: The vcredist_x86 was, I thought, supposed to give me the dll, but it does not seem to have done so. The installer puts the DLL in the directory C:\WINDOWS\WinSxS (or at least it does for me, on WinXP) I shall update the py2exe tutorial page to reflect this. Under that dir, there are a lot of mangled directory names, and a director called 'Manifests'. You can still discern the text 'Microsoft.VC90.CRT' and '9.0.21022.8' within the filenames of the DLL dir and the manifest file that you want. I am no expert, but I think if you are taking a copy of these to embed in your application, then you can (must?) rename them to remove the mangling, as described on the py2exe tutorial page. If you still cannot find the DLL there, then try searching your Program Files folder for a copy included with another application. Several other Visual C/C++ applications include these runtime DLLs. (eg. Console2 from sourceforge) One other thing to keep in mind is that there is more than one version of this DLL in the wild, all with the same filename. You absolutely need the same version that Python 2.6 was compiled with, which is 9.0.21022.8. You can tell which version of the DLL you have got the tooltip when hovering you mouse cursor over it. (also hovering over the redistributable installer will tell you the same thing) The original version of the redistributable installer does provide the correct DLL version (this is the same thing as linked to above. This is the English version): http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bfdisplaylang=en The SP1 version of the same installer provides a different version of the DLL (but with the same filename). This will not work. -- http://mail.python.org/mailman/listinfo/python-list
Re: missing dll follow-up
On Apr 15, 12:11 pm, Jonathan Hartley tart...@tartley.com wrote: Alex Hall wrote: The vcredist_x86 was, I thought, supposed to give me the dll, but it does not seem to have done so. The installer puts the DLL in the directory C:\WINDOWS\WinSxS (or at least it does for me, on WinXP) I shall update the py2exe tutorial page to reflect this. Under that dir, there are a lot of mangled directory names, and a director called 'Manifests'. You can still discern the text 'Microsoft.VC90.CRT' and '9.0.21022.8' within the filenames of the DLL dir and the manifest file that you want. I am no expert, but I think if you are taking a copy of these to embed in your application, then you can (must?) rename them to remove the mangling, as described on the py2exe tutorial page. If you still cannot find the DLL there, then try searching your Program Files folder for a copy included with another application. Several other Visual C/C++ applications include these runtime DLLs. (eg. Console2 from sourceforge) One other thing to keep in mind is that there is more than one version of this DLL in the wild, all with the same filename. You absolutely need the same version that Python 2.6 was compiled with, which is 9.0.21022.8. You can tell which version of the DLL you have got the tooltip when hovering you mouse cursor over it. (also hovering over the redistributable installer will tell you the same thing) The original version of the redistributable installer does provide the correct DLL version (this is the same thing as linked to above. This is the English version):http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e0... The SP1 version of the same installer provides a different version of the DLL (but with the same filename). This will not work. Oh, and, this is probably obvious and well-known, sorry if I'm teaching grandmother to suck eggs here, but if you have rights to distribute this DLL with your application, I understand this means that you own a copy of Visual Studio, and a copy of the DLL and manifest file can be found in the installed Visual Studio 'redist' directory. If you don't have such a DLL in that directory (eg. if you have the express edition) then you don't have legal right to distribution it. Just so you know. -- http://mail.python.org/mailman/listinfo/python-list
Re: missing dll follow-up
On Apr 15, 12:11 pm, Jonathan Hartley tart...@tartley.com wrote: The installer puts the DLL in the directory C:\WINDOWS\WinSxS (or at least it does for me, on WinXP) I shall update the py2exe tutorial page to reflect this. Done. Final para of section 5.2.2 now reads: The installer puts a copy of the DLLs in the directory C:\WINDOWS \WinSxS (XP), inside subdirectories with mangled names. The manifest file is in the 'Manifests' subdirectory, again this will have a mangled filename. You can still discern the text 'Microsoft.VC90.CRT' and '9.0.21022.8' within the mangled file and directory names, to find the files. It is possible to take a copy of these files and remove the filename mangling, to embed them in your application as described in 5.2.1. Where section 5.2.1 begins, as it always has: If you do have the rights to redistribute MSVCR90.dll, there should be a copy of it in your Visual Studio install, under VC\redist \x86\Microsoft.VC90.CRT... http://www.py2exe.org/index.cgi/Tutorial#Step522 -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating a standalone application
On Apr 13, 10:42 pm, Lawrence D'Oliveiro l...@geek- central.gen.new_zealand wrote: In message kz4xn.868$i8@news.indigo.ie, Luis Quesada wrote: I am getting an expected string without null bytes error when using cxfreeze for creating a standalone application (in Linux-Ubuntu). Why bother? Every decent Linux system will have Python available. Why not just distribute it as a script? I keep hearing this reply every time I ask this question, and it doesn't seem to make sense to me. Anything other than a trivial script will have dependencies. These might be other Python packages, C-extensions, and other libraries. What if your program runs on a version of Python other than the one installed on the client's Linux system? In my opinion, there is a severe need for this question to be answered in a robust and simple way. Is creating an rpm / deb file the answer? I don't know, but I think it's a very valid question. -- http://mail.python.org/mailman/listinfo/python-list
Re: Classes as namespaces?
On Mar 26, 6:26 pm, Luis M. González luis...@gmail.com wrote: On 26 mar, 11:49, kj no.em...@please.post wrote: What's the word on using classes as namespaces? E.g. class _cfg(object): spam = 1 jambon = 3 huevos = 2 breakfast = (_cfg.spam, _cfg.jambon, _cfg.huevos) I see no problem. I wouldn't mix English, French and Spanish in the same recipe though... Hey everyone. By coincidence, only yesterday I was wondering about using classes as a way of labeling a block of code, ie. an lightweight alternative to defining a function that would only be called from one location. eg. instead of: x = 1 ((some complex logic)) y = 2 one might like to name the complex block of logic, just to make it readable: x = 1 def account_for_non_square_pixels(x): ((some complex logic)) account_for_non_square_pixels() y = 2 But defining and then calling the function like that is a tad cumbersome. So I was wondering about: x = 1 class account_for_non_square_pixels: ((some complex logic)) y = 2 I don't exactly like this, but I think you can see what I'm getting at. Does this fall down in some way I haven't grasped? Is it as awful an abuse of 'class' as my intuition suggests it is? Is there a way to do it better? -- http://mail.python.org/mailman/listinfo/python-list
Re: python to exe
On Mar 13, 1:45 pm, pyt...@bdurham.com wrote: Robin, do you of an alternate compilter it doesn't work (py2exe) on my windows 7 box I can assure you that Py2exe does work on Windows 7 (my firm develops commercial Python applications packaged using Py2exe running on Windows 7), but it does take a bit of fiddling and some patience. Join the py2exe newsgroup and post your problems there.https://lists.sourceforge.net/lists/listinfo/py2exe-users You may also want to google 'Gui2exe'. This is a free front-end to Py2exe that you can use to generate your Py2exe setup.py scripts. Note that Gui2exe requires wxPython (free) to run. Finally, make sure you are trying to compile 32-bit Python 2.x code. I don't think py2exe supports Python 3.x or 64-bit versions of Python yet. Nope; py2exe is pretty much the go-to tool for this. I hear great things about PyInstaller. The project is not dead - make sure you use the latest version in the SVN. Search stackoverflow.com for positive feedback and tips on PyInstaller. Its on our plate to take a good look this product 'one of these days'. Good luck! Malcolm I summarised a all the alternatives to py2exe I could find, here: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput=html Looking for those with a green 'y' in the 'Windows' row, you want to check out cx_freeze, PyInstaller, bbfreeze. Best of luck. -- http://mail.python.org/mailman/listinfo/python-list
Re: py2exe deal with python command line inside a program
On Jan 22, 7:35 pm, susan_kij...@yahoo.ca wrote: Hi, I need to create a python subprogress, like this: myProcess = subprocess.Popen([sys.executable, 'C:\myscript.py'], env=env, stdin=subprocess.PIPE, stdout=subprocess.PIPE) sys.executable was printed out as ''C:\\Python25\\python.exe'', how can I make this work in executable package through py2exe? I have to fix the following problems: -Source code shouldn't exposed in an executable program -Since python environment is not required when running an executable program, how to deal with the situation that C:\\Python25\ \python.exe is required as part of command? Thanks in advance! Hi. What does it do when you try to execute it with py2exe? Does it fail to run? What is the error? -- http://mail.python.org/mailman/listinfo/python-list
Re: Is python not good enough?
On Jan 13, 9:06 am, ta...@mongo.net (tanix) wrote: Well, as soon as they restore the braces to identify the code blocks and provide the functionality of advanced statically type languages, such as threads, async processing, all synchronization primitives, garbage collection, events and GUI, i'd be willing to switch to Python. Some of it is already there. But not all. Except, before doing it, I'd like to know what Python buys me compared to say Java. Hey tanis. The absence of braces from Python is a thoughtful, deliberate choice. There are good reasons for it, and many people (especially people round these parts) think Python is better without braces. If you don't like it then fair enough, your preferences are your own to choose. Other than that, Python does have every single one of the things you enumerate. Regarding static versus dynamic typing - many people (especially people round these parts) believe dynamic typing to be superior to static typing in many situations. Again, personal taste seems to weigh heavily in this topic, but there are strong reasons to prefer dynamic typing - it allows you to write some programs that simply couldn't be written statically, and this greater flexibility sometimes allows you to choose algorithms and code organisation that is a better match for your problem than a statically typed language would, making your programs easier to write, shorter, and simpler to read. As for a direct comparison with Java, then perhaps the most prominent differences are that Python generally produces shorter, simpler- looking programs, which are easier to write and read. Dynamic typing is an advantage of Python in most situations. On the other hand, Python often has poorer performance than Java. My personal hypothesis is that this performance mismatch is most pronounced in small, benchmark-like data churning inner-loops, and becomes less significant for most real-world programs that have high complexity, since Python's power-through-simplicity allows developers to visualise better algorithms and refactor more easily than would otherwise be the case. Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
the method involves editing python26.dll in order to remove dependency references and then dropping msvcr90.dll in the same directory as the py2exe produced executable. Clever idea Waldemar, thanks for that, but for the moment, using the dll as a win32 assembly (ie. with a manifest file, as described by others earlier in this thread) seems to work just as well. You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll. So, for the record, I have included these two files in a directory called 'Microsoft.VC90.CRT', which is in the same dir as my executable, and that makes everything work, even on my 'bare bones' windows XP virtual machine. The end result is a small game some friends and I put together for the PyWeek competition a few months ago. If anyone wants to see exactly how the resulting dll and manifest look, you can download the Windows binary under the 'featured downloads' from here: http://code.google.com/p/brokenspell/ I appreciate David Bolen's comment that an installer isn't that hard to put together: Acknowledged, but for the moment I still seem to be getting away without needing one. Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: Any way to use cProfile in a multi-threaded program?
On Dec 30, 3:00 pm, mk mrk...@gmail.com wrote: I'm stumped; I read somewhere that one would have to modify Thread.run() method but I have never modified Python methods nor would I really want to do it. Is there any way to start cProfile on each thread and then combine the stats? Regards, mk Well, you can start cProfile from any arbitrary point within your program, using the code: import cProfile import .mymodule command = 'mymodule.myfunction()' cProfile.runctx(command, globals(), locals(), filename='profile.out') Conventionally this is run at the start of your program (and myfunction () is something that you call to startup the remainder of your program), but one solution for you might be to run this after the threads have been created. You'll have to run this in each thread, and myfunction() will be the function required for the thread to do its work. Maybe each thread should output to a different filename, using something like filename='profile%s' % (threading.current_thread ().ident,) As for combining the outputs from each thread, I don't know what the cProfile output format is, so I can't help you there. There might be better ways, but I don't know them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On 27/12/2009 05:18, Stephen Hansen wrote: Jonathan Hartley tart...@tartley.com mailto:tart...@tartley.com writes: These are non-technical users, so I'd rather send them a single executable that 'just works', [break] rather than asking them to install Python and then coach them through running a script - they would HATE that as a solution. Whoa... How can you go from single executable that 'just works' to asking them to install Python and then coach them -- there's /miles/ of difference between the two of those options and countless places for you to sit between them. This isn't an issue which is unique to Python, or which has anything to do with Python at all-- or that Python has any power to do anything about. This is the platform and ecosystem that Microsoft has made for you, and they alone have any power to change anything in this arena. This is their code, not Python's, and they define the rules by which you can use it. One way to get those files is to just install python, yes. As Python was compiled with a legally licensed version of Visual C++ (though gratis from Microsoft, I believe), they have the rights to redistribute those files. Here though, /you/ are creating a new work-- and even though it includes Python its not a derivative of Python-- and distributing it. The question is, do /you/ have the right to distribute those files? That Python did originally, and you're using Python, does not automatically mean that yes you do-- lawyer-logic does not necessarily equate to layman-logic. I have no idea what the answer to that question is, actually; IANAL and I have never needed to make a stand-alone windows exe out of python where it wasn't a simple matter to include a link to Microsoft's website where anyone is free to download and install those redistributable components. This came up a few years ago if memory serves, and I don't remember anyone having a conclusive answer to it, and people argued a bit over Microsoft's EULA granting redistribution rights. I don't remember any actual lawyers chiming in, so I think the question was never solved: and that means in the end you should assume you do not have the right, as the assumption in the other direction is sorta bad. Yes, in an ideal world people wouldn't need to run anything but your .exe. But the reality is, they probably will need to install the redistributable -- but come on.. The VC2008 (which is VC++ 9.0, which is what Python was compiled with) package is only 1.7 megs. Its not *that* big of a deal to say hey, if it doesn't work install this. There's nothing else you (or anyone else) can do about it. Until Microsoft open-sources Visual Studio :) --S Thanks Steve, there's clearly much sense is what you say. I recognise that this isn't unique to Python, nor the result of anything Python has any control over. However, I keep imagining slash hoping that we might have *engineered* our way around the situation. :-) For example, I clearly don't know what I'm talking about, but might it be possible to bundle the VC redistributable installer with your exectutable, such that if the required DLL's are not already on the user's system, then we run the installer to create them. The logic to do this could be in a PyPI package, or else built into py2exe and similar. Then the application developer would only need to add a single option to py2exe in order for this whole issue to pretty much go away? Or am I misunderstanding? -- http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On Dec 27, 1:51 pm, pyt...@bdurham.com wrote:
Hi Martin,
You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll.
Thank you for your answers. From my research and testing on this topic:
1. Can I safely place these 2 files in the same folder as my Py2exe
generated EXE file or do I need to place the MSVCR90.DLL file in a
specially named sub-folder?
2. Do I need to rename the Microsoft.VC90.CRT.manifest file to
myapp.exe.manifest or can I leave it named as is?
3. Do I need to customize the contents of the
Microsoft.VC90.CRT.manifest file for my EXE?
I've been experimenting with different answers to the above questions
and multiple approaches seems to work. I suspect this is because all the
workstations I have access to for testing already have the full set of
MSVC*90.DLL's installed - and not because my multiple tests really work.
Thanks so much for your help!
Malcolm
I just created a VM containing a bare-bones install of Windows XP,
precisely so that I can reproduce the errors my users see when
MSVCR90.DLL is not installed.
It sounds like the wisest course of action is for me to use
vcredist_x86.exe to install the required MSVC runtime on the user's
machine (as opposed to trying to distribute MSVCR90.DLL with my
application.) I can be sure that I have rights to distribute this, and
I don't have to understand side-by-side DLL installation, and I'm
delegating any tricky decisions to Microsoft, who are presumably best
qualified to judge things like: what to do if other versions of the
DLLs are already installed; how to register them to be shared between
multiple applications; whether to update them if Windows Update
decrees it, etc)
I'm going to try to run vcredist_x86.exe automatically (as opposed to
asking my users to download and run it manually). I don't currently
have any installer, so I'm going to run vcredist_x86.exe on my
application start-up. Some logic like this seems to do this trick:
if platform.system() == 'Windows':
command = [path.join('lib', 'vcredist_x86.exe'), '/q']
retcode = subprocess.call(command)
if retcode != 0:
sys.stderr.write(
'Return value %d from vcredist_x86.exe\n' %
(retcode,))
This seems to work. My py2exe program will now run out of the box on a
bare-bones Windows XP install. (note: running 'vcredist_x86.exe /qu'
will uninstall the DLLs again)
However, this takes a few seconds to run. Is there a sensible way for
me to only run this if the required DLL is not already installed? How
should I be detecting that?
Also: Will this work on 64 bit machines? Or do I not need to worry
about that?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On Dec 29, 2:24 pm, Jonathan Hartley tart...@tartley.com wrote:
On Dec 27, 1:51 pm, pyt...@bdurham.com wrote:
Hi Martin,
You'll need to include Microsoft.VC90.CRT.manifest and msvcr90.dll.
Thank you for your answers. From my research and testing on this topic:
1. Can I safely place these 2 files in the same folder as my Py2exe
generated EXE file or do I need to place the MSVCR90.DLL file in a
specially named sub-folder?
2. Do I need to rename the Microsoft.VC90.CRT.manifest file to
myapp.exe.manifest or can I leave it named as is?
3. Do I need to customize the contents of the
Microsoft.VC90.CRT.manifest file for my EXE?
I've been experimenting with different answers to the above questions
and multiple approaches seems to work. I suspect this is because all the
workstations I have access to for testing already have the full set of
MSVC*90.DLL's installed - and not because my multiple tests really work.
Thanks so much for your help!
Malcolm
I just created a VM containing a bare-bones install of Windows XP,
precisely so that I can reproduce the errors my users see when
MSVCR90.DLL is not installed.
It sounds like the wisest course of action is for me to use
vcredist_x86.exe to install the required MSVC runtime on the user's
machine (as opposed to trying to distribute MSVCR90.DLL with my
application.) I can be sure that I have rights to distribute this, and
I don't have to understand side-by-side DLL installation, and I'm
delegating any tricky decisions to Microsoft, who are presumably best
qualified to judge things like: what to do if other versions of the
DLLs are already installed; how to register them to be shared between
multiple applications; whether to update them if Windows Update
decrees it, etc)
I'm going to try to run vcredist_x86.exe automatically (as opposed to
asking my users to download and run it manually). I don't currently
have any installer, so I'm going to run vcredist_x86.exe on my
application start-up. Some logic like this seems to do this trick:
if platform.system() == 'Windows':
command = [path.join('lib', 'vcredist_x86.exe'), '/q']
retcode = subprocess.call(command)
if retcode != 0:
sys.stderr.write(
'Return value %d from vcredist_x86.exe\n' %
(retcode,))
This seems to work. My py2exe program will now run out of the box on a
bare-bones Windows XP install. (note: running 'vcredist_x86.exe /qu'
will uninstall the DLLs again)
However, this takes a few seconds to run. Is there a sensible way for
me to only run this if the required DLL is not already installed? How
should I be detecting that?
Also: Will this work on 64 bit machines? Or do I not need to worry
about that?
I was fooling myself with sloppy testing, this doesn't work at all.
Obviously enough.
If the DLLs aren't installed, then my program can't be launched, and
can't bootstrap itself by installing the required DLL's.
I guess I really need an installer. Oh well.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On 29/12/2009 18:31, pyt...@bdurham.com wrote:
Jonathan,
snipped
I'm going to try to run vcredist_x86.exe automatically (as opposed to
asking my users to download and run it manually). I don't currently
have any installer, so I'm going to run vcredist_x86.exe on my
application start-up. Some logic like this seems to do this trick:
if platform.system() == 'Windows':
command = [path.join('lib', 'vcredist_x86.exe'), '/q']
retcode = subprocess.call(command)
if retcode != 0:
sys.stderr.write(
'Return value %d from vcredist_x86.exe\n' %
(retcode,))
This seems to work. My py2exe program will now run out of the box on a
bare-bones Windows XP install. (note: running 'vcredist_x86.exe /qu'
will uninstall the DLLs again)
/snipped
I'm surprised that this technique works because the Python interpreter
itself needs to find the MSVC*90.DLL files before it can startup and run
your program that installs the MSVC*90.DLL files. Sort of a chicken and
egg scenario.
Malcolm
Yeah, I was still clearly a little fuzzy-headed from Christmas when I
even thought to try that. It only appeared to work, I was trying it on
another machine (not my bare-bones VM) and evidently the required
msvcr90.dll was already installed elsewhere on that machine.
I'm just going to give in and stick the manifest and dll directly in
with my application as described by others earlier, from the cheapest
copy of Visual Studio I can lay my hands on.
Thanks to everyone for their help on this, it's been plaguing me for ages.
Jonathan Hartley Made of meat. http://tartley.com
tart...@tartley.com +44 7737 062 225 twitter/skype: tartley
--
http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On Dec 26, 3:14 pm, Ross Ridge rri...@csclub.uwaterloo.ca wrote: Jonathan Hartley tart...@tartley.com wrote: Am I right to infer that if I want to distribute a py2exe'd application legally, and have half a chance of it working on a non- developer's machine, then I have to: a) Ask my users to run the Visual C++ redistributable installer, as well as download my program. This is really unfortunate, since one of the major disadvantages of coding something in Python as opposed to as a web application is the overhead of asking users to download and execute anything at all. Asking them to do it twice seems problematic. Most users would regard this as a deal-breaking hurdle, do you think? or b) Buy a copy of Visual Studio in order to acquire the rights to distribute msvcr.dll (etc.) along with my application. If your users are paying to download your program then spending $1000 or whatever it is to buy Visual C++ doesn't seem to be unreasonable expense to make sure you're staying well within the right side of the law. If you're giving it away for free, or aren't expecting to make enough money to make spending $1000 worthwhile, then asking them to download something sepeately doesn't seem to be unreasonable either. I give my py2exe wrapped application for free so I'm not losing sleep just because a few people can't run it because they don't have 7.1 runtime already installed. That said, you might have couple of other options. Microsoft's documentation says that with the Express edition, it is recommended to redistribute Visual C++ libraries using the Visual C++ Redistributable Package. That suggests that you can redistribute the package with your application and have your installer run it automatically. My older copy of the Windows SDK includes the Visual C++ 2005 compilers with the C/C++ runtime merge modules, so lastest version of the SDK might include 2008 merge modules. Whatever you do, make sure you install the runtime correctly. Part of the reason for the restrictions on redistributing the runtime is so people don't just bindly copy DLLs around. That leads to older DLLs overriding newer DLLs and makes it difficult for Micrsoft to make security fixes. In particular they don't want a repeat of the GDI+ fiasco, where a buffer overrun of the image processing routines resulted security vulnerabilities in a lot of third party applications that couldn't be easily fixed by deploying a patched DLL with Windows Update. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] rri...@csclub.uwaterloo.ca -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // Thanks very much again Ross. Yeah, I'm looking at two scenarios: 1) Writing some games, which for the moment are free download, and hence have a high elasticity of demand. If I make the install fiddly, a lot of people won't bother. 2) About once a week the last couple of months I've had a friend phone to say 'can you write me a simple program to do X', where X is stuff like calling a web API to look up info for every postcode/zipcode in a database. This sort of thing is ideally suited to Python, but then when I come to send the program to my friend, it never works. These are non-technical users, so I'd rather send them a single executable that 'just works', rather than asking them to install Python and then coach them through running a script - they would HATE that as a solution. In each case, at the moment, I don't even have an installer. If I have to create one just for tiny 50 line applications like case (2), then that seems a large and cumbersome hurdle, unless the process can be automated for future projects. I feel like it would be a huge increase in Python's viability, usefulness and desirability if we could improve this situation. Best regards, many thanks to everyone who has contributed to my understanding on this thread. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On Dec 21, 2:56 pm, Ross Ridge rri...@csclub.uwaterloo.ca wrote: Jonathan Hartley tart...@tartley.com wrote: Many thanks for that, but my issue is that my programs work fine for me on my computer - but then fail on other people's computers. I'd very strongly prefer for my users to not have to install the MSVCR redistributable installer as well as my program - it would be much better if I could bundle everything up into my py2exe package so that it 'just works' on any Windows computer. So I think that means I'm looking for a stand-alone DLL (or several, plus the manifest file, it sounds like) to bundle up with my py2exe. Microsoft's documentation describes several possible ways you can redistribute the Visual C++ runtime: http://msdn.microsoft.com/en-us/library/ms235299.aspx From the sounds of things, if you only have Visual C++ 2008 Express your only option may be to use Visual C++ Redistributable Package. Ross Ridge -- l/ // Ross Ridge -- The Great HTMU [oo][oo] rri...@csclub.uwaterloo.ca -()-/()/ http://www.csclub.uwaterloo.ca/~rridge/ db // Hey. So I think I'm finally getting it. Am I right to infer that if I want to distribute a py2exe'd application legally, and have half a chance of it working on a non- developer's machine, then I have to: a) Ask my users to run the Visual C++ redistributable installer, as well as download my program. This is really unfortunate, since one of the major disadvantages of coding something in Python as opposed to as a web application is the overhead of asking users to download and execute anything at all. Asking them to do it twice seems problematic. Most users would regard this as a deal-breaking hurdle, do you think? or b) Buy a copy of Visual Studio in order to acquire the rights to distribute msvcr.dll (etc.) along with my application. This is kind of a shame, because it rules out the most obvious and desirable solution, which would be to distribute the DLLs which are required to give my Python application half a chance of running on my target user's PC's, without having to buy Visual Studio. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On Dec 17, 8:39 pm, Christian Heimes li...@cheimes.de wrote:
Jonathan Hartley wrote:
Only this week I sent a py2exe-derived executable to someone else (a
non-developer) and it would not run on their WinXP machine ('The
system cannot execute the specified program') - my current favourite
hypothesis is that my omission of this dll or something similar was to
blame.
To diagnose what's wrong, I can't get access to the machine that gives
the above error. To try and reproduce, I'm right now in the process of
creating a bare-bones WindowsXP installed on a VM.
MSVCR90 is a side-by-side assembly (SxS). You can't just copy a SxS
assembly to another computer. You must at least ship the manifest file,
too. The easiest way to get your program running is the installation of
the MSVCR redistributable installer.
Christian
Hey Christian,
Many thanks for that, but my issue is that my programs work fine for
me on my computer - but then fail on other people's computers. I'd
very strongly prefer for my users to not have to install the MSVCR
redistributable installer as well as my program - it would be much
better if I could bundle everything up into my py2exe package so that
it 'just works' on any Windows computer. So I think that means I'm
looking for a stand-alone DLL (or several, plus the manifest file, it
sounds like) to bundle up with my py2exe.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On Dec 17, 11:16 pm, Mark Hammond skippy.hamm...@gmail.com wrote: On 18/12/2009 7:44 AM, Ross Ridge wrote: The P DLL is for C++ and so the original poster may not actually need it. I'm pretty sure Python itself doesn't need it, and py2exe shouldn't either, but wxPython, or more precisely wxWidgets, almost certainly does. So in your case you'll probably need to redistribute both DLLs. FYI, my experience is that an entire manifest must be distributed. As the manifest in question actually lists 3 DLLs, IIUC, you must ship all 4 files - the 3 DLLs and the manifest, even if only one of the DLLs is actually used. This is from memory some time back though, so apologies in advance if I'm mis-remembering. Mark Thanks to everyone who replied, especially Ross obviously for such comprehensive info. I'll go percolate on what you wrote, and try some experiments on my new VM, see if it all makes sense for me when I put it into practice. -- http://mail.python.org/mailman/listinfo/python-list
Re: Which version of MSVC?90.DLL's to distribute with Python 2.6 based Py2exe executables?
On Dec 17, 5:36 pm, Ross Ridge rri...@csclub.uwaterloo.ca wrote:
pyt...@bdurham.com wrote:
Does anyone have any recommendations on which version of the
MSVC?90.DLL's need to be distributed with a Python 2.6.4 PY2EXE (0.6.9)
based executable? (I assume I need just a matching pair of MSVCR90.DLL
and MSVCP90.DLL?)
Either the one the came with your copy Microsoft Visual C++ or Python
2.6.4. Otherwise, you don't have the legal right to redistribute
Microsoft's code.
Ross Ridge
--
l/ // Ross Ridge -- The Great HTMU
[oo][oo] rri...@csclub.uwaterloo.ca
-()-/()/ http://www.csclub.uwaterloo.ca/~rridge/
db //
Hi. I clearly haven't yet quite understood this very well.
Only this week I sent a py2exe-derived executable to someone else (a
non-developer) and it would not run on their WinXP machine ('The
system cannot execute the specified program') - my current favourite
hypothesis is that my omission of this dll or something similar was to
blame.
To diagnose what's wrong, I can't get access to the machine that gives
the above error. To try and reproduce, I'm right now in the process of
creating a bare-bones WindowsXP installed on a VM.
My questions are, sadly, legion:
1) I don't understand why the OP's question doesn't deserve a literal
answer - isn't one of those DLLs in the WinSxS directory derived from
his MSVC install? In which case does he have the rights to
redistribute it?
Ross said:
Either the one the came with your copy Microsoft Visual C++ or Python 2.6.4.
2) The required dlls come with Python? Whatwhatwhat? Is this if I
download Python source to compile myself?
2b) Presumably these runtimes must come with Visual Studio express
edition (the free one.) I assume I can just prise the required DLL off
my filesystem after MSVS express edition has installed, rather than
insisting that my users run the MSVC runtime installer at
3) The wxpython site describes that I have to use a manifest file as
well as the DLLs, although I find no mention of the word 'manifest' on
www.py2exe.org, excepting a vaguely worded news item. Other sites (eg.
StackOverflow) report conflicting ideas of whether and when this
manifest file is needed. Is there a simple answer to whether this is
required?
4) The py2exe wiki says, of the msvc runtime dll version 7.1 (for
versions of Python prior to 2.6) that:
Since most Windows installations nowadays include this DLL by
default, it may be unnecessary.
To what extent is this true? Does the same not also apply to the msvc
runtime 9.0 dll? (for Python 2.6.4)
Malcome said:
(I assume I need just a matching pair of MSVCR90.DLL and MSVCP90.DLL?)
5) Whatwhatwhat again? More than one DLL is required? Are there ever
any more than these two?
Sorry to be dense. Terse links to useful sources of information
appreciated. I've read the whole py2exe wiki and been googling the
last hour.
Jonathan
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python without wrapper script
On Dec 2, 4:12 pm, Ulrich Eckhardt eckha...@satorlaser.com wrote: eric.frederich wrote: Is there a way to set up environment variables in python itself without having a wrapper script. Yes, sure, you can set environment variables... The wrapper script is now something like #!/bin/bash export LD_LIBRARY_PATH=/some/thing/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH=/another/thing/lib:$LD_LIBRARY_PATH export PATH=/some/thing/bin:$PATH export PATH=/another/thing/bin:$PATH python ./someScript.py ...but this won't work, I'm afraid. LD_LIBRARY_PATH is for the program loader / dynamic linker under Linux. This thing is what is invoked _before_ the program is started, any later modifications to the environment are ignored. Similarly PATH, which tells the shell (e.g. bash) where to find executables. If you need that to e.g. find 'python' itself, you're out of luck. Otherwise, I believe Python itself doesn't use PATH, so you could set it inside and any shells started from Python should pick it up. Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 I have had success in modifying LD_LIBRARY_PATH from within my Python code, to make sure that Python correctly loads DLL's from subdirectories of my project. (I believe the Python ended up calling CDll, or somesuch?) -- http://mail.python.org/mailman/listinfo/python-list
Re: Python without wrapper script
On Dec 3, 3:13 pm, Jonathan Hartley tart...@tartley.com wrote: On Dec 2, 4:12 pm, Ulrich Eckhardt eckha...@satorlaser.com wrote: eric.frederich wrote: Is there a way to set up environment variables in python itself without having a wrapper script. Yes, sure, you can set environment variables... The wrapper script is now something like #!/bin/bash export LD_LIBRARY_PATH=/some/thing/lib:$LD_LIBRARY_PATH export LD_LIBRARY_PATH=/another/thing/lib:$LD_LIBRARY_PATH export PATH=/some/thing/bin:$PATH export PATH=/another/thing/bin:$PATH python ./someScript.py ...but this won't work, I'm afraid. LD_LIBRARY_PATH is for the program loader / dynamic linker under Linux. This thing is what is invoked _before_ the program is started, any later modifications to the environment are ignored. Similarly PATH, which tells the shell (e.g. bash) where to find executables. If you need that to e.g. find 'python' itself, you're out of luck. Otherwise, I believe Python itself doesn't use PATH, so you could set it inside and any shells started from Python should pick it up. Uli -- Sator Laser GmbH Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932 I have had success in modifying LD_LIBRARY_PATH from within my Python code, to make sure that Python correctly loads DLL's from subdirectories of my project. (I believe the Python ended up calling CDll, or somesuch?) Ahar! But of course, I was modifying os.environ, not setting the actual environment. I see. -- http://mail.python.org/mailman/listinfo/python-list
Re: Anything equivalent to cassert in C++?
On Nov 26, 6:08 pm, Jean-Michel Pichavant jeanmic...@sequans.com wrote: Peng Yu wrote: There are some assertion code (testing if a condition is false, if it is false, raise an Error object) in my python, which is useful when I test my package. But such case would never occur when in the produce code. If I keep them in if statement, it will take some runtime. I'm wondering what is the practice that take care of the assertion code in python. Would never occur ? You can't use 'would' and 'never' in the same sentence. That is the kind of concect that make (to me) asserts diffcult to use. I personally never use asserts in python, cause I will end up handling with asserts what I should in fact handle properly in what you call the production code. Anyway that does not answer your question I'm sorry to be off topic, 'tis just a thought. Simon gave you the proper answer. Jean-Michel I can see this issue has several facets to it, so I don't intend to flagratly contradict your experience Jean-Michel, but I think that in at least some circumstances asserts used in this way can be valuable. One of the interesting points to come out of the recent flurry of empirical studies of software engineering is that quality of code as measured by defect density shows a definite negative correllation with use of asserts in production code. (Although the significance of this is somewhat lessened by the fact that both use of asserts and low defect density are correlated with the level of developer experience.) Original Microsoft paper here: http://research.microsoft.com/apps/pubs/default.aspx?id=70290 Summary article discussing that paper and others: http://research.microsoft.com/en-us/news/features/nagappan-100609.aspx Personally, I'm curious as to whether the benefit from asserts used in this way is in helping the developer to clarify in their own mind exactly what their expectations and invariants are. -- http://mail.python.org/mailman/listinfo/python-list
Re: IDE for python
On Nov 16, 5:09 am, sturlamolden sturlamol...@yahoo.no wrote: On 15 Nov, 18:09, Peng Yu pengyu...@gmail.com wrote: There had been some discussion on IDE. But I'm not sure what pros and cons of each choice. Current, I'm using vim and ctags. Could somebody give some advices on choosing the best IDE for me? There is a plug-in to develop (amd debug) Python using MS Visual Studio. It works with IronPython and CPython. There is the PyDev plug-in for Eclipse. There is Komodo from ActiveState. There is KDevelop in KDE4. Which is better? I don't know. My impression is that Python development does noe need an IDE like e.g. C++ development do. There is no build process, which takes the major advantage of the IDE away. I am fine with a editor like IDLE or Kate. I'd like to offer the group the anecdote of the great Resolver IDE migration. Developers at Resolver, where I work, choose their own IDE. Being developers, that meant every single person chose a different one. We had them all. Which turned out, slightly unexpectedly, to be just fine. We pair on all production code. So this meant we all spent a lot of time sitting at each other's desks. We soon all became pretty familiar with each other's environments - there's nothing like 8 hours a day of hands-on usage, coupled with sitting right next to a bone-fide expert to get you up to speed pretty quick. I even learned a little Emacs, holy cow! Occasionally, after seeing the details of how well some other IDE worked, developers would switch from one to another. Then, after about a year, a curious thing happened. One by one, in entirely independent decisions, almost all developers decided to migrate to either Emacs or Vi.* Each person decided that the fancy features of their IDE wasn't as useful to them as having a flexible, powerful and lightweight editor which can easily be scripted to provide whatever ad-hoc features they need. I regard this as an example of the way pairing spreads knowledge. * I say 'most developers' - there were two notable exceptions: Michael Foord, who's prodigious contributions are legend, who likes Wing, and Will Reade, our tame brainiac, responsible for the exceedingly clever 'IronClad' open-source project, who likes the uncomplicated simplicity of TextPad. As far as I can make out, TextPad has only two features, syntax highlighting and the ability to define a 'make' command, and a regex that is used to extract filenames and line-numbers from the resulting output of that make command. These are, it turns out, sufficient to transform a program that would otherwise simply be 'Notepad' into an entirely credible development environment. -- http://mail.python.org/mailman/listinfo/python-list
Re: Vote on PyPI comments
On Nov 15, 9:21 am, Daniel Fetchinson fetchin...@googlemail.com wrote: I am skeptical about the utility of both rating and comments. If somebody wants to know if a package is good, she should ask here. Because unlike people writing comments, people here are never incompetent, misinformed, dishonest, confused, trolling or just wrong. But sometimes sarcastic. All right, but the newsgroup has interactivity and the presence of true Python experts too. A blind vote given by an anonymous person does not look more informative to me. You are right about a single vote, but the way these things usually work is that out of 1000 votes the non-informative ones average out (wow! awsome package! vs this sucks bad!) and the net vote result is generally indicative of the actual thing that was voted on especially when there is no direct financial incentive to cheat. Cheers, Daniel -- Psss, psss, put it down! -http://www.cafepress.com/putitdown I haven't used the PyPI rating / comments system at all. Can comments accrue which complain about bugs or missing features of old versions of the package? If so, they could be misleading for users coming to view a package before trying it. Or do comments and ratings only apply to a particular version of a package, and get removed from the package's 'front page' every time a new version is released? Thanks, Jonathan Hartley -- http://mail.python.org/mailman/listinfo/python-list
Re: bootstrapping on machines without Python
On Nov 13, 1:57 pm, Tim Golden m...@timgolden.me.uk wrote: Jonathan Hartley wrote: While examining py2exe et al of late, my thoughts keep returning to the idea of writing, in C or similar, a compiled stand-alone executable 'bootstrapper', which: 1) downloads and install a Python interpreter if none exists 2) runs the application's Python source code using this interpreter. Thinking aloud about what you're describing here... Assuming Windows, as your starting point is py2exe and I imagine that most Unix-like boxes already have Python on them. Step 1: The user downloads a tiny myapp.exe which is basically a zip of the myapp package / files plus an .exe header which will... Step 2a: ... download a minimised? (ie custom-built) Python interpreter and stdlib bundle which is just enough to run the app. Or... Step 2b: ... download and install the official python.org Windows installer for version x.y identified as the highest known to run this app if... Step 2bi) ... that version of the interpreter isn't already installed and registered on that machine (at least: for that user). My step 2a seems to be little better than a bundled py2exe, so I can only assume you mean Step 2b, especially given your comment below about ending up with an installation of Python where one wasn't before. This, though, seems fraught with accusations of backdoor installations etc. Have I misunderstood you? For the Record, I'm entirely in favour of moves to make Python use on Windows more seamless, attractive, consistent, etc. I was going to comment positively on your recent PyChooser widget and to plug a similar but unpublished one of my own. But I'm not sure if this particular proposal has enough wings to make it fly. TJG Hi Tim. Thanks for that. Yes, you have understood pretty much perfectly. I was envisaging something like 2b. I'm very much enamored of creating cross-platform apps, but I'm focused on deployment on Windows first, because this is where most users are, and also where the problem seems to need the most work. Your input is very much appreciated. It may be that you are right that I haven't thought this through clearly enough. Incidentally, I'd love to see your approach of dealing with the problem that pychoose addresses - Since creating it, I'm gripped with paranoia that it is failing to take account of lots of things which will trip me up later (or worse- trip other people up too, if anyone uses it) -- http://mail.python.org/mailman/listinfo/python-list
Re: bootstrapping on machines without Python
On Nov 13, 10:25 pm, mma...@gmx.net wrote: On Fri, 13 Nov 2009 02:40:28 -0800 (PST) Jonathan Hartley tart...@tartley.com wrote: Even my very limited understanding of the issues is enough to see that the idea is far from trivial. Thanks heaps for the input from everyone. Martin Lemburg's 'chained' approach does sound like the smart way to do it, and Thomas does demonstrate pretty much the simplest possible example of what I'm thinking of. Martin Manns' portable Python sounds useful too, and is not disimilar to a suggestion made by Michael Foord off list. However, the problems that Tim, Martin, Marc and Martin point out do seem very real. I think users could be placated about 'backdoor installation' if we tell them what's going on, with an OK button. But I confess I wasn't aware that a full Python install is quite so large compared to the bundle produced by py2exe et al. Perhaps this idea is overly idealistic then - I was maybe transfixed by the 'needless consistency' of sharing a single interpreter between many applications. Thanks for helping me straighten out my thoughts on the subject. Best! Jonathan -- http://mail.python.org/mailman/listinfo/python-list
bootstrapping on machines without Python
While examining py2exe et al of late, my thoughts keep returning to the idea of writing, in C or similar, a compiled stand-alone executable 'bootstrapper', which: 1) downloads and install a Python interpreter if none exists 2) runs the application's Python source code using this interpreter. An application source code could be distributed with this small exe to wrap its top level 'main.py', and the application could then be run on machines which do not (yet) have Python installed. The goal of this is to provide a way for end-users to download and double-click a Python application, without having to know what Python is or whether (an appropriate version of) it is installed. This method has some disadvantages compared to using py2exe et al, but it has the advantage that a small application would remain small: there is no need to bundle a whole interpreter with every application. From an advocacy point of view, it also must help that merely running such an application would seamlessly put a usable Python interpreter installed and on the PATH on Windows boxes. Even my very limited understanding of the issues is enough to see that the idea is far from trivial. I'm aware that great minds are working on related and overlapping problems, so I thought I'd ask whether many people have done this already, and if not, is there any value in taking the trivial first step described above? ie. Ignore all complications, and write a simple C program to download install an interpreter, then use that to run my Python. In the long run, to be useful for real projects, the bootstrapper would need to manage some nasty details: * different versions of the interpreter for different applications * download required packages * manage conflicting versions of packages I'm hoping that these thorny problems will be solved, if they aren't already, by the great minds working on packaging, etc. I'm very aware that I don't know anything at all about this, compared to many on the list. Be gentle with me. :-) -- http://mail.python.org/mailman/listinfo/python-list
Re: comparing alternatives to py2exe
On Nov 10, 1:34 pm, Philip Semanchuk phi...@semanchuk.com wrote: On Nov 9, 2009, at 9:16 PM, Gabriel Genellina wrote: En Fri, 06 Nov 2009 17:00:17 -0300, Philip Semanchuk phi...@semanchuk.com escribió: On Nov 3, 2009, at 10:58 AM, Jonathan Hartley wrote: Recently I put together this incomplete comparison chart in an attempt to choose between the different alternatives to py2exe: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput... I was interested in py2exe because we'd like to provide a one download, one click install experience for our Windows users. I think a lot of people are interested in py2exe for the same reason. Well, one thing that I came across in my travels was the fact that distutils can create MSIs. Like py2exe, MSIs provide a one download, one click install experience under Windows and therefore might be a replacement for py2exe. But py2exe and .msi are complementary, not a replacement. py2exe collects in onedirectory(or even in one file in some cases) all the pieces necesary to run your application. That is,Python itself + your application code + all referenced libraries + other required pieces. The resulting files must beinstalledin the client machine; you either build a .msi file (a database for the Microsoft Installer) or use any other installer (like InnoSetup, the one I like). For me, the following command was sufficient to create an msi, although it only worked under Windows (not under Linux or OS X): pythonsetup.py bdist_msi The resulting MSI worked just fine in my extensive testing (read: I tried it on one machine). The resulting .msi file requiresPythonalreadyinstalledon the target machine, if I'm not mistaken. The whole point of py2exe is to avoid requiring a previousPythoninstall. You're right; the MSI I created doesn't include prerequisites. It packaged up our app, that's it. To be fair to MSIs, they might be capable of including prerequisites, the app, and the kitchen sink. But I don't thinkPython'screation process through distutils makes that possible. That's why I suggested MSIs belong alongside RPM/DEB in the chart (if they're to be included at all). I wouldn't say that the whole point of py2exe is to bundlePython. That's certainly a big benefit, but another benefit is that it can bundle an app into a one-click download. That's why we were interested in it. It seems, then, that creating an MSI is even within the reach of someone like me who spends very little time in Windows-land, so it might be worth a column on your chart alongside rpm/deb. As said inhttp://wiki.python.org/moin/DistributionUtilitiesthe easiest way is to use py2exe + InnoSetup. Easiest for you. =) The list of packages and modules that might require special treatment is almost a perfect superset of the modules we're using in our application:http://www.py2exe.org/index.cgi/WorkingWithVariousPackagesAndModules py2exe looks great, but it remains to be seen if it's the easiest way to solve our problem. The MSI isn't nearly as nice for the end user, but we created it using only thePythonstandard library and our existing setup.py. Simplicity has value. Cheers Philip Hey Philip and Gabriel, Interesting to hear your respective perspectives - you've given me much to ponder and to read about. Personally I'm keen to find a method that doesn't require the end-user to have to manually install (the correct version of) Python separately from my app, so I think that rules out the distutils-generated MSI for me. I can see it has value for others though. -- http://mail.python.org/mailman/listinfo/python-list
comparing alternatives to py2exe
Hi, Recently I put together this incomplete comparison chart in an attempt to choose between the different alternatives to py2exe: http://spreadsheets.google.com/pub?key=tZ42hjaRunvkObFq0bKxVdgoutput=html Columns represent methods of deploying to end-users such that they don't have to worry about installing Python, packages or other dependencies. 'Bundle' represents manually bundling an interpreter with your app. 'Bootstrap' represents a fanciful idea of mine to include an installer that downloads and installs an interpreter if necessary. This sounds fiddly, since it would have to install side-by- side with any existing interpreters of the wrong version, without breaking anything. Has anyone done this? The remaining columns represent the projects out there I could find which would do the bundling for me. Are there major things I'm missing or misunderstanding? Perhaps folks on the list would care to rate (+1/-1) rows that they find important or unimportant, or suggest additional rows that would be important to them. Maybe an updated and complete version of this table would help people agree on what's important, and help the various projects to improve faster. Best regards, Jonathan -- http://mail.python.org/mailman/listinfo/python-list
Re: file system iteration
Georg Brandl wrote: Which application needs to walk over ALL files? How about 'updatedb' for starters, the index-maintainer for the common *nix command-line utility 'locate'. I'm pretty sure that os.walk( ) deals with symbolic links (by not visiting them) and ' /proc' type complexities by not doing anything to walked directories that '/proc' type entries cannot deal with. I think (no sarcasm intended) the point of offering a directory-like interface to '/proc' was so one can perform directory-like operations on it. -- Jonathan Hartley [EMAIL PROTECTED] +44 7737 062 225 -- http://mail.python.org/mailman/listinfo/python-list
