[Python-Dev] Cross-platform math functions?
Hi - I'm curious if there is any interest in the Python community to achieve better cross-platform math behavior. A quick test[1] shows a non-surprising difference between the platform implementations. Question: Is there any interest in changing the behavior to produce identical results across platforms (for example by utilizing fdlibm [2])? Since I have need for a set of cross-platform math functions I'll probably start with a math-compatible fdlibm module (unless somebody has done that already ;-) Cheers, - Andreas [1] Using Python 2.4: >>> import math >>> math.cos(1.0e32) WinXP:-0.39929634612021897 LinuxX86: -0.49093671143542561 [2] http://www.netlib.org/fdlibm/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cross-platform math functions?
Tim Peters wrote: > Package a Python wrapper and see how popular it becomes. Some reasons > against trying to standardize on fdlibm were explained here: > >http://mail.python.org/pipermail/python-list/2005-July/290164.html Thanks, these are good points. About speed, do you have any good benchmarks available? In my experience fdlibm is quite reasonable for speed in the context of use by dynamic languages (i.e., counting allocation overheads, lookup and send performance etc) but since I'm not a Python expert I'd appreciate some help with realistic benchmarks. > Bottom line is I suspect that when it comes to bit-for-bit > reproducibility, fewer people care about that x-platform than care > about it x-language on the box they use. Nothing wrong with different > modules for people with different desires. Agreed. Thus my question if someone had already done this ;-) Cheers, - Andreas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cross-platform math functions?
Nick Maclaren wrote: > The word "better" is emotive and inaccurate. Such calculations are > numerically meaningless, and merely encourage the confusion between > consistency and correctness. There is a strong sense in which giving > random results between -1 and 1 would be better. I did, of course, mean more consistent (and yes, random consistent results would be "better" by this definition and indeed I would prefer that over inconsistent but more accurate results ;-) Cheers, - Andreas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] .pyc location?
Hi - I'm having a few problems with our (embedded) Python interpreter trying to write .pyc files in the installation of our product (which actually sometimes works and sometimes doesn't depending on OS and paranoia level involved). This can give raise to a few very confusing situations and I'd like to be able to specify an explicit location for the .pyc files. Ideally, this would be a cache location where all .pyc files are created under an hashed (MD5 or similar) name of the original source file so that the cache location can be used for all of the compiled Python files. While googling this issue, I noticed that the status of PEP 304 says "withdrawn" but since most of the discussion around it seems to be a couple of years old, I thought I'd ask if anyone has done something in this area recently. If not, a pointer to the place which manages these mappings (or a starting point for further digging) would be greatly welcome. Cheers, - Andreas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] .pyc location?
Nick Coghlan wrote: > Issues with collocating the compiled files with the source files do > arise occasionally, but they can generally be resolved by having root > run compileall [1] over the affected directories. In cases where users > are able to modify source files (hence leading to the need to recompile > them after installation), those users are also typically able to write > the necessary .pyc files to the same directory. Thanks, I'll try using compileall before digging deeper. If the file times are preserved correctly by the various installers this should do the trick. Cheers, - Andreas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deploying embedded Python
Hi - [Apologies if this isn't the right list but I couldn't find any mailing list specifically dedicated to embedded Python. Does such a list exist?] I'm currently looking into a few deployment issues with our embedded Python interpreter and I'm looking for any information about deploying embedded Python that people may have. Specifically, I'm looking for the following information: 1) How to define a useful subset of the stdlib that can serve as an initial basis for the installation but later allows upgrade to the "full" library if desirable. In other words, I'd like to deploy a small subset of the stdlib to begin with (simply because of size constraints) which may later be extended to a full stdlib if this is desirable. Has someone done this before? I'd love to have a small "Python.zip" cross-platform stdlib surrogate that just gets shipped with the product. If not, what is the right starting point for analyzing the dependencies inside the stdlib? 2) How to isolate the embedded interpreter from environmental effects. I have found that on occasion, the interpreter would pick up "stray" installations which can cause weird problems. Which environmental settings affect the startup of an embedded Python interpreter? How does one work around/remove those dependencies? Is there any information available about how exactly the startup works? What is being read/loaded in which order etc? 3) General advice about deploying embedded Python. Pointers to web sites, general experience (good or bad) etc. are all very welcome. Thanks, - Andreas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deploying embedded Python
Aahz wrote: > On Mon, Dec 17, 2007, Andreas Raab wrote: >> [Apologies if this isn't the right list but I couldn't find any mailing >> list specifically dedicated to embedded Python. Does such a list exist?] > > There isn't, really, but python-dev is by definition NOT the correct list > because you're asking questions about using Python rather than about > improving the code in Python. You should use either comp.lang.python or > capi-sig. Thanks for pointing this out. I wasn't aware that this list is exclusively about improving the code in Python - I thought that discussions about, for example, the contents and structure of the stdlib as well as the startup of the interpreter would be on-topic here (mainly because it's fairly specialized knowledge that I wouldn't expect to be widely available outside of the python-dev community). In any case, I'll repost on the lists you're mentioning. Cheers, - Andreas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Guido van Rossum wrote: > On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: >>> - File size should be rounded up to some block size (512 if you don't >>> have filesystem specific information) before adding to the total. >> Why? > > Because that's how filesystems work. Allocations are in terms of block > sizes. 1000 files of 1 byte take up the same space as 1000 files of > 512 bytes (in most common filesystems anyway -- I think Reiserfs may > be different). Forgive me if I'm missing the obvious but shouldn't block size be taken into consideration when setting the cap rather than for testing the file size? E.g., what happens if you specify a cap of 100 bytes, your block size is 512 and the user tries to write a single byte? Fail, because it's logically allocation 512 and the cap is at 100? That seems backwards to me since it would require that the app first determine the block size of the OS it's running on before it can even set a "working" cap. And if the interpreter implicitly rounds the cap up to block size, then there isn't much of a point in specifying the number of bytes to begin with - perhaps use number of blocks instead? In any case, I'd argue that if you allow the cap to be set at any specific number of bytes, the interpreter should honor *exactly* that number of bytes, blocks or not. Cheers, - Andreas ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
