Re: ImportError with pickle (Python 2.7.9), possibly platform dependent
On Friday, 1 May 2015 13:09:48 UTC+1, Chris Angelico wrote: Cool! That's part way. So, can you simply stuff OMDBMap into sys.modules prior to loading? It might be a bit of a hack, but it should work for testing, at least. Conversely, you could change the dump script to import via the name my_wsgi_app to make it consistent. ChrisA Sorry for not coming back to this sooner. In our case we are probably just going to work with a different file format because this was something like the 3rd time that the way pickle works caused our loading to fail for some reason or other. I think the hoops we need to jump through to ensure that the dumping and loading environments match up are too high relative to the cost of switching to JSON or similar, especially if we might need to load the data from something other than Python in future (god forbid). -- Ben Sizer -- https://mail.python.org/mailman/listinfo/python-list
Re: ImportError with pickle (Python 2.7.9), possibly platform dependent
On Friday, 1 May 2015 13:34:41 UTC+1, Peter Otten wrote: Ben Sizer wrote: So... I don't know how to fix this, but I do now know why it fails, and I have a satisfactory answer for why it is acting differently on the Linux server (and that is just because that is the only one running under WSGI). Two out of three isn't bad! How about moving OMDBMap.py into the parent folder of my_wsgi_app.__file__ or any other folder in sys.path? That might work, but wouldn't be practical for us because in some configurations my_wsgi_app doesn't exist at all (as it is an artifact of running under mod_wsgi environment) and when it does, it it at the top of the hierarchy - so the rest of the app wouldn't be access modules there. It could be put into sys.path somewhere else... but that is starting to break the project structure just to satisfy pickle. Instead, we'll just use a different format in future. -- Ben Sizer -- https://mail.python.org/mailman/listinfo/python-list
Re: ImportError with pickle (Python 2.7.9), possibly platform dependent
On Thursday, 30 April 2015 01:45:05 UTC+1, Chris Angelico wrote: On Thu, Apr 30, 2015 at 2:01 AM, Ben Sizer wrote: 1) There clearly is a module named OMDBMap, and it's importable - it's there in the 2nd line of the traceback. Does anybody have any suggestions on how I can go about debugging this? Or refactoring it to avoid whatever is happening here? Are you half way through importing it when this load() call happens? That might cause some issues. No, we already imported OMDBMap at the top of OMDBSetup. Has your current directory been changed anywhere in there? Good question. It turns out that the current directory seems to be $HOME when loading, but is the script directory during saving. This will be because the Linux server is running under mod_wsgi, whereas we run the save script in-place. Our Windows and Mac tests run via Flask's built-in server so the working directory is likely to be the same whether we're running the script that does pickle.dump or the whole app that does pickle.load. What happens if you catch this exception and print out sys.modules at that point? Another good question, and this gives us the answer. The module lists are quite different, as I'd expect because the load happens in the context of the full application whereas the dump happens as a standalone script. But literally every module that is in the 'before dump' list is in the 'before load' list - except OMDBMap. Like the error says! What /is/ in the 'before load' list however is my_wsgi_app.OMDBMap. The module has been imported, but the pickle algorithm is unable to reconcile the module in the WSGI app's namespace with the module referenced in the pickle file. So... I don't know how to fix this, but I do now know why it fails, and I have a satisfactory answer for why it is acting differently on the Linux server (and that is just because that is the only one running under WSGI). Two out of three isn't bad! Thanks, -- Ben Sizer -- https://mail.python.org/mailman/listinfo/python-list
ImportError with pickle (Python 2.7.9), possibly platform dependent
I'm saving some data via pickle, and loading it in is proving tricky. Traceback (most recent call last): [...some lines removed...] File /home/kylotan/OMDBSetup.py, line 44, in get_omdb_map __omdb_map = OMDBMap.OMDBMap.load_from_binary(full_path) File /home/kylotan/OMDBMap.py, line 87, in load_from_binary d = pickle.load(binary_file) File /usr/local/lib/python2.7/pickle.py, line 1378, in load return Unpickler(file).load() File /usr/local/lib/python2.7/pickle.py, line 858, in load dispatch[key](self) File /usr/local/lib/python2.7/pickle.py, line 1090, in load_global klass = self.find_class(module, name) File /usr/local/lib/python2.7/pickle.py, line 1124, in find_class __import__(module) ImportError: No module named OMDBMap Here are the 2 weird things: 1) There clearly is a module named OMDBMap, and it's importable - it's there in the 2nd line of the traceback. 2) This error only arises on Linux. Exactly the same file loads in properly on MacOSX, and on Windows 8. What I've done to try and debug this: a) I've run an MD5 on the file to make sure the file is identical on all platforms, and that nothing is changing the line endings, and I'm also making sure to both open and save the pickle with 'rb'/'wb'. b) I tried both pickle and cPickle - they seem to produce slightly different output but the error is exactly the same in each case. c) I pickle and unpickle from exactly the same file (a file called OMDBSetup.py does 'import OMDBMap' and then calls methods in there to save and load the data (including the OMDBMap.OMDBMap.load_from_binary which contains the above callstack). The intention here was to avoid both the common No module named __main__ error, and to hopefully have exactly the same modules imported into the namespace at both save and load time. So my hypothesis is that I've either found some edge case which only acts weird on Linux (or only succeeds on the other platforms, whichever way you look at it), or there's something wrong with the Linux configuration that means it somehow cannot find this module (despite it already having found it to get this far). Does anybody have any suggestions on how I can go about debugging this? Or refactoring it to avoid whatever is happening here? -- Ben Sizer -- https://mail.python.org/mailman/listinfo/python-list
Creating an object that can track when its attributes are modified
I am trying to make an object that can track when its attributes have been assigned new values, and which can rollback to previous values where necessary. I have the following code which I believe works, but would like to know if there are simpler ways to achieve this goal, or if there are any bugs I haven't seen yet. class ChangeTrackingObject(object): def __init__(self): self.clean() def clean(self): Mark all attributes as unmodified. object.__setattr__(self, '_dirty_attributes', dict()) def dirty_vals(self): Returns all dirty values. return dict( [ (k,v) for k,v in self.__dict__.iteritems() if k in self._dirty_attributes] ) def get_changes_and_clean(self): Helper that collects all the changes and returns them, cleaning the dirty flags at the same time. changes = self.dirty_vals() self.clean() return changes def rollback(self): Reset attributes to their previous values. for k,v in self._dirty_attributes.iteritems(): object.__setattr__(self, k, v) self.clean() def __setattr__(self, key, value): # If the first modification to this attribute, store the old value if key not in self._dirty_attributes: if key in self.__dict__: self._dirty_attributes[key] = object.__getattribute__(self, key) else: self._dirty_attributes[key] = None # Set the new value object.__setattr__(self, key, value) I am aware that adding a new attribute and then calling rollback() leaves the new attribute in place with a None value - maybe I can use a special DeleteMe marker object in the _dirty_attributes dict along with a loop that calls delattr on any attribute that has that value after a rollback. I also believe that this won't catch modification to existing attributes as opposed to assignments: eg. if one of the attributes is a list and I append to it, this system won't notice. Is that something I can rectify easily? Any other comments or suggestions? Thanks, -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating an object that can track when its attributes are modified
On Wednesday, 6 March 2013 16:22:56 UTC, Chris Angelico wrote: Effectively, you would need to have a subclass of list/dict/tuple/whatever that can respond to the change. This is certainly something I'd be interested in having, but I guess that would be fragile since the user would have the burden of having to remember to use those types. What's the goal of this class? Can you achieve the same thing by using, perhaps, a before-and-after snapshot of a JSON-encoded form of the object? I need to be able to perform complex operations on the object that may modify several properties, and then gather the properties at the end as an efficient way to see what has changed and to store those changes. Any comparison of before-and-after snapshots could work in theory, but in practice it could be expensive to produce the snapshots on larger objects and probably expensive to calculate the differences that way too. Performance is important so I would probably just go for an explicit function call to mark an attribute as having been modified rather than trying to do a diff like that. (It wouldn't work for rollbacks, but I can accept that.) -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Creating an object that can track when its attributes are modified
On Thursday, 7 March 2013 00:07:02 UTC, Steven D'Aprano wrote: On Wed, 06 Mar 2013 08:56:09 -0800, Ben Sizer wrote: I need to be able to perform complex operations on the object that may modify several properties, and then gather the properties at the end as an efficient way to see what has changed and to store those changes. Any comparison of before-and-after snapshots could work in theory, but in practice it could be expensive to produce the snapshots on larger objects and probably expensive to calculate the differences that way too. Performance is important so I would probably just go for an explicit function call to mark an attribute as having been modified rather than trying to do a diff like that. (It wouldn't work for rollbacks, but I can accept that.) Premature optimization. Unless you have been eating and breathing Python code for 15+ years, your intuition of what is expensive and what isn't will probably be *way* off. I've been using Python for ~15 years, and I wouldn't want to try to guess what the most efficient way to do this will be. I admit, I've only been using Python for 10 years, but I've learned a lot about optimisation and what needs optimising from my time as a game developer. This code needs to be fairly high-performing due to the role it plays in my server and the frequency with which the behaviour gets called. Actually I lie. I would guess that the simple, most obvious way is faster: don't worry about storing what changed, just store *everything*. But I could be wrong. The use case I have is not one where that is suitable. It's not the snapshots that are important, but the changes between them. Fortunately, Python development is rapid enough that you can afford to develop this object the straightforward way, profile your application to see where the bottlenecks are, and if it turns out that the simple approach is too expensive, then try something more complicated. I don't see a more straightforward solution to the problem I have than the one I have posted. I said that a system that took snapshots of the whole object and attempted to diff them would probably perform worse, but it would probably be more complex too, given the traversal and copying requirements. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Installing PyPy alongside Python 2.7 on Windows?
On Jul 13, 7:29 am, cjrh caleb.hatti...@gmail.com wrote: You can just extract the windows pypy 1.5 distribution to any folder and run pypy.exe from there as if it was called python.exe. This is how I have been using it. In fact, pypy has been the default python for my portable eclipse for a good while now. That doesn't give access to existing site-packages, or allow me to install binary packages that it can access. Hence me asking about that specifically. -- http://mail.python.org/mailman/listinfo/python-list
Installing PyPy alongside Python 2.7 on Windows?
I'd like to evaluate the recent build of PyPy on the project I'm currently working on, but am not sure how best to go about it. So my question is simply - how would I go about installing PyPy alongside Python 2.7 on Windows? In particular, unzipping PyPy and adding it to the PATH is easy enough, but what about getting setuptools and easy_setup working to install various packages for it? Is there a virtualenv-based method I can use here? (And is pip a decent replacement for setuptools on Windows yet?) -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Confusion over etree.ElementTree.Element.getiterator
On Jul 4, 7:33 am, Stefan Behnel stefan...@behnel.de wrote:
BenSizer, 04.07.2010 00:32:
On Jul 3, 11:12 pm,BenSizerkylo...@gmail.com wrote:
for el in root.getiterator():
... print el
[much output snipped]
Element {http://www.w3.org/1999/xhtml}a at d871e8
Element {http://www.w3.org/1999/xhtml}a at d87288
Element {http://www.w3.org/1999/xhtml}script at d87300
Element {http://www.w3.org/1999/xhtml}script at d87378
Hmm, I think I've worked it out. Apparently the XML namespace forms
part of the tag name in this case. Is that what is intended?
Sure.
I didn't see any examples of this in the docs.
Admittedly, it's three clicks away from the library docs on docs.python.org.
http://effbot.org/zone/element.htm#xml-namespaces
Hopefully someone will see fit to roll this important documentation
into docs.python.org before the next release... oops, too late. ;)
It's one of those things that's easy to fix when you know what the
problem is. Unfortunately it makes the examples a bit awkward. The
example on http://docs.python.org/library/xml.etree.elementtree.html
opens up an xhtml file and reads a p tag within a body tag, but
the xhtml specification (http://www.w3.org/TR/xhtml1/#strict) states
that 'The root element of the document must contain an xmlns
declaration for the XHTML namespace'. Therefore I don't see how the
example Python code given could work on a proper xhtml file, given
that there should always be a namespace in effect but the code doesn't
allow for it.
That's my excuse anyway! :)
--
Ben Sizer
--
http://mail.python.org/mailman/listinfo/python-list
Confusion over etree.ElementTree.Element.getiterator
It seems that getiterator isn't returning the tags I ask for.
tree = parse('gdlibs.html')
root = tree.getroot()
for el in root.getiterator():
...print el
[much output snipped]
Element {http://www.w3.org/1999/xhtml}a at d871e8
Element {http://www.w3.org/1999/xhtml}a at d87288
Element {http://www.w3.org/1999/xhtml}script at d87300
Element {http://www.w3.org/1999/xhtml}script at d87378
it = root.getiterator('script')
all_scripts = list(it)
print len(all_scripts)
0
I would have expected at least 2 script tags to be found, considering
iterating over the whole lot found at least 2 at the end there.
What am I doing wrong?
import sys
print sys.version
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
I will upgrade to 2.6.5 ASAP, but I don't see anything in the
changelog that implies a bug that has been fixed here.
--
Ben Sizer
--
http://mail.python.org/mailman/listinfo/python-list
Re: Confusion over etree.ElementTree.Element.getiterator
On Jul 3, 11:12 pm, Ben Sizer kylo...@gmail.com wrote:
for el in root.getiterator():
... print el
[much output snipped]
Element {http://www.w3.org/1999/xhtml}a at d871e8
Element {http://www.w3.org/1999/xhtml}a at d87288
Element {http://www.w3.org/1999/xhtml}script at d87300
Element {http://www.w3.org/1999/xhtml}script at d87378
Hmm, I think I've worked it out. Apparently the XML namespace forms
part of the tag name in this case. Is that what is intended? I didn't
see any examples of this in the docs.
--
Ben Sizer
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is pythonic version of scanf() or sscanf() planned?
On Oct 3, 11:06 pm, ryniek90 rynie...@gmail.com wrote: Hi I know that in python, we can do the same with regexps or *.split()*, but thats longer and less practical method than *scanf()*. I also found that (http://code.activestate.com/recipes/502213/), but the code doesn't looks so simple for beginners. So, whether it is or has been planned the core Python implementation of *scanf()* ? (prefered as a batteries included method) Perhaps struct.unpack is close to what you need? Admittedly that doesn't read from a file, but that might not be a problem in most cases. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: 'Import sys' succeeds in C++ embedded code, but module is not fully visible
On Jan 14, 4:37 pm, Ivan Illarionov ivan.illario...@gmail.com wrote: On Jan 14, 1:49 pm, Ben Sizer kylo...@gmail.com wrote: No, I don't want to do anything with sys.path apart from see it. I just wanted my original question answered, not a guess at my intent and a solution for something I'm not doing. ;) Thanks though! Again - why can I not reference sys from within the function? Ah, sorry for wrong guess. I would try to use ourNamespace_ dict for both globals and locals in PyRun_String call. Yes, this seems to fix it, thanks. But why? Can some Python guru explain why these two dictionaries must be the same? (Or what steps we must take if we want them to be separate?) The documentation is not very clear. I had hoped to be able to clear out the locals dictionary while leaving useful functions intact in the globals dictionary, but it would appear that is not practical. (On a separate note, while trying to debug this it seemed that Python will look for debug versions of a library when you embed it in debug mode, and will fail to find a module if you only have the release versions there. The error message you get isn't too helpful about this however, and I only worked it out by looking at the very long list of filesystem calls Python made to try and find it. Anybody wishing to speed up import times might want to ensure they don't have a long Python path and as few eggs in site-packages as possible.) -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: 'Import sys' succeeds in C++ embedded code, but module is not fully visible
On Jan 14, 1:55 am, Ivan Illarionov ivan.illario...@gmail.com wrote: Ben Sizer kylo...@gmail.com wrote: What am I doing wrong? What are you trying to achieve? If you want to modify sys.path I suggest using Python/C API directly: No, I don't want to do anything with sys.path apart from see it. I just wanted my original question answered, not a guess at my intent and a solution for something I'm not doing. ;) Thanks though! Again - why can I not reference sys from within the function? -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: 'Import sys' succeeds in C++ embedded code, but module is not fully visible
On Jan 14, 4:37 pm, Ivan Illarionov ivan.illario...@gmail.com wrote: I would try to use ourNamespace_ dict for both globals and locals in PyRun_String call. I will try it when I get home. However I would like to be able to treat them as separate dictionaries, as I want to be able to import some symbols and modules at a global level, but be able to clear out objects introduced at the local level on a periodic basis, so that I can have some degree of isolation between distinct 'scripts'. The docs aren't terribly clear about what the globals and locals parameters to PyRun_String actually do, though. I also wonder if this is something specific to the sys module, since it's already been shown that there are some specific C API functions for it. I will try with other modules and see if they exhibit the same symptoms. And I'm still wondering about the sys.path[0] question. :) -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
'Import sys' succeeds in C++ embedded code, but module is not fully visible
I have the following C++ code and am attempting to embed Python 2.5,
but although the import sys statement works, attempting to reference
sys.path from inside a function after that point fails. It's as if
it's not treating it as a normal module but as any other global
variable which I'd have to explicitly qualify.
Py_InitializeEx(0); // the zero skips registration of signal
handlers.
PyObject* ourNamespace_ = PyDict_New();
PyDict_SetItemString(ourNamespace_, __builtins__,
PyEval_GetBuiltins());
PyObject* locals = PyDict_New();
const char* scriptStr =
print '1'\n
import sys\n
print sys.path\n
def debug_path_info():\n
print 'These are the directories Python looks into for
modules and source files:'\n
print '2'\n
for folder in sys.path:\n
print folder\n
print '--'\n
print 'This would be your present working folder/
directory:'\n
print '3'\n
print sys.path[0]\n
debug_path_info()\n;
PyObject* scriptResult = PyRun_String(
scriptStr, // Python code to execute
Py_file_input,
ourNamespace_, // globals dictionary
locals);// locals dictionary
if (!scriptResult)
{
std::cerr Python error: Unhandled Python exception
from
script. std::endl;
PyErr_Print();
}
else
{
Py_DECREF(scriptResult); // don't need result any more
}
Py_DECREF(locals);
Py_DECREF(ourNamespace_);
Py_Finalize();
And the output is like this:
1
['E:\\code\\Python25\\lib\\site-packages\\turbokid-1.0.4-py2.5.egg',
'E:\\code\\
Python25\\lib\\site-packages\\turbocheetah-1.0-py2.5.egg', 'E:\\code\
\Python25\\
lib\\site-packages\\simplejson-1.8.1-py2.5-win32.egg', 'E:\\code\
\Python25\\lib\
\site-packages\\ruledispatch-0.5a0.dev_r2306-py2.5-win32.egg', 'E:\
\code\\Python
25\\lib\\site-packages\\pastescript-1.6.2-py2.5.egg', 'E:\\code\
\Python25\\lib\\
site-packages\\formencode-1.0.1-py2.5.egg', 'E:\\code\\Python25\\lib\
\site-packa
ges\\decoratortools-1.7-py2.5.egg', 'E:\\code\\Python25\\lib\\site-
packages\\con
figobj-4.5.2-py2.5.egg', 'E:\\code\\Python25\\lib\\site-packages\
\cherrypy-2.3.0
-py2.5.egg', 'E:\\code\\Python25\\lib\\site-packages\\kid-0.9.6-
py2.5.egg', 'E:\
\code\\Python25\\lib\\site-packages\\cheetah-2.0.1-py2.5-win32.egg',
'E:\\code\\
Python25\\lib\\site-packages\\pyprotocols-1.0a0-py2.5-win32.egg', 'E:\
\code\\Pyt
hon25\\lib\\site-packages\\pastedeploy-1.3.1-py2.5.egg', 'E:\\code\
\Python25\\li
b\\site-packages\\paste-1.6-py2.5.egg', 'E:\\code\\Python25\\lib\\site-
packages\
\sqlobject-0.10.0-py2.5.egg', 'E:\\code\\Python25\\lib\\site-packages\
\tgfastdat
a-0.9a7-py2.5.egg', 'E:\\code\\Python25\\lib\\site-packages\
\webhelpers-0.6-py2.
5.egg', 'E:\\code\\Python25\\lib\\site-packages\\shove-0.1.3-
py2.5.egg', 'E:\\co
de\\Python25\\lib\\site-packages\\boto-1.3a-py2.5.egg', 'E:\\code\
\Python25\\lib
\\site-packages\\sqlalchemy-0.5.0beta3-py2.5.egg', 'E:\\code\\Python25\
\lib\\sit
e-packages\\turbojson-1.1.4-py2.5.egg', 'E:\\code\\Python25\\lib\\site-
packages\
\setuptools-0.6c9-py2.5.egg', 'E:\\code\\Python25\\lib\\site-packages\
\turbogear
s-1.0.8-py2.5.egg', 'C:\\WINDOWS\\system32\\python25_d.zip', 'E:\\code\
\Python25
\\Lib', 'E:\\code\\Python25\\DLLs', 'E:\\code\\Python25\\Lib\\lib-tk',
'e:\\Visu
al Studio 2008\\Projects\\StacklessEmbed\\StacklessEmbed', 'e:\\Visual
Studio 20
08\\Projects\\StacklessEmbed\\Debug', 'E:\\code\\Python25', 'E:\\code\
\Python25\
\lib\\site-packages', 'E:\\code\\Python25\\lib\\site-packages\\PIL',
'E:\\code\\
Python25\\lib\\site-packages\\wx-2.8-msw-unicode']
These are the directories Python looks into for modules and source
files:
2
Python error: Unhandled Python exception from script.
Traceback (most recent call last):
File string, line 13, in module
File string, line 7, in debug_path_info
NameError: global name 'sys' is not defined
[12532 refs]
(Incidentally, the Stackless references are because I was originally
trying to embed Stackless, but I reverted to vanilla 2.5 to see if it
was a Stackless specific issue, which it appears not.)
Another interesting thing is that sys.path[0] doesn't appear to be the
current working directory, despite several sources online suggesting
it should be.
What am I doing wrong?
--
Ben Sizer
--
http://mail.python.org/mailman/listinfo/python-list
Re: Plz help..SocketServer UDP server losing lots of packets
On Nov 6, 12:46 am, James Mills [EMAIL PROTECTED] wrote: Try these instead: * UDPServer -http://trac.softcircuit.com.au/circuits/browser/examples/udpserver.py * UDPClient -http://trac.softcircuit.com.au/circuits/browser/examples/udpclient.py Since there's no contact details on the Circuits site, and the guest Trac account doesn't work (it asks the admin to verify the email), then I'll post here: it appears that the Hello World example is wrong, trying to add an instance of a 'hello' object that doesn't exist. I've not tried to run the example, but it certainly confused me when trying to work out how Circuits works. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Python GUI interpreter slower than DOS-version?
On Aug 12, 4:04 pm, ssecorp [EMAIL PROTECTED] wrote: Sometimes when running very intensive computations the Python- interpreter kind of overheats and stops responding. I have gotten the impression that the dos-version is less likely to crash. Can that be true and if so, why? Is there anyway to get around this? Pretty annoying that it stops responding, would be nice to be able to control-c out of it like in DOS when you want to terminate a program. If a Windows app says it's stopped responding, that doesn't mean it's crashed. It just means it's not servicing the message pump. Chances are high that the program is still running just as normal. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Undefined calling conventions in Python.h
On Jul 23, 1:19 pm, Fredrik Lundh [EMAIL PROTECTED] wrote: Ben Sizer wrote: You should put the extern block around the #include python.h call rather than individual functions, as surely the C calling convention should apply to everything within. Hello? Python's include files are C++ safe. I even posted a complete compiler session to show that I'm not making that up. /F In theory, yeah. In practice, if his compiler was somehow not respecting that, then a quicker fix is to enclose the #include than to do individual prototypes. Admittedly that might obscure the problem rather than solve it. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Undefined calling conventions in Python.h
On Jul 23, 11:43 am, Jaco Naude [EMAIL PROTECTED] wrote:
What Visual C++ is doing is that it is looking for mangled names since
it does not know the DLL contains C functions. I've managed to work
around this by declaring the Python functions as follows before using
them in the C++ application side:
extern C
{
void Py_Initialize(void);
}
You should put the extern block around the #include python.h call
rather than individual functions, as surely the C calling convention
should apply to everything within.
It is probably more of a C++ question it turns out, but I would think
that someone in the Python group would use the Python DLL in C++.
More of a Visual C++ question specifically, since the __clrcall prefix
is a MS specific extension (http://msdn.microsoft.com/en-us/library/
ec7sfckb(VS.80).aspx). If you're not using managed code in your app,
disable it in the project/build options. If you are, then perhaps you
just need to specify that you're not with this DLL, though I've never
had to deal with anything like that myself.
--
Ben Sizer
--
http://mail.python.org/mailman/listinfo/python-list
Re: Best Python packages?
On Jul 19, 5:59 pm, Kay Schluehr [EMAIL PROTECTED] wrote: In the original post you asked for hidden gems and now it seems you just want to know about Madonna or Justin Timberlake. Not really, and I don't see why you'd say that. Maybe a look on this collection helps http://wiki.python.org/moin/UsefulModules Yeah, I saw that. I hoped some people might have some more, but perhaps not. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Best Python packages?
On Jul 16, 3:31 pm, Fredrik Lundh [EMAIL PROTECTED] wrote: Ben Sizer wrote: make my development a lot easier. Knowing what kind of development you do might help, of course. Some libraries are excellent in some contexts and suck badly in others... Sure. Mostly I'm just interested in what's out there though. In C++ you have Boost which everybody knows are a source of high quality libraries, covering a fairly wide set of applications. Obviously that's more low-level and less application specific, and the Python standard libs do pretty much everything that is in Boost, but it's that sort of peer-reviewed and widely-applicable list that I'd like to see. I (attempt to) use TurboGears for web development and that depends on a whole bunch of libraries - SQLObject, PyProtocols, RuleDispatch, SimpleJson, FormEncode, etc - and I would never have heard of these if TurboGears' exposure of its internals wasn't so common. Some of these are web-specific but some are not. And I'd never know to look for them specificially, because in many cases it wouldn't occur to me that they exist. (eg. Object-Relational Mappers like SQLObject may be obvious if you come from certain areas of IT, but I'd never heard of them before I started with TurboGears.) For what it's worth, my main areas of interest are gaming, multimedia, and web development. But I just like to hear about anything that people might use which makes their life a lot easier and which perhaps is not application specific - like ORMs or something similar. Looking at things that larger projects and distributions use can also be a good idea. For example, if you're doing scientific stuff, go directly to enthought.com. If you're doing web stuff, look at the libraries big Django applications use. Etc. Sadly, I know just as little about what major applications are out there as I do about what libraries are out there! -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Best Python packages?
Although the standard library in Python is great, there are undoubtedly some great packages available from 3rd parties, and I've encountered a few almost by accident. However, I don't know how a user would become aware of many of these. http://pypi.python.org/pypi/ presumably lists most of the decent ones, but there's a lot there and little indication as to quality or popularity - great if you know exactly what you need, but not so great for just browsing. I'd love to have some way of finding out what hidden gems are out there in the Python world which could make my development a lot easier. Any suggestions? -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Create list from string
On Jun 13, 3:15 pm, ericdaniel [EMAIL PROTECTED] wrote: Hi, I'm new to Python and I need to do the following: from this: s = 978654321 to this : [978, 654, 321] What are your criteria for splitting this string? Every 3 characters? If there isn't an even multiple of 3, which group should be shorter, the first, the last, or maybe some other? And do you even really need this as a string at all? Perhaps you really just wanted to format the output of an integer? (I think that may be done via the locale, but I am not sure.) Often it's best to specify why you want to do something, as when using a new language there is often a better way to achieve what you want than the first way that occurs to you. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Using an object-relational mapper to convert between databases
Hello, I'd like to be able to do the following: - open a connection to a MySQL or PostgreSQL database - read the schema and contents for one or more tables - create a new sqlite database file and open a connection to it - write out the previously-read tables and their contents to this new database I get the impression that the various object-relational mappers such as SQLAlchemy and SQLObject can make this easier, especially if using something like SQLAlchemy's autoloading capability to query the schema from the DB rather than me having to explicitly specify it. But then how easy is it to make a corresponding sqlite table and write the same objects to it? I don't know how practical this is with SQLAlchemy, or if a different ORM library would be more useful for this. And since objects tend to be closely related to the database they are mapped to, I don't know how easy it is to reflect them onto a second database. I'd just like some advice and pointers from anybody who's tried something similar to this or who knows the packages well enough to point me in the right direction. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
On Aug 10, 5:13 pm, Chris Mellon [EMAIL PROTECTED] wrote: On 8/10/07, Ben Sizer [EMAIL PROTECTED] wrote: On 10 Aug, 15:38, Ben Finney [EMAIL PROTECTED] wrote: Last I checked, multiple processes can run concurrently on multi-core systems. That's a well-established way of structuring a program. It is, however, almost always more complex and slower-performing. Plus, it's underdocumented. Most academic study of concurrent programming, while referring to the separately executing units as 'processes', almost always assume a shared memory space and the associated primitives that go along with that. This is simply not true. Firstly, there's a well defined difference between 'process' and a 'thread' and that is that processes have private memory spaces. Nobody says process when they mean threads of execution within a shared memory space and if they do they're wrong. I'm afraid that a lot of what students will be taught does exactly this, because the typical study of concurrency is in relation to contention for shared resources, whether that be memory, a file, a peripheral, a queue, etc. One example I have close to hand is 'Principles of Concurrent and Distributed Programming', which has no mention of the term 'thread'. It does have many examples of several processes accessing shared objects, which is typically the focus of most concurrent programming considerations. The idea that processes have memory space completely isolated from other processes is both relatively recent and not universal across all platforms. It also requires you to start treating memory as arbitrarily different from other resources which are typically shared. And no, most academic study isn't limited to shared memory spaces. In fact, almost every improvement in concurrency has been moving *away* from simple shared memory - the closest thing to it is transactional memory, which is like shared memory but with transactional semantics instead of simple sharing. I think I wasn't sufficiently clear; research may well be moving in that direction, but you can bet that the typical student with their computer science or software engineering degree will have been taught far more about how to use synchronisation primitives within a program than how to communicate between arbitrary processes. There's nothing undocumented about IPC. It's been around as a technique for decades. Message passing is as old as the hills. I didn't say undocumented, I said underdocumented. The typical programmer these days comes educated in at least how to use a mutex or semaphore, and will probably look for that capability in any language they use. They won't be thinking about creating an arbitrary message passing system and separating their project out into separate programs, even if that has been what UNIX programmers have chosen to do since 1969. There are a multitude of different ways to fit IPC into a system, but only a few approaches to threading, which also happen to coincide quite closely to how low-level OS functionality handles processes meaning you tend to get taught the latter. That's why it's useful for Python to have good support for it. Hardly. Sure, so you don't have to worry about contention over objects in memory, but it's still completely asynchronous, and there will still be a large degree of waiting for the other processes to respond, and you have to develop the protocols to communicate. Apart from convenient serialisation, Python doesn't exactly make IPC easy, unlike Java's RMI for example. There's nothing that Python does to make IPC hard, either. There's nothing in the standard library yet, but you may be interested in Pyro (http://pyro.sf.net) or Parallel Python (http://www.parallelpython.com/). It's not erlang, but it's not hard either. At least, it's not any harder than using threads and locks. Although Pyro is good in what it does, simple RPC alone doesn't solve most of the problems that typical threading usage does. IPC is useful for the idea of submitting jobs in the background but it doesn't fit so well to situations where there are parallel loops both acting on a shared resource. Say you have a main thread and a network reading thread - given a shared queue for the data, you can safely do this by adding just 5 lines of code: 2 locks, 2 unlocks, and a call to start the networking thread. Implementing that using RPC will be more complex, or less efficient, or probably both. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: The Future of Python Threading
On 10 Aug, 15:38, Ben Finney [EMAIL PROTECTED] wrote: Justin T. [EMAIL PROTECTED] writes: The truth is that the future (and present reality) of almost every form of computing is multi-core, and there currently is no effective way of dealing with concurrency. Your post seems to take threading as the *only* way to write code for multi-core systems, which certainly isn't so. Last I checked, multiple processes can run concurrently on multi-core systems. That's a well-established way of structuring a program. It is, however, almost always more complex and slower-performing. Plus, it's underdocumented. Most academic study of concurrent programming, while referring to the separately executing units as 'processes', almost always assume a shared memory space and the associated primitives that go along with that. We still worry about setting up threads, synchronization of message queues, synchronization of shared memory regions, dealing with asynchronous behaviors, and most importantly, how threaded an application should be. All of which is avoided by designing the program to operate as discrete processes communicating via well-defined IPC mechanisms. Hardly. Sure, so you don't have to worry about contention over objects in memory, but it's still completely asynchronous, and there will still be a large degree of waiting for the other processes to respond, and you have to develop the protocols to communicate. Apart from convenient serialisation, Python doesn't exactly make IPC easy, unlike Java's RMI for example. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: something similar to shutil.copytree that can overwrite?
On 22 Jun, 02:34, Justin Ezequiel [EMAIL PROTECTED] wrote: def copytree(src, dst, symlinks=False): Recursively copy a directory tree using copy2(). The destination directory must not already exist. XXX Consider this example code rather than the ultimate tool. names = os.listdir(src) if not os.path.exists(dst): os.makedirs(dst) # add check here That's the easy bit to fix; what about overwriting existing files instead of copying them? Do I have to explicitly check for them and delete them? It seems like there are several different copy functions in the module and it's not clear what each of them do. What's the difference between copy, copyfile, and copy2? Why do the docs imply that they overwrite existing files when copytree skips existing files? -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: something similar to shutil.copytree that can overwrite?
On 20 Jun, 11:40, Justin Ezequiel [EMAIL PROTECTED] wrote: On Jun 20, 5:30 pm, Ben Sizer [EMAIL PROTECTED] wrote: I need to copy directories from one place to another, but it needs to overwrite individual files and directories rather than just exiting if a destination file already exists. What version of Python do you have? Nothing in the source would make it exit if a target file exists. (Unless perhaps you have sym-links or the like.) I have 2.5, and I believe the behaviour I saw was that it exits if a directory already exists and it skips any files that already exist. It certainly wouldn't overwrite anything. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
something similar to shutil.copytree that can overwrite?
I need to copy directories from one place to another, but it needs to overwrite individual files and directories rather than just exiting if a destination file already exists. Previous suggestions have focused on looking at the source for copytree, but it has several places where exceptions can be raised, and the documentation for the shutil functions that copytree is implemented in terms of isn't exactly clear about which exceptions get raised and when. This makes duplicating a one-line shell operation a non-trivial task. Has anybody got any pre-written code that does what I'm looking for? -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows build of PostgreSQL library for 2.5
On 30 May, 16:20, Ben Sizer [EMAIL PROTECTED] wrote: On 30 May, 15:42, Frank Millman [EMAIL PROTECTED] wrote: On May 30, 4:15 pm,BenSizer[EMAIL PROTECTED] wrote: I've been looking for a Windows version of a library to interface to PostgreSQL, but can only find ones compiled under Python version 2.4. Is there a 2.5 build out there? Is this what you are looking for? http://stickpeople.com/projects/python/win-psycopg/ It may well be, thanks. On second thoughts, is there one anywhere without an extra multi- megabyte dependency? This seems to rely on the eGenix 'mx' library. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Windows build of PostgreSQL library for 2.5
I've been looking for a Windows version of a library to interface to PostgreSQL, but can only find ones compiled under Python version 2.4. Is there a 2.5 build out there? -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Windows build of PostgreSQL library for 2.5
On 30 May, 15:42, Frank Millman [EMAIL PROTECTED] wrote: On May 30, 4:15 pm, Ben Sizer [EMAIL PROTECTED] wrote: I've been looking for a Windows version of a library to interface to PostgreSQL, but can only find ones compiled under Python version 2.4. Is there a 2.5 build out there? Is this what you are looking for? http://stickpeople.com/projects/python/win-psycopg/ It may well be, thanks. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame and python 2.5
On Feb 10, 6:31 am, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Feb 9, 11:39?am, Ben Sizer [EMAIL PROTECTED] wrote: Hopefully in the future, some of those convoluted steps will be fixed, but that requires someone putting in the effort to do so. As is often the case with Python, and indeed many open source projects, the people who are knowledgeable enough to do such things usually don't need to do them, as their setup already works just fine. So you're saying the knowledgeable people's attitude is fuck everyone else as lomg as it's not MY problem? And you people complain about Microsoft. Am I one of those people? You don't exactly make it clear. But yes, there is a lot of well, it works for me going around. If you do that long enough, people stop complaining, so people wrongly assume there's no longer a problem. This is partly why Python has various warts on Windows and why the standard libraries are oddly biased, why configuring Linux almost always ends up involving hand- editing a .conf file, why the leading cross-platform multimedia library SDL still doesn't do hardware graphics acceleration a decade after such hardware became mainstream, and so on. However, the difference between the open-source people and Microsoft is the the open-source people aren't being paid by you for the use of their product, so they're not obligated in any way to help you. After all, they have already given freely and generously, and if they choose not to give more on top of that, it's really up to them. Yes, it's occasionally very frustrating to the rest of us, but that's life. The best I feel I can do is raise these things on occasion, on the off- chance that I manage to catch the attention of someone who is altruistic, knowledgeable, and who has some spare time on their hands! -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame and python 2.5
On Feb 10, 8:42 am, Steve Holden [EMAIL PROTECTED] wrote: Hendrik van Rooyen wrote: [EMAIL PROTECTED] wrote: Ben Sizer [EMAIL PROTECTED] wrote: Ben Python extensions written in C require recompilation for each new Ben version of Python, due to Python limitations. Can you propose a means to eliminate this limitation? Yes. - Instead of calling something, send it a message... I suppose you are proposing to use the ISO 1.333 generic message-passing interface for this? The one that doesn't actually call a function to pass a message? I'm assuming you're being facetious here..? Of course, functions get called at the ends of the message passing process, but those functions can stay the same across versions while the messages themselves change. The important part is reducing the binary interface between the two sides to a level where it's trivial to guarantee that part of the equation is safe. eg. Instead of having PySomeType_FromLong(long value) exposed to the API, you could have a PyAnyObject_FromLong(long value, char* object_type_name). That function can return NULL and set up an exception if it doesn't understand the object you asked for, so Python versions earlier than the one that implement the type you want will just raise an exception gracefully rather than not linking. The other issue comes with interfaces that are fragile by definition - eg. instead of returning a FILE* from Python to the extension, return the file descriptor and create the FILE* on the extension side with fdopen. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame and python 2.5
On Feb 9, 1:48 pm, siggi [EMAIL PROTECTED] wrote: @Ben Sizer Lucky I spotted this... As a Python (and programming ) newbie allow me a - certainly naive - question: What is this time consuming part of recompiling an extension, such as Pygame, from source code to Windows? Is it a matter of spare time to do the job? Or do you have to wait for some Windows modules that are necessary for compiling? The problem is something like this: - Python extensions written in C require recompilation for each new version of Python, due to Python limitations. - Recompiling such an extension requires you to have a C compiler set up on your local machine. - Windows doesn't come with a C compiler, so you have to download one. - The compiler that Python expects you to use (Visual Studio 2003) is no longer legally available. - The other compiler that you can use (MinGW) is requires a slightly convoluted set of steps in order to build an extension. Hopefully in the future, some of those convoluted steps will be fixed, but that requires someone putting in the effort to do so. As is often the case with Python, and indeed many open source projects, the people who are knowledgeable enough to do such things usually don't need to do them, as their setup already works just fine. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame and python 2.5
On Feb 9, 5:53 pm, [EMAIL PROTECTED] wrote: Ben Python extensions written in C require recompilation for each new Ben version of Python, due to Python limitations. Can you propose a means to eliminate this limitation? By putting an intermediate layer between the extensions and the language. I suppose this is essentially what ctypes does, except from the other direction. If someone could explain the limitation in detail, I expect ways could be found around it. After all, I don't know of any other systems that require you to recompile all the extensions when you upgrade the application. Winamp is one application that comes to mind which has kept plugins working across many upgrades. I doubt they're still compiling with Visual Studio 6. Perhaps it works because they have a more restrictive API that isn't passing non-primitive types across the DLL boundary. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame and python 2.5
On Feb 9, 9:01 pm, [EMAIL PROTECTED] wrote: Ben If someone could explain the limitation in detail, I expect ways Ben could be found around it. After all, I don't know of any other Ben systems that require you to recompile all the extensions when you Ben upgrade the application. Python used to work that way. You'd then silently get errors if the API changed between version A and version B and you neglected to recompile the extensions you compiled against version A. Maybe the Python extension API is mature enough now that it can be frozen, but I sort of doubt it. The only reason this is an issue is because the system is tightly bound on a binary level. Decouple that and the problem goes away. These 'silent' errors will all stem from a small number of specific things, each of which can be addressed. eg. PyFile_AsFile returns a FILE*, which is all well and good if both the extension's compiler and the language's compiler agree on what you get when you dereference that type, and probably not so good when they don't. The answer there is not to make assumptions about the structure of complex types across the boundary. The same may well go for the multitude of macros that make assumptions about the structure of a PyObject. It's not really much to do with the maturity, since functions don't seem to be getting regularly removed from the API. It's more the choices made about how to implement it. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: when will python 2.5 take in mainstream?
On Feb 5, 4:15 pm, Jean-Paul Calderone [EMAIL PROTECTED] wrote: It's very easy to maintain compatibility in the C API. I'm much more interested in compatibility at the Python layer, which is changed incompatibly much, much more frequently than is the C layer. Really? In all cases I've found, pure-Python extensions written for 2.4 work with 2.5. The same was true for 2.3 to 2.4 as well. And even if I found one that didn't, it's highly likely I could fix it myself. The same doesn't apply to any C compiled extensions. Updating Python breaks these, every time, and users typically have to wait months for the library developer to compile a new version, every time. Or maybe they can wade through the morass of how do I compile this library on Windows threads here. Perhaps the C API remains the same but the real issue is the binary API between extensions and Python changes every couple of years or so. That's why I run 2.4 anywhere that needs extensions. It would be great if someone could invest some time in trying to fix this problem. I don't think I know of any other languages that require recompilation of libraries for every minor version increase. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: when will python 2.5 take in mainstream?
On Feb 6, 3:35 pm, [EMAIL PROTECTED] (Aahz) wrote: Ben Sizer [EMAIL PROTECTED] wrote: It would be great if someone could invest some time in trying to fix this problem. I don't think I know of any other languages that require recompilation of libraries for every minor version increase. How do you define minor version increase? If you look at the progression from 2.0 through 2.5, it's pretty clear that each version doesn't particularly fit minor version increase even though each one only increments by 0.1. I can't say I agree with that. In terms of naming, it's a minor release because the 'major' release number has stayed at 2. In terms of time, it's a minor release because it's only happening about once every 18 months or so - a short period in computer language terms. In terms of semantics, I'd argue they are minor releases because generally the changes are just minor additions rather than large revisions; I don't see much in the way of significant language alterations for 2.5 apart from arguably 'unified try/except/finally', nor in 2.4. I don't count addition of new types or modules as 'major'. The language itself is fairly stable; it's just the way that it links to extensions which is pretty fragile. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Python does not play well with others
On Jan 24, 1:50 am, John Nagle [EMAIL PROTECTED] wrote: In the Perl, Java, PHP, and C/C++ worlds, the equivalent functions just work. That's because, in those worlds, either the development team for the language or the development team for the subsystem takes responsibility for making them work. Only Python doesn't do that. I have much sympathy for your position. I think the problem is that Python is quite capable in many areas, such that the people in the community with the expertise to extend the language and libraries, are usually the ones who've been happily using the polished features for years and have found they need nothing more. And the ones who need those features probably got bored of waiting for progress long ago. You get the responses you do from years of natural selection in the community. I think that is why many of the SIGs are stagnant, why the standard library has so much fluff yet still lacks in key areas such as multimedia and web development, etc. People can say, if you want it done, why aren't you doing it?, and is a fair question, but it doesn't alter the fact of Python's deficiencies in certain areas when compared with other languages. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: pygame and python 2.5
siggi wrote: when I rtry to install pygame (pygame-1.7.1release.win32-py2.4.exe, the most ciurrent version I found) it requires Python 2.4! Will I really have to uninstall my Python 2.5 and install the old Python 2.4 in order to use pygame? For now, yes. This is a long-standing problem with Python really, requiring extensions to always be recompiled for newer versions. I usually have to wait about 6 months to a year after any new release before I can actually install it, due to the extension lag. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: How to modify object attribute by python C API
Huayang Xia wrote: PyObject* py_obj_attr1 = PyObject_GetAttrString(obj, attr1); PyObject_SetAttrString(py_obj_attr1, attr2, PyString_FromString(a)); Py_DECREF(py_obj_attr1); The object py_obj_attr1 is said to be a New reference. It's confusing, does it refer to the same object as obj.attr1 in python's term? Yes, it refers to the same object. Each object can have many references, and is deleted when all the references are gone. The new reference in this case means that Python has taken note that there's a new use of that object - your C code. It means it won't delete that object, even if no more Python code refers to it, because it knows your C code holds a reference to it. Therefore, when your C code no longer needs to access the object, you call Py_DECREF. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a good example on instantiating, calling, using, an API from Python on Windows?
kj7ny wrote: To be more exact, I am trying to use Python to talk to a Livelink system (http://www.opentext.com/) through their LAPI interface (.dll's, I think). I'll see if I can generate a more intelligent answer to your question, but for now, I'm far enough in the dark that this is as good as I can get. API is a vague term referring to the interface to an application, which could take one of many forms. The form it takes dictates the method you need to use here. If indeed it is via DLLs, then the ctypes module may help. Otherwise, you need to find out precisely what form the API takes. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: creating simple Python scripting interfaces via C++
Ok, my first attempt at this creates proxy objects in Python, and
stores a pointer to the C++ instance in the Python object. I cast that
pointer to an int and pass it as a single parameter to the object's
__init__ function.
static PyObject* Actor_init(PyObject *self, PyObject *args)
{
PyObject* selfParam;
PyObject* ptrValue;
if (!PyArg_ParseTuple(args, OO, selfParam, ptrValue))
return NULL;
PyObject_SetAttrString(selfParam, _cpp_ptr, ptrValue);
Py_INCREF(Py_None);
return Py_None;
}
I have no idea why self is always NULL, when I'm calling the functions
as methods of an object. Any ideas why this is the case? For what it's
worth I attach each method via the PyMethodDef - PyCFunction_New -
PyMethod_New - PyDict_SetItemString(classDict) route.
To get data back from the C++ object to Python, I extract that value
and cast it back to the appropriate pointer type.
static PyObject* Actor_showName(PyObject *self, PyObject *args)
{
PyObject* selfParam;
if (!PyArg_ParseTuple(args, O, selfParam))
return NULL;
PyObject* cppPtr = PyObject_GetAttrString(selfParam, _cpp_ptr);
long cppPtrVal = PyInt_AsLong(cppPtr);
Actor* pActor = reinterpret_castActor*(cppPtrVal);
// Delegate to the C++ object
pActor-ShowName();
Py_INCREF(Py_None);
return Py_None;
}
I've omitted some error checking, but this is the way I'm going for
now. Are there any glaring errors I've made (apart from perhaps
assuming sizeof(pointer) = sizeof(long), that is)? And is there
anywhere else more appropriate that I should be asking this question,
given the lack of responses to this and my other embedding topic so
far?
--
Ben Sizer
--
http://mail.python.org/mailman/listinfo/python-list
Ref count oddness with embedded Python... memory leak?
Here's my test-case:
#include python.h
int main(int argc, char *argv[])
{
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
Py_Initialize(); Py_Finalize();
return 1;
}
Here's my output, with Python 2.5 built in debug mode on WinXP, no
modifications:
[7438 refs]
[7499 refs]
[7550 refs]
[7601 refs]
[7652 refs]
Is this normal? It doesn't look very promising to me.
--
Ben Sizer
--
http://mail.python.org/mailman/listinfo/python-list
PyCFunction_New requires a pointer to a static PyMethodDef?
In following the example given at http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/54352, I find that if I instead try to create PyMethodDef instances on the stack and create methods that way, rather than providing pointers to a static array of them, executing the method later raises an exception from PyCFunction_Call. Is it required that the PyMethodDef persists throughout the execution of the Python program? If so, why isn't the information just copied instead? I was hoping to just create a temporary PyMethodDef on the stack purely for the duration of creating the method. (Google doesn't find any instance of PyCFunction_Call on docs.python.org. This might explain the Cookbook's comment that one hardly ever sees Python class objects built in C extensions!) -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
creating simple Python scripting interfaces via C++
I have Python embedded in a C++ application (yes, yes, I know, I'd prefer it the other way around too) and essentially need to expose some read-only values and functions to Python so it can be used to script the host application. When scripting a similar app in TCL, it's possible to associate each command with some client data, so that the command can be written in the script as a free function but it actually executes in some sort of context, accessed via the client data pointer in C++. In Python, there doesn't appear to be this mechanism, so I think I'd have to inject the context in another way, either as some sort of module-level global, or as an object, implementing the previously free functions as methods. Is this correct? If so, what is the simplest way of implementing the former method - inserting the pointer to the required context as a long (via PyDict_SetItemString(globals, context, PyInt_FromLong(pointer)) or similar) and then converting it back in the bound function? And for the latter method, is it possible to make an arbitrary object and then attach methods and the context data? Or will I have to create a whole Python class for this (as in http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/54352)? I'm not interested in wrapping whole C++ objects at this stage, and libraries like Boost::Python aren't currently an option. I just need a few pointers on doing it the low-level way for now. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
Chris Lambacher wrote: On Tue, Jan 02, 2007 at 09:08:41AM -0800, Ben Sizer wrote: Chris Lambacher wrote: The python part of the 'python setup.py install' idiom needs to be omitted on Windows, but that does not mean that the solution is to automatically add it to PATH. Firstly, that solution only works for actual Python scripts; it doesn't solve the utility scripts that are often installed to the /scripts directory. It's a shame that many responses on this thread don't address that half of the issue. Am I the only person who installs packages that add scripts (not all of which are Python ones)? Nope, but just adding the scripts directory to the PATH does not solve the problem. You also need to either create an executable launcher (.bat or .exe) for the script or mess with environment variables to tell Windows to treat .py files a executable. This issue is solved in Unix by toggling the executable bit on the file in the file system. Many of the scripts that are installed come as batch files or other executables. They just assume the directory is in your PATH already, which they aren't, until you set it that way. Secondly, it's still a significant difference from the Unix-based installs. Its not really. Unix installs default to being installed to the prefix /usr, which just happens to put the executable in your path. It does not modify the user's path in any way. I was talking more in terms of the end-user experience. I don't know of any binary package on the distros I've used (Mandriva/Mandrake, Fedora Core, and Kubuntu) that install Python without it going into your path, nor of any that allow you to avoid that while using their standard package managers. It may be incidental in some meaning of the term, but it's expected and apparently intended. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
Martin v. Löwis wrote: Ben Sizer schrieb: Firstly, that solution only works for actual Python scripts; it doesn't solve the utility scripts that are often installed to the /scripts directory. Those packages should install .bat files into /scripts on Windows. Which still need their location to be be fully qualified, due to /scripts not being in the path. This is not my experience with Linux installations of the same packages. Please submit a patch that does so, then. Make sure you add user interface to make it an option. These things are *not* easy, and claiming that they are is misleading. I will look into it. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
robert wrote: Ben Sizer wrote: My opinion is that this is not as big a problem as some may feel that it is. Unlike Unix systems, the PATH variable is rarely used. It is a big problem. It is not less than the majority of Python users (at least those who do things on the command line) who deal with multiple Python versions. So you think most Python users have more than one version of Python installed? I disagree - but even if it is true, how come this isn't a big problem on Unix? Can you name a single distribution that doesn't install Python to the path? This would create funny PATH variables - almost a psychic behavior with history. It is quite trivial to see if Python is already on the path, and act differently based on that. Windows is at all less a multi user system. I don't even know a case where two (Python) Programmers use _one_ box and then also want separate Python's - just know home mates (parasites) who occasionally share the web browser or so... So... that's another reason why there's rarely a problem in setting that PATH variable. Linking also a default python.exe into the system32 upon a (non-default) checkbox mark in the installer should be simple, clear and do everything what 99.9% want - and most compatible to *nix. No, it doesn't : the /scripts directory is also important for many Python packages and that isn't addressed by shifting python.exe into system32. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
Tom Plunket wrote: vbgunz wrote: Some if not most python documentation assumes Python is on the path... Really? I must live in different places in the docs, but I can't recall encountering any such documentation. I have posted a few examples above: Installing Python Modules (http://python.org/doc/2.2.3/inst/inst.html) is a key example. 3rd party packages often expect you to type python setup.py install. Setuptools/easyinstall will give you an 'easy_install' script, but then notes that you have to manually fix up the PATH yourself. Users who want it in their paths are certainly capable of putting it there. By that logic, users who want Python are probably capable of unzipping the archive and putting it somewhere semi-suitable. So why provide an installer? If you're going to provide an installer, it should do the whole job, and get Python in a state that is reasonably consistent across all platforms, where practical. Adding to the PATH variable isn't impractical. I am in the camp that detests apps that automatically install tons of crap everywhere without prompts. Why use hyperbole here? Is 13 or 14 bytes optionally added to a single environment variable tons of crap? And did anybody insist that the installer would have no prompts? Certainly, though, the suggestion that one pane in the installer offer to put it in the path would leave the default as it is today (don't edit PATH), though, right? Doesn't make a whole lot of sense to add a new option and default it to something completely different from the old behavior, does it? I have no problem with something being configurable, but I do have a problem with Windows users being forced to jump through unnecessary hoops that Unix and MacOS users don't have to endure. And I think the default should be to edit the PATH and allow you to explicitly disallow this: changing from the current behaviour is the right thing to do because the current behaviour is wrong, in terms of cross-platform compatibility and usability. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
Gabriel Genellina wrote: At Saturday 30/12/2006 21:55, Ben Sizer wrote: python setup.py install On Unix, you'd run this command from a shell prompt; on Windows, you have to open a command prompt window (``DOS box'') and do it there; Pretty much none of the instructions in that part of the docs will work without you altering your path beforehand. Python's cross-platform nature means people rightly expect the same instructions to work on Linux and Windows from a standard installation. Right now, they don't. Notice that there is NO need to alter the system path. You just have to tell Windows where python.exe resides; there is a per-application path located at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths. In order to launch Python just writing python at the command prompt, the installer should -instead of playing with the system path- create a new key below App Paths, named python.exe, and set its default value to the full path of the installed python executable. See http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_perceived_types.asp From what I can tell, that is solely for file associations. If so, it will work if you type setup.py install but not if you type python setup.py install. For instance, I have an entry for Firefox in that part of the registry, but if you try executing firefox at the command line, it fails. It also doesn't solve the issue of utility scripts being added to Python's scripts directory. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
Chris Lambacher wrote: On Sat, Dec 30, 2006 at 04:55:09PM -0800, Ben Sizer wrote: Yet many scripts and applications require parameters, or to be executed from a certain directory. For example, setup.py. Or the various turbogears scripts. Or easy_install. Martin's point was that if you need to pass arguments, you can call the script from the command line like so: setup.py install The python part of the 'python setup.py install' idiom needs to be omitted on Windows, but that does not mean that the solution is to automatically add it to PATH. Firstly, that solution only works for actual Python scripts; it doesn't solve the utility scripts that are often installed to the /scripts directory. It's a shame that many responses on this thread don't address that half of the issue. Am I the only person who installs packages that add scripts (not all of which are Python ones)? Secondly, it's still a significant difference from the Unix-based installs. You're right, the solution doesn't automatically have to be adding it to the PATH - but I'm yet to see a good argument for choosing not to, apart from I don't like it when apps do that. The documentation is misleading... time for a but report: http://sourceforge.net/tracker/index.php?func=detailaid=1626300group_id=5470atid=105470 Fixing the docs is better than nothing, but I believe fixing the install to encourage uniform usage across all platforms is preferable, and that in this regard the documentation shows how it 'should' work. There appears to be a freely-available binary at this address that may suffice: http://legroom.net/modules.php?op=modloadname=Open_Sourcefile=indexpage=softwareapp=modpath Unfortunately the Python installer is not an InnoSetup installer. The page I linked to is a bit misleading but there is an executable on that page. All you then have to do is invoke it with the relevant parameter. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
Martin v. Löwis wrote: Ben Sizer schrieb: I've installed several different versions of Python across several different versions of MS Windows, and not a single time was the Python directory or the Scripts subdirectory added to the PATH environment variable. Every time, I've had to go through and add this by hand, to have something resembling a usable Python installation. No such problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or Kubuntu. So why is the Windows install half-crippled by default? For several reasons: 1. Python can be used just fine without being on PATH. Python scripts run fine both when double-clicked and when invoked in the command line, and if you want to use an interactive interpreter, you can find it readily on the Start menu. Yet many scripts and applications require parameters, or to be executed from a certain directory. For example, setup.py. Or the various turbogears scripts. Or easy_install. 2. Many windows users (including myself) dislike setup routines that manipulate PATH. My opinion is that this is not as big a problem as some may feel that it is. Unlike Unix systems, the PATH variable is rarely used. Most applications are launched via the Start Menu, which uses absolute paths, or via file associations, also done via absolute paths. The chance of a naming collision only really arises when you start using the command line, which most people don't do. However, among those who will use the command line, are some people new to Python, who will come across instructions like this: http://docs.python.org/inst/standard-install.html As described in section 1.2, building and installing a module distribution using the Distutils is usually one simple command: python setup.py install On Unix, you'd run this command from a shell prompt; on Windows, you have to open a command prompt window (``DOS box'') and do it there; Pretty much none of the instructions in that part of the docs will work without you altering your path beforehand. Python's cross-platform nature means people rightly expect the same instructions to work on Linux and Windows from a standard installation. Right now, they don't. if Python is to be found in PATH, it should rather be installed to a directory that is known to live on PATH (or where CreateProcess searches, anyway, such as system32). So if the installer had such a feature, it should be optional, and it should default to off. It's a lot more anti-social to install to system32 than to modify the PATH variable. How easy is it to temporarily undo an installation to a system directory like that? What if you still want Python in your path but with less precedence than some other user directory? 3. Most importantly: it is difficult to implement, and nobody has contributed code to make it work. There appears to be a freely-available binary at this address that may suffice: http://legroom.net/modules.php?op=modloadname=Open_Sourcefile=indexpage=softwareapp=modpath -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
[EMAIL PROTECTED] wrote: I don't seem to have any problem running python programs regardless of where they are. My platform is windows xp and I have run both 2.4 and 2.5 more details about what version of windows you are running might be helpfull I don't think the Windows version is relevant. I did point out that this happens across different incarnations of Windows (98SE and XP the 2 I have on hand to test), and that the problem wasn't specifically about running python programs. Basically if you go to a command prompt and type python, it won't do anything on a plain Python install on Windows. Try it on Linux, and probably Mac too, and it'll do something useful. Similarly, if you install a Python package that adds to the scripts directory, you can typically expect to run those scripts from the command line without having to use the full path - not on Windows. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does Python never add itself to the Windows path?
Ross Ridge wrote: Ben Sizer wrote: I've installed several different versions of Python across several different versions of MS Windows, and not a single time was the Python directory or the Scripts subdirectory added to the PATH environment variable. Personally, I hate Windows applications that add themselves to the PATH. So much crap gets put in there that I don't even use the default system PATH and just set my own explicitly. Personally I hate programs that ask to be installed to the root folder of my hard drive, but Python suggests that as a default too. ;) In an ideal world, Python should operate pretty much the same across all platforms. Unfortunately, as it stands, you need to have different instructions for running things on Windows. eg. The standard python setup.py install invocation isn't going to do a damn thing unless you've fixed up the path beforehand. The same goes for python ez_setup.py, another common favourite. The scripts directory is important too: TurboGears installs a tg-admin script which you're supposed to run from your project's directory: which on Windows means you need to type something like c:\python24\scripts\tg-admin each time. Half of the people who develop on Mac and Linux don't realise or acknowledge this. and so the instructions for using their packages don't work for the average person new to Python who probably just ran the Windows installer program and thought that would suffice. Linux distributions normally install themselves somewhere that's normally in the path already. I suppose you can do the same thing on Windows if you want, just choose to install Python into directory that's already in your path. Though installing to something like C:\WINDOWS\SYSTEM32 is probably not a good idea. The Windows way is typically to install things in Program Files and then point things there as necessary. Installing it the Linux way would just cause a different set of problems. Adding it to the PATH variable is not going to cause problems for the vast majority of people, and it's far easier to edit up the PATH to remove an entry you don't want, than to move an installed program from one place to another. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Why does Python never add itself to the Windows path?
I've installed several different versions of Python across several different versions of MS Windows, and not a single time was the Python directory or the Scripts subdirectory added to the PATH environment variable. Every time, I've had to go through and add this by hand, to have something resembling a usable Python installation. No such problems on Linux, whether it be Mandrake/Mandriva, Fedora Core, or Kubuntu. So why is the Windows install half-crippled by default? I just rediscovered this today when trying to run one of the Turbogears scripts, but this has puzzled me for years now. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python scripts in Windows Explorer
MC wrote: I use this little batch: @echo off cd \dev\python viewarg.py %* I try that (with viewarg.py renamed, obviously), and get this error: 'defines.py' is not recognized as an internal or external command, operable program or batch file. defines.py is in the same directory as the batch file, but cannot be executed like this. Double-clicking on it works, as expected. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python scripts in Windows Explorer
Gabriel Genellina wrote: At Friday 20/10/2006 12:20, Ben Sizer wrote: I'd like to be able to drag a file onto a Python script in Windows Explorer, or send that file to the script via the Send To context-menu option, so I can then process that file via sys.argc. Unfortunately, I can't drag items onto the Python script, because Windows doesn't recognise that the script is executable (unless I double-click it, upon which it runs as usual, without the command line parameter of course) Create a shortcut and drop the file over it. Doesn't work; the mouse cursor changes to the not permitted sign and when you release the mouse, nothing happens. and won't set it as a drop target. And it won't even appear in the Send To menu after the usual steps are taken to get it there. Same here: put a shortcut to the script on your SendTo folder (wherever it resides) That is what I meant by 'the usual steps'. :) It doesn't work. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Using Python scripts in Windows Explorer
I'd like to be able to drag a file onto a Python script in Windows Explorer, or send that file to the script via the Send To context-menu option, so I can then process that file via sys.argc. Unfortunately, I can't drag items onto the Python script, because Windows doesn't recognise that the script is executable (unless I double-click it, upon which it runs as usual, without the command line parameter of course) and won't set it as a drop target. And it won't even appear in the Send To menu after the usual steps are taken to get it there. I then tried to wrap it in a batch file, but encounter a problem, where that batch file is able to execute the Python file if I double-click the batch file, but if I drag a file onto it it says it can no longer find the Python script. Are there any simple and workable solutions for this sort of thing? -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Can recursive descent parser handle Python grammar?
[EMAIL PROTECTED] wrote: Ben Sizer wrote: [EMAIL PROTECTED] wrote: I'm a compiler newbie and was curious if Python's language/grammar can be handled by a recursive descent parser. I believe a recursive descent parser can handle any grammar; it just depends on how pure you want it to be. -- Ben Sizer Thanks! What do you mean by 'pure'? By 'pure' I mean entirely recursive and not iterative. Implementation becomes easier if you're not writing a purely recursive parsing program, and it makes it more practical to implement an arbitrary amount of 'read-ahead'. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Can recursive descent parser handle Python grammar?
[EMAIL PROTECTED] wrote: I'm a compiler newbie and was curious if Python's language/grammar can be handled by a recursive descent parser. I believe a recursive descent parser can handle any grammar; it just depends on how pure you want it to be. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: for: else: - any practical uses for the else clause?
[EMAIL PROTECTED] wrote: metaperl I'm wondering if anyone has ever found a practical use for the metaperl else branch? Yeah, I use it from time to time: for foo in bar: if foo matches some condition: print sail to tahiti! break else: print abandon ship! As a C++ programmer (which I'm sure undermines my argument before you've even read it...), this feels 'backwards' to me. Although I am no purist, the 'else' typically implies failure of a previous explicit condition, yet in this case, it's executed by default, when the previous clause was successfully executed. It would seem more natural if the else clause was triggered by 'bar' being empty, or even if the loop was explicitly broken out of, though I'm sure that would make the construct much less useful. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: RELEASED Python 2.5 (FINAL)
Anthony Baxter wrote: It's been nearly 20 months since the last major release of Python (2.4), and 5 months since the first alpha release of this cycle, so I'm absolutely thrilled to be able to say: On behalf of the Python development team and the Python community, I'm happy to announce the FINAL release of Python 2.5. Any chance the docs links could be fixed? The link on the front page still goes to 2.4.3 on docs.python.org, and the link from /download/releases/2.5/ goes to 2.6a0. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Request for elucidation: enhanced generators
A simple question - can anybody give a short example of how these work and what they are good for? I've read PEP 342 and the associated bit in the What's New section and it's still all Greek to me. The latter seems to focus on how to do it, rather than why you'd do it, so it doesn't aid the understanding too much. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Request for elucidation: enhanced generators
Steve Holden wrote: Ben Sizer wrote: A simple question - can anybody give a short example of how these work and what they are good for? I've read PEP 342 and the associated bit in the What's New section and it's still all Greek to me. The latter seems to focus on how to do it, rather than why you'd do it, so it doesn't aid the understanding too much. Unti 2.5 the yield keyword could only be used to produce a value from a generator - it introduced a statement. Now the yield keyword can be used as an expression inside a generator, allowing you to send values into the generator by calling its .send() method. If you have no use case for this you are, as always, perfectly free to ignore it, as the majority of Python users may well choose to do. Your existing generators should continue to work. But do you have an example of such a use case? That's what I'm missing here. Without ever having used proper coroutines elsewhere, I have no real way to appreciate their benefits without a good example. I don't think it's feasible to just ignore any new feature, as sooner or later you're going to encounter someone else's code that relies upon it. Hence why I'd rather not see all sorts of 'optional' extras added later (like type declarations and so on). -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
Bryan Olson wrote: Ben Sizer wrote: It's not a crackpot theory. It's a completely reasonable theory. SQL is based on relational algebra, which provides a mathematical set of operators for grouping data that is stored in separate sets. That data is selected and projected according to its value, and nothing else. The concept of it having a 'type' has been overlaid on top of this, presumably to facilitate efficient implementation, which tends to require fixed-width rows (and hence columns). It's not necessary in any sense, and it's reasonable to argue that if it was trivial to implement variable width columns as efficiently as fixed width columns, that explicit data types might never have needed to exist. The mathematical definition of the relational model includes that data values are drawn from specific sets. Well, I did say relational algebra, which from what I understand predates the official 'relational model'. Implementing variable width columns has nothing to do with it. On a practical level, it has lots to do with it! Here's the reference: 1.3. A Relational View of Data The term relation is used here in its accepted mathematical sense. Given sets S1, S2, ···, Sn, (not necessarily distinct), R is a relation on these n sets if it is a set of n-tuples each of which has its first element from S1, its second element from S2, and so on [1]. We shall refer to Sj as the jth domain of R. Does it specify anywhere that sets S1...Sn cannot each be the universal set? To put it another way - although the spec implies the existence of limited set domains, and data types enforce limited domains, I don't think a requirement to allow limited domains is a requirement for static data types. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: SQLwaterheadretard3 (Was: Is it just me, or is Sqlite3 goofy?)
[EMAIL PROTECTED] wrote: Bruno Desthuilliers wrote: SQLite never pretended to be a full-blown RDBMS - just a lightweight simple embedded database as SQL-compliant as possible. Ah, *you* haven't read the documentation either! as SQL-compliant as possible? ROTFLMAO! No need to be rude really. In this context as SQL-compliant as possible means, as SQL-compliant as it is possible to be within the project's restrictions, which presumably refer to code size and speed. It's a reasonable trade-off. ** * The authors argue that static typing is a bug in the * * SQL specification that SQLite has fixed in a backwards * * compatible way.* ** /quote Fixed? Up until now, I didn't think it was possible for crackpot theories to be implemented in computer science. This is absolutely the craziest thing I've ever heard. It's not a crackpot theory. It's a completely reasonable theory. SQL is based on relational algebra, which provides a mathematical set of operators for grouping data that is stored in separate sets. That data is selected and projected according to its value, and nothing else. The concept of it having a 'type' has been overlaid on top of this, presumably to facilitate efficient implementation, which tends to require fixed-width rows (and hence columns). It's not necessary in any sense, and it's reasonable to argue that if it was trivial to implement variable width columns as efficiently as fixed width columns, that explicit data types might never have needed to exist. So much for If switching to a larger database such as PostgreSQL or Oracle is later necessary, the switch should be relatively easy. If you rely too much on a language-enforced data type rather than the values of the underlying data, perhaps Python is not for you! Personally I've migrated from SQLite to MySQL a couple of times (on small projects, granted) and not found it to be a problem at all. Fixing the documentation is now becoming an enormous task. I don't think so... it doesn't take much to say that the module implements a subset of SQL but stores ignores data types. What are the chances that anything I send in as a bug report will simply be ignored? Kind of like the Emporer's New Clothes, eh? It would be an admission of ignorance and stupidity on the part of the Python Development Team, wouldn't it? Why get so bitter over this? I agree the docs need fixing but you make it sound like this was a deliberate attempt to make you waste your time. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Javadoc style python manual?
[EMAIL PROTECTED] wrote: I'm new to python and I'm from the java world. Though I love to learn python, I'm not very comfortable with the python documentation. Because when i read jdk doc, i can see the class hierachy, class member, class methods etc in html docs. It's very easy for me to understand the Java language. But in python, i find it kind of inconvient. My advice is to get used to it... the Python docs are not arranged in the hierarchical fashion because there isn't any real hierarchy to speak of. Python does not rely heavily on inheritance like Java does. Instead, it is used in just a few places, more like the C++ standard library than the Java library. I agree that the Python docs aren't quite as effective as reference material due to the lack of simple function and method lists though. I don't know if there's a solution to that anywhere. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Javadoc style python manual?
Michele Simionato wrote: Ben Sizer wrote: I agree that the Python docs aren't quite as effective as reference material due to the lack of simple function and method lists though. http://docs.python.org/lib/modindex.html, pydoc and ipython are more than enough for me. modindex is comprehensive but too 'flat'. Sometimes you want to see all of one object's methods and properties listed together. I was unaware of pydoc until this thread; its existence seems to be buried, somewhat. Looking at pydoc.org (assuming that is a good example of it in use), it looks more like what the original poster and I might want, but sadly it's still very inconsistent, with many things undescribed. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: getting quick arp request
kondal wrote: Something is limiting the TCP/IP connections from my python program at 10 maximum at the same time. I do not see this limit in my code. I did not bumped over the 4226 error. = Where does this limit come from. = How can I overcome it. You can just edit it by creating a new key in the registry. HKEY_LOCAL_MACHINE - SYSTEM - CurrentControlSet - Services -Tcpip - Parameters Create a DWORD key named TcpNumConnections and set the value to 00fe or 16777214. That's the maximum number of connections, which is unlikely to be what he's running up against. It's more likely the original poster is hitting the max number of half-open connections, which is limited to 10 (exactly the figure he's seeing). Perhaps the 4226 event just isn't appearing for some reason. I've had that myself sometimes. There is an unofficial OS-level patch for this behaviour at this address: http://www.lvllord.de/?lang=enurl=downloads No idea if it works or if it's safe, but many people use it. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: getting quick arp request
seb wrote: I am not fully confident to apply the patch from http://www.lvllord.de/?lang=enurl=downloads .on computers other than mine. Fully understandable. Is there another solution ? I believe it is possible to overwrite the .dll that SP2 gives you with the older one. Obviously you lose any other bug fixes or enhancements Microsoft put in there. I don't remember the actual file in question, sorry. And I don't suppose this is much more acceptable than the previous 'solution'. Still without the above patch on windows, the software angry ip scan for example managed to output a lot of more socket connection. How is it possible ? It sends an ICMP ping to each address first, meaning it doesn't have to waste time on trying a TCP connection to a host that doesn't respond. This leads to fewer half-open connections. It may also be that it implements part of its own TCP/IP stack, and accessing the ethernet card directly, but I don't know how practical that is for you. Ethereal and nmap appear to do this; you might want to browse their open source code, and/or ask on their mailing lists or forums. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Higher-level OpenGL modules
[EMAIL PROTECTED] wrote: http://pyopengl.sourceforge.net/ I wouldn't begin to tell you how to install this.. Looks like russian roulette with virus since the .dll's are not available and are not linked from the site but are available from lots of places in the google search. I think you're very mistaken... it's a little over-complex, but everything you need is up there, on the installation and download pages, and the only other .dlls you need are the OpenGL ones which the original poster will already have. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: getting quick arp request
seb wrote: I need to write a scanner that test all the IP adresses that repond on a given port. ... I am using winXP pro on a 2GHZ P4 and 512 Mo. If you have XP Service Pack 2, it cripples port-scanning as part of a 'security' fix. Broadly speaking, it limits the rate at which you can make connections at the OS level; this will show up as event 4226 in the Event Viewer if it affects you. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it just me, or is Sqlite3 goofy?
Bruno Desthuilliers wrote: [EMAIL PROTECTED] wrote: I don't mind living with it as long as it's documented. It is. In SQLite manual. Or do you hope the Python manual to also fully document PostgreSQL, MySQL, Oracle, Apache, Posix, Win32 etc ? With those other applications, you have a separate download. With sqlite, you don't, on Windows at least. Surely all the 'included batteries' should have local documentation, especially with the type conversions. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: raw audio in windows
Jay wrote: So, are you saying this would be possible to do with the PlaySound function? Fredrik is often terse. ;) I think what he's saying is that when I said you could pass a .wav file to an external application, he showed that you could pass it to a Python module instead. I think you still need to get it into .wav format first, though this can apparently be in memory rather than on disk. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: raw audio in windows
Putty wrote: Hi. I've written a small python script that was primarily meant for use in a unix-compatible environment. It writes a bunch of raw audio to a file and then sends the file to /dev/audio and the system plays the audio. Very simple. Is there a simple way I could edit the script (which just uses the system call to do this) to run under windows? This is the code that would have to change: os.system(cat audioBuf /dev/audio) Not really. You'll have to convert it to .wav and then pass it to a helper app. http://www.microsoft.com/technet/scriptcenter/resources/qanda/nov04/hey1103.mspx -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Timeline for Python?
Sebastian Bassi wrote: So, if the book is published in October 2007, should feature Python 3 or Python 2.5? I did read http://www.python.org/dev/peps/pep-3000/ but I still not sure about timeline. I get the impression that Python 3 will not be around Any Time Soon and certainly not in just 12 or 13 months. The PEP does suggest that it isn't likely to be around any time before 2008 at the earliest. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Pygame, mouse events and threads
[EMAIL PROTECTED] wrote: Ben Sizer wrote: [EMAIL PROTECTED] wrote: When I put the content of the run and input functions in the main thread, it's working, why not in the thread? Because event handling needs to be done in the main thread. So does rendering. This is a limitation of the underlying system. As a general rule, try to keep all your PyGame functions in the main thread and push your other processing into background threads, if you really need them. Well, that is a limitation... And is it something that will be fixed or something that is inherent to pygame and not fixable? It's inherent to SDL (the library underpinning PyGame), because it's apparently inherent to some of the platforms it runs on. Rendering and event handling is typically tied closely to the notion of a window and that in turn may well be coupled tightly to a single process or thread. As Diez said however, this is not generally a big problem. Most games are typically single-threaded anyway. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Python and STL efficiency
Neil Cerutti wrote: On 2006-08-24, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It will run a lot faster if it doesn't have to keep resizing the array. I don't see why it should run a lot faster that way. Appending elements to a vector with push_back takes amortized constant time. In the example above, preallocating 4 strings saves (probably) math.log(4, 2) reallocations of the vector's storage along with the consequent copy-construction and destruction of some fixed number of strings. Most of those reallocations take place while the vector is still proportionally quite small. Math.log(4, 2) is not a small number when talking about a relatively expensive operation such as memory allocation and deallocation. And the superfluous copying amounts to probably an extra 2^16 copies in this case - not exactly trivial. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Open Office and Python
F wrote: I'd like to load a .csv file to the Open Office spreadsheet from the command line using an arbitrary delimiter through Python. I don't need any fancy formatting and stuff like that, just putting the values in the spreadsheet will do. Is there a relatively simple way to do that? I assume when you say load you mean create. To 'load' usually means to read data rather than write it. If you want to read the data in, then a Google search for python csv should answer all your questions. Otherwise... How are the values stored? It might be as simple as this: # sample data table = [ (item1, 10, 100), (item 2, 15, 300) ] out = file(my.csv, w+) for row in table: out.write(,.join(str(item) for item in row) + \n) And my.csv will look like: item1,10,100 item 2,15,300 -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Pygame, mouse events and threads
[EMAIL PROTECTED] wrote: When I put the content of the run and input functions in the main thread, it's working, why not in the thread? Because event handling needs to be done in the main thread. So does rendering. This is a limitation of the underlying system. As a general rule, try to keep all your PyGame functions in the main thread and push your other processing into background threads, if you really need them. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Python + Java Integration
Chas Emerick wrote: There is no doubt that Ruby's success is a concern for anyone who sees it as diminishing Python's status. One of the reasons for Ruby's success is certainly the notion (originally advocated by Bruce Tate, if I'm not mistaken) that it is the next Java -- the language and environment that mainstream Java developers are, or will, look to as a natural next step. Is it? I thought it was more along the lines of you've been struggling with Java to build web-apps all this time - here, have Ruby on Rails which is much easier. Python provides just as much simplicity in the web frameworks, but no consensus on what is 'best' (recent BDFL pronouncement aside), and thus only a small community for each framework. I bet that if Django or TurboGears had been fully ready for prime-time before Ruby on Rails, we wouldn't be having this discussion. As a language, Python is much closer to Java than Ruby is anyway. People already migrate over to Python from Java in their multitudes, bringing some odd assumptions with them. (eg. The whole thing about 'why isn't a Python static method equivalent to a Java class method?' because they've been wrongly told that 'static' in Java signifies a 'class method', and because they never read the Python docs where it clearly shows that classmethod != staticmethod. A bit of C++ knowledge might have sorted them out here too, as it would have for many problems encountered by people who were raised on Java, but I digress...) One thing that would help Python in this debate (or, perhaps simply put it in the running, at least as a next Java candidate) Java itself never deserved to be the 'next' anything anyway. It was sold on hype and has never lived up to it. I can see your point from a business perspective but I like to think Python is sold on its merits and not on being the new panacea for middle managers to deploy. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: hide python code !
is typically strongly linked to the quality of your work, it's arguable that this is in fact a fairer business model than being paid a normal salary. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: hide python code !
Paul Boddie wrote: Ben Sizer wrote: Imagine if you were the single-person developer of a small application that did something quite innovative, and charged a small fee for your product. Now imagine you were practically forced to make your algorithm obvious - a couple of months later, Microsoft bring out a freeware version and destroy your business in an instant. Sure, they and others can (and have) done that with closed-source products, but you increase your chances of survival 10-fold if the key algorithms are not obvious. This point is fairly comprehensively answered in the following article: http://radar.oreilly.com/archives/2006/08/apple_eats_whiners.html I don't believe so. That talks about copying of ideas, which is quite distinct from copying of implementations. The distinction may be meaningless in your typical desktop app where implementation is usually obvious from the interface. However in more high-tech systems such as multimedia or AI, the same is far from true. I read an article where various aging popular musicians were lobbying the British government to extend the period of copyright beyond 50 years because their first works would soon fall into the public domain and that they'd no longer earn royalties on those works. But in what percentage of the many other jobs that exist do you still get paid for a day at work that happened over 50 years ago? However, in most of those jobs you get paid properly at the time. Aside from the 1% of musicians who are pop stars, musicians generally do not. I'm not saying I agree with extending the copyright period, however I do think you can't just compare it to 'a day at work'. It's a totally different set of circumstances which requires a different set of rules to both encourage artists to continue creating while benefitting society in the long run too. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: hide python code !
Steven D'Aprano wrote: On Fri, 11 Aug 2006 09:18:12 -0700, Ben Sizer wrote: Imagine if you were the single-person developer of a small application that did something quite innovative, And imagine that you found a money-tree in your back yard... How about a more likely scenario? Imagine you're using a boring, run-of-the-mill algorithm, the same as 99.9% of all software out there, and that it's neither non-obvious nor innovative in any way at all. Statistically, I'd say it is ten thousand times more likely that this is the case than that the algorithm is at all valuable. Everybody thinks their algorithm is special. They almost never are. I work in game development, where new algorithms and processes are being discovered all the time. Sure, they're not going to cure cancer or end poverty but there are most definitely some algorithms devised by many developers which other companies have no idea how to emulate until years down the line; long enough for the first company to enjoy a little commercial benefit based on their individual implementation. Valuable algorithms are rare. Most software is not valuable for the algorithm, which is hidden in the source code, but for the functionality, which is obvious. Algorithms are a dime a dozen. True, however, most is not all, and I think it's unfair to categorise all software as being so trivial. Yes, and for every algorithm worth stealing, there are ten thousand that aren't. Play the odds, and you too will poo-poo the idea that some random developer on Usenet has discovered a valuable innovative algorithm. More likely he's just ashamed of his code, or wants to hide backdoors in it. Play the odds, and pretty much everything is unlikely. Of all the names in the world, what was the chance of this language being called Python? Yet these things occasionally happen. I have no opinion on why the original poster wants to hide code, only an opinion on there definitely being a few applications where it is very useful. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: hide python code !
Paul Boddie wrote: Fuzzyman wrote: I never understand the knee-jerk reaction on this mailing list to answer people who ask this question by telling them they don't really want to do it... Well, given the pace of technological development and the disregard in some environments for perpetual backward compatibility, how much of your infrastructure would you implement in vendor-supplied binaries, especially when the vendor is a one man plus dog operation? When the binaries don't work on your newly-upgraded system and the vendor is on holiday (possibly for good), it doesn't look like a knee-jerk reaction any more. It's worth remembering that there is a massive amount of software that has nothing to do with 'infrastructure', that won't need to be maintained, or upgraded. Examples include most retail software for the home or small office, and most entertainment software. Developers of such software often have understandable reasons for making it inconvenient to examine the algorithms at a high level. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: hide python code !
Paul Boddie wrote: Ben Sizer wrote: It's worth remembering that there is a massive amount of software that has nothing to do with 'infrastructure', that won't need to be maintained, or upgraded. Examples include most retail software for the home or small office, and most entertainment software. Developers of such software often have understandable reasons for making it inconvenient to examine the algorithms at a high level. Sure, developers of such software may not want their competitors to find out how their products work - certain companies also like to file patents for that added anticompetitive edge, should their competitors even consider figuring out the not-so-magic formula - but as end-users of software ourselves, we don't have to share such an understanding of their motivations, especially when such motivations directly conflict with our own: with respect to the above evidence, our own motivations are to have a reasonable level of control over the tools to manage our own data. I think you're possibly being a bit idealistic here. I use and endorse open source and open formats wherever possible but I don't believe we would have the same degree of diversity of software available if everything was open. Imagine if you were the single-person developer of a small application that did something quite innovative, and charged a small fee for your product. Now imagine you were practically forced to make your algorithm obvious - a couple of months later, Microsoft bring out a freeware version and destroy your business in an instant. Sure, they and others can (and have) done that with closed-source products, but you increase your chances of survival 10-fold if the key algorithms are not obvious. The only other way to protect against that would be a software patent, and I disagree with their existence on the grounds that it punishes those who discover the techniques independently. It may not matter if some console game or other doesn't work after 20 years... Certainly; yet this is a valid example of software that requires a degree of protection since some of the algorithms employed truly are 'worth stealing'. They can usually be replicated in time, but that may be months and allows the original company to have a deserved commercial advantage. ...although I think it's actually something of a shame given that such artifacts, no matter how apparently trivial they are, are actually part of our culture and shouldn't be so readily discarded and forgotten... Thankfully we have emulators for most platforms, and hopefully litigation won't kill those off. ...but when your own data is not easily accessible within a much shorter timeframe, the scandal is (at least to me) so much more obvious. I think it's quite possible to have a closed binary but an open document format, thus allowing the user to migrate away at any point while still preserving any 'secrets' in the implementation. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: beginner questions on embedding/extending python with C++
Qun Cao wrote: Hi Everyone, I am a beginner on cross language development. My problem at hand is to build a python interface for a C++ application built on top of a 3D game engine. The purpose of this python interface is providing a convenient scripting toolkit for the application. As well as this group/list, you may find some useful help at the Gamedev.net Scripting Languages and Game Modifications forum: http://www.gamedev.net/community/forums/forum.asp?forum_id=41 Many people there have mixed Python and C++ code in the context of game applications and may have some good answers to your questions. After deciding how to expose C++ classes and functions to Python, the main problem you'll face, assuming you need the functionality, is how to yield control between Python and C++ when a Python action is long-running yet requires the C++ engine to be polled (eg. to handle input, AI, graphics, etc). Previous threads there will give you some hints on all these matters. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a compelling argument to use Django instead of Rails
[EMAIL PROTECTED] wrote: Paul Rubin wrote: A typical shared hosting place might support 1000's of users with ONE apache/php instance (running in a whole bunch of threads or processes, to be sure). You just need to run multiple apache instances, which is advisable anyway. The hosting service formerly known as python-hosting has been doing this for years. Would you need one instance per user? Is it practical to run 1000s of Apache instances on one server? -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Using Python for my web site
Cliff Wells wrote: On Mon, 2006-07-31 at 22:25 -0700, Luis M. González wrote: IMHO the best way of using mod_python is with its publisher handler. It let's you code your applications in a MVC (model view controller) style. While I agree (or at least consider the point moot) that this is possibly the best way to use plain mod_python, I'd disagree that it's a good way to develop modern web applications in Python. By the time you've decided on every bit of framework to use, and made all the little decisions that go into turning a fresh, clean spot on your hard drive into an application, what you've done is reinvent TurboGears rather than develop your application. However, at least whatever you come up with would be better documented than TurboGears. ;) (I reserve the right to amend this jocular opinion after TurboGears hits version 1.0.) -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a compelling argument to use Django instead of Rails
Vincent Delporte wrote: On 31 Jul 2006 07:05:27 -0700, Ben Sizer [EMAIL PROTECTED] wrote: Typically you run PHP as a module in your webserver, so there should be no process startup overhead. mod_python provides the same sort of functionality for Python, but is not as popular or widely installed as the PHP Apache module. So, if mod_python provides the same functionality, it's not the main reason why Python developers use application servers while PHP users still program with page codes in /htdocs. Why do PHP users stick to that old way of things? Because they mostly use shared hosts, with no way to install their application server? Yes, one reason is because they can't install anything other than web pages. Not only can they not install a Python application server, they can't install mod_python either, and few places will have it pre-installed. Shared hosting accounts for a massive number of sites so this is a significant issue. Another perfectly good reason is that PHP pages are much simpler to deploy than any given Python application server. Just add the code into your HTML pages as required and you're done. Python could come close to this if something like the Python Server Pages implementation in mod_python was to become widely available and well known, but that still requires overcoming the first problem. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Network Game in Python
[EMAIL PROTECTED] wrote: Some questions I have are: 1. How can I manage network messages among the players. Should multicast be used or Actor should send the message to Supervisor and he sends to all. ? Send a message from one client to the supervisor, handle it, then get the supervisor to send messages back out to notify all clients of the change. That way, the supervisor always has the correct state, and knows which clients are aware of it. What python modules can be handy in these things. The socket and select modules are all that you need. Perhaps there's a higher-level solution somewhere but I don't expect you'd need it. 2. How can I manage moves among players. What move a player makes is visible to all others in real time, so essentially all players have the same consistent view of the game. Only the person with access can actually make a move or carry out action. Any suggestion how to carry out this thing. As above: inform the supervisor/server of the move, and the server informs all others of what is going on. Usually this is just a message telling the client to update certain values. The client will update those values and refresh the display. You may find it easiest to send whole objects using pickle or something like that. 3. Shold I use a flat file or some database in mySQL to measure points etc ? I want to have a repository which keep tracks of all the mvoes in the system and who played what move etc..? Any suggestions on this. Use whichever is easiest for you. Why do you need to save the data to disk anyway? If you definitely need to do that, the shelve module is often a good choice for basic needs. But it depends on what you need to do with the information after you write it. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a compelling argument to use Django instead of Rails
Paul Rubin wrote: Ben Sizer [EMAIL PROTECTED] writes: Another perfectly good reason is that PHP pages are much simpler to deploy than any given Python application server. Just add the code into your HTML pages as required and you're done. Python could come close to this if something like the Python Server Pages implementation in mod_python was to become widely available and well known, but that still requires overcoming the first problem. I didn't realize you could do shared hosting with mod_python, because of the lack of security barriers between Python objects (i.e. someone else's application could reach into yours). You really need a separate interpreter per user. A typical shared hosting place might support 1000's of users with ONE apache/php instance (running in a whole bunch of threads or processes, to be sure). Ah yes, I hadn't considered that. Is this a Python limitation? Py_Initialize() seems to initialise a global Python object which obviously makes it awkward to share. Other languages allow you to create multiple instances (eg. Lua has lua_newstate() which returns a new Lua state) which would facilitate running multiple interpreters without the new process overhead. A brief search implies that mod_perl doesn't have the same problem as mod_python (but has other problems). It would be a shame if Python is almost alone in having this issue. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a compelling argument to use Django instead of Rails
Paul Boddie wrote: Ben Sizer wrote: Even C++ comes with OpenGL in the standard library. Which standard library? Sorry, it was a long day, and I used entirely the wrong term here. By that, I meant typically shipped with each compiler. I've never had to even install a development library to use OpenGL, whether under Win32 or Linux. It's just a typical part of the distribution. [Web-SIG standardisation] And I always thought that WSGI was solving the wrong problem. It certainly didn't go very far towards meeting the expressed goals of the Web-SIG. Oh well. http://mail.python.org/pipermail/web-sig/2004-August/000650.html There are some remarks just after that message about the SIG charter needing to change or having become irrelevant, but in fact the need for standard functionality is as relevant today as ever. At a slightly higher level, everyone would now prefer that you buy into their total full stack solution, perhaps with the exception of the Paste developers whose selection of packages either suggest a problem of internal framework proliferation or one of a lack of coherency in presenting a suitable solution to the casual inquirer. Yeah. On the server side I think there's been a sad lack of attention to the large middle ground that lies between simple CGI scripting and full stack solutions. In fact, I'd guess that the majority of web sites fall into that middle ground, just perhaps not the most interesting or financially lucrative ones. Examples might be things like the various PHP forums, or web-based non-real-time games. These applications are complex enough to deserve a decent implementation language such as Python, yet simple and small enough that most users won't want to set up dedicated hardware for the purpose. I think there's definitely scope in the standard library to go well beyond the current cgi module and the piecemeal offerings in other modules, without needing to provide another integrated web stack. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a compelling argument to use Django instead of Rails
Sybren Stuvel wrote: Ben Sizer enlightened us with: PyGame was barely maintained for a year, and is based on SDL which was also barely maintained for a year, and which hasn't kept up with hardware advances at all. Still, ID Software and Epic both use SDL + OpenGL for their games. Why is it good for them but insufficient for you? Because id and Epic have many millions of dollars and better developers to throw at the problem than I do. :) To put it another way, they have lots of in-house middleware that is built on top of those technologies to make them more effective. SDL and OpenGL is the bottom of the stack for them. We mere mortals often prefer to start with something a little higher level. :) -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a compelling argument to use Django instead of Rails
Terry Reedy wrote: Ben Sizer [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] PyGame was barely maintained for a year, and is based on SDL which was also barely maintained for a year, and which hasn't kept up with hardware advances at all. I believe there is a recent release of SDL, but which what advances I do not know. Pygame is being actively worked on by more than one person. The recent release of SDL was another minimal one, though there is an intention to make the important changes 'soon'. As for PyGame, it's good that development there has picked up again but I'd love to see it broaden its horizons beyond SDL. Maybe that is impractical, however. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
Re: Need a compelling argument to use Django instead of Rails
Gerhard Fiedler wrote: On 2006-07-29 01:07:12, Tim Roberts wrote: Vincent Delporte [EMAIL PROTECTED] wrote: BTW, what is the advantage of running a CherryPy/Django server instead of the regular way of code in pages? Improved performance because the Python interpreter is already up and running? Exactly. The Python interpreter can take a significant fraction of a second to start. For the typical short web request, the overhead can add up. Is this start-up overhead the same thing for PHP? Or is this handled differently there? Typically you run PHP as a module in your webserver, so there should be no process startup overhead. mod_python provides the same sort of functionality for Python, but is not as popular or widely installed as the PHP Apache module. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
