Re: [Python-Dev] SIGCHECK() in longobject.c
On Mon, Oct 19, 2009 at 9:58 PM, Tim Peters tim.pet...@gmail.com wrote: Don't want to hijack this thread, but this is the kind of use case justifying keeping the 3-argument pow in the decimal module. People playing with number theory questions can learn a bag of tricks to worm around that non-decimal arithmetic can make it inconvenient slow to get answers about decimal digits, but most people -- and especially beginners -- find life easier when doing calculations in decimal to begin with. Then they can use obvious methods, and not get sidetracked by wondering why they take forever to finish. That's true. I wouldn't relish the task of trying to teach the decimal module at the same time as introducing students to Python and to elementary number theory, though. It's not the most friendly module to get started with. Although, to be fair, I started decimal.getcontext().prec = 2000 p10 = pow(decimal.Decimal(2), 43112609) before I started typing this, and am still waiting for it to finish ;-) Hmm, yes. The decimal module isn't (currently) well set up for this sort of calculation, mostly because almost every operation is implemented by converting to binary, invoking the appropriate int/long arithmetic operation, and converting back. Since the conversion is O(n^2), even addition and multiplication of Decimal instances end up being O(n^2) operations at the moment, instead of getting the linear and Karatsuba (resp.) running times that they deserve. (The exception is rounding operations, which don't do any decimal - binary operations, but operate directly on the coefficient in its representation as a string of decimal digits.) This high-precision inefficiency could easily be fixed by using a dedicated 'decimal natural number' extension type for the Decimal coefficient, stored internally in base a suitable power of 10. I think this may be worth considering seriously. I'm not proposing this as an alternative to the huge task of rewriting the entire decimal module in C, by the way; it would be more a stop-gap measure that would be easy to implement, would slightly increase efficiency for normal operations, and vastly increase efficiency for high-precision operations. OTOH, decimal.getcontext().prec = 200 pow(decimal.Decimal(2), 43112609) # get the first 100 digits ( then some) and pow(decimal.Decimal(2), 43112609, 10**100) - 1 # get the last 100 digits both appear to work instantaneously. Right. Low precision Decimal operations should be fine. I don't really see the advantage of the second operation over a simple pow(2, 43112609, 10**100) though. By the way, despite the above use-case, and despite the fact that I use it frequently, I still don't believe 3-argument pow belongs in the core. But that's probably a discussion topic for Python 4000. Mark ___ 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] SIGCHECK() in longobject.c
Mark Dickinson wrote: This high-precision inefficiency could easily be fixed by using a dedicated 'decimal natural number' extension type for the Decimal coefficient, stored internally in base a suitable power of 10. I think this may be worth considering seriously. I'm not proposing this as an alternative to the huge task of rewriting the entire decimal module in C, by the way; it would be more a stop-gap measure that would be easy to implement, would slightly increase efficiency for normal operations, and vastly increase efficiency for high-precision operations. Didn't you already start work on that concept with the deccoeff patch? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] Python 2.6.4rc2
On Oct 19, 2009, at 11:10 PM, Lisandro Dalcin wrote: I'm getting this warning. It seems nothing is actually broken, but the fix is pretty easy. gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Objects/unicodeobject.c: In function 'PyUnicodeUCS2_FromFormatV': Objects/unicodeobject.c:687: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness /usr/include/string.h:397: note: expected 'const char *' but argument is of type 'unsigned char *' Objects/unicodeobject.c:687: warning: pointer targets in passing argument 1 of 'PyUnicodeUCS2_DecodeUTF8' differ in signedness Include/unicodeobject.h:752: note: expected 'const char *' but argument is of type 'unsigned char *' This isn't a regression in 2.6.3, nor is it critical enough, to be fixed for 2.6.4. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] SIGCHECK() in longobject.c
On Tue, Oct 20, 2009 at 11:49 AM, Nick Coghlan ncogh...@gmail.com wrote: Mark Dickinson wrote: This high-precision inefficiency could easily be fixed by using a dedicated 'decimal natural number' extension type for the Decimal coefficient, stored internally in base a suitable power of 10. [...] Didn't you already start work on that concept with the deccoeff patch? I did: the code can be seen at: http://svn.python.org/view/sandbox/trunk/decimal/decimal_in_c/ This code defines a Deccoeff type as above, providing base 10 natural number arithmetic, along with a skeletal _Decimal type. The work on Deccoeff is pretty much complete, but the _Decimal type is only just a beginning; the original intent was to slowly translate the Decimal code into C and move it into the _Decimal type. The code was working a few months ago (with all Decimal tests passing), but there have been some changes and bugfixes since then. I might try to resurrect that code, dropping the _Decimal type and just concentrating on Deccoeff. Mark ___ 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] Volunteer needed to organize summits
I'd like to turn over the organization of the VM and Python Language Summits at PyCon 2010 to someone else, one or two people. (The same person doesn't need to organize both of them.) Why: in November PyCon will be three months away, so the guest list needs to be finalized and the invitations need to be sent. Yet I can't pull together the motivation to work on them; I contemplate the task for two minutes and then go do something else. It's obviously better if the summit tasks are being actively worked on instead of just drifting, so I want to give it up now. What's required: chiefly it's just a matter of sending and replying to e-mail. Draw up a guest list (I can provide last year's lists); think of new people projects to be added, or e-mail someone to ask for suggestions; send out invitations and requests for agenda items; collect the responses so we know how many people are coming. You can also help moderate the summits on the day of the events, but if that's not feasible someone else could do it, or the groups could manage themselves. (Also sent to pycon-organizers, psf-members.) --amk ___ 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] Interest in integrating C decimal module into Python?
Hi, as some of you know, recently I've released an arbitrary precision C library for decimal arithmetic together with a Python module: http://www.bytereef.org/libmpdec.html http://www.bytereef.org/fastdec.html Both the library and the module have been tested extensively. Fastdec currently differs from decimal.py in a couple of ways that could be fixed. The license is AGPL, but if there is interest in integrating it into Python I'd release it under a Python-compatible license. There have been several approaches towards getting C decimal arithmetic into Python: http://bugs.python.org/issue2486 Fastdec follows Raymond Hettinger's suggestion to provide wrappers for an independent C implementation. Arguments in favour of fastdec are: * Complete implementation of Mike Cowlishaw's specification * C library can be tested independently * Redundant arithmetic module for tests against decimal.py * Faster than Java BigDecimal * Compares relatively well in speed against gmpy To be clear, I would not want to _replace_ decimal.py. Rather I'd like to see a cdecimal module alongside decimal.py. I know that ultimately there should be a PEP for module inclusions. The purpose of this post is to gauge interest. Specifically: 1. Are you generally in favour of a C decimal module in Python? 2. Would fastdec - after achieving full decimal.py compatibility - be a serious candidate? 3. Could I use this list to settle a couple of questions, or would perhaps a Python developer be willing to work with me to make it compatible? I'm asking this to avoid doing work that would not find acceptance afterwards. Thanks, Stefan Krah ___ 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] Interest in integrating C decimal module into Python?
Shouldn't this be on python-ideas? S On Oct 20, 2009, at 9:15 AM, Stefan Krah wrote: Hi, as some of you know, recently I've released an arbitrary precision C library for decimal arithmetic together with a Python module: http://www.bytereef.org/libmpdec.html http://www.bytereef.org/fastdec.html Both the library and the module have been tested extensively. Fastdec currently differs from decimal.py in a couple of ways that could be fixed. The license is AGPL, but if there is interest in integrating it into Python I'd release it under a Python-compatible license. There have been several approaches towards getting C decimal arithmetic into Python: http://bugs.python.org/issue2486 Fastdec follows Raymond Hettinger's suggestion to provide wrappers for an independent C implementation. Arguments in favour of fastdec are: * Complete implementation of Mike Cowlishaw's specification * C library can be tested independently * Redundant arithmetic module for tests against decimal.py * Faster than Java BigDecimal * Compares relatively well in speed against gmpy To be clear, I would not want to _replace_ decimal.py. Rather I'd like to see a cdecimal module alongside decimal.py. I know that ultimately there should be a PEP for module inclusions. The purpose of this post is to gauge interest. Specifically: 1. Are you generally in favour of a C decimal module in Python? 2. Would fastdec - after achieving full decimal.py compatibility - be a serious candidate? 3. Could I use this list to settle a couple of questions, or would perhaps a Python developer be willing to work with me to make it compatible? I'm asking this to avoid doing work that would not find acceptance afterwards. Thanks, Stefan Krah ___ 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/ssteinerx%40gmail.com ___ 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] Interest in integrating C decimal module into Python?
On Tue, 20 Oct 2009 at 09:27, sstein...@gmail.com wrote: Shouldn't this be on python-ideas? IMO this question is appropriate for python-dev, not python-ideas. --David ___ 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] Interest in integrating C decimal module into Python?
sstein...@gmail.com sstein...@gmail.com wrote: Shouldn't this be on python-ideas? I found previous discussions about Decimal in C on python-dev, that's why used this list. Stefan Krah ___ 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] Interest in integrating C decimal module into Python?
On Oct 20, 2009, at 9:43 AM, Stefan Krah wrote: sstein...@gmail.com sstein...@gmail.com wrote: Shouldn't this be on python-ideas? I found previous discussions about Decimal in C on python-dev, that's why used this list. python-ideas: This list is to contain discussion of speculative language ideas for Python for possible inclusion into the language. If an idea gains traction it can then be discussed and honed to the point of becoming a solid proposal to put to either python-dev or python-3000 as appropriate. I guess it's a fine line...and matter of opinion. No worries. S ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
[following up on distutils-sig] Michael Foord wrote: Many Windows users would be quite happy if the standard mechanism for installing non-source distributions on Windows was via the wininst binaries. ...and many users may not be ;-) I know I'd be extremely unhappy if that were the case as I routines use multiple versions of packages with multiple versions of python on one machine... I wonder if it is going to be possible to make this compatible with the upcoming distutils package management 'stuff' (querying for installed packages, uninstallation etc) since installation/uninstallation goes through the Windows system package management feature. I guess it would be eminently possible but require some reasonably high level Windows-fu to do. I wouldn't have a problem if integrating with the windows package manager was an optional extra, but I think it's one of many types of package management that need to be worried about, so might be easier to get the others working and let anyone who wants anything beyond a pure-python packaging system that works across platforms, regardless of whether binary extensions are needed, do the work themselves... Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
Chris Withers wrote: [following up on distutils-sig] ...FAIL, sorry for the noise. Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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] Interest in integrating C decimal module into Python?
On Tue, 20 Oct 2009 at 09:55, sstein...@gmail.com wrote: On Oct 20, 2009, at 9:43 AM, Stefan Krah wrote: sstein...@gmail.com sstein...@gmail.com wrote: Shouldn't this be on python-ideas? I found previous discussions about Decimal in C on python-dev, that's why used this list. python-ideas: This list is to contain discussion of speculative language ideas for Python for possible inclusion into the language. If an idea gains traction it can then be discussed and honed to the point of becoming a solid proposal to put to either python-dev or python-3000 as appropriate. I guess it's a fine line...and matter of opinion. No worries. In this case it isn't a language idea under discussion, but the possible inclusion of an implementation of an idea (and moreover an idea that is already included in Python in another, less efficient, form). (I'm expecting that both Mark Dickinson and Raymond Hettinger will comment on this thread eventually...) --David (RDM) ___ 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] SIGCHECK() in longobject.c
On Tue, Oct 20, 2009 at 11:49 AM, Nick Coghlan ncogh...@gmail.com wrote: Mark Dickinson wrote: This high-precision inefficiency could easily be fixed by using a dedicated 'decimal natural number' extension type for the Decimal coefficient, stored internally in base a suitable power of 10. [...] Didn't you already start work on that concept with the deccoeff patch? I did: the code can be seen at: http://svn.python.org/view/sandbox/trunk/decimal/decimal_in_c/ This code defines a Deccoeff type as above, providing base 10 natural number arithmetic, along with a skeletal _Decimal type. The work on Deccoeff is pretty much complete, but the _Decimal type is only just a beginning; the original intent was to slowly translate the Decimal code into C and move it into the _Decimal type. The code was working a few months ago (with all Decimal tests passing), but there have been some changes and bugfixes since then. I might try to resurrect that code, dropping the _Decimal type and just concentrating on Deccoeff. My only concern about this is the effect it would have on IronPython, Jython, PyPy, and other alternate implementations that use the stdlib. ___ 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] SIGCHECK() in longobject.c
On Tue, Oct 20, 2009 at 3:50 PM, Eric Smith e...@trueblade.com wrote: The code was working a few months ago (with all Decimal tests passing), but there have been some changes and bugfixes since then. I might try to resurrect that code, dropping the _Decimal type and just concentrating on Deccoeff. My only concern about this is the effect it would have on IronPython, Jython, PyPy, and other alternate implementations that use the stdlib. Yes, that worries me a bit, too. I have the same worry with the idea of rewriting the entire decimal module in C. The Deccoeff type is very simple, though. It would be easy to create a pure Python version of it, and then do something like: try: from _decimal import Deccoeff # try to get C version except ImportError: from deccoeff import Deccoeff # else use Python fallback code. Mark ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
2009/10/20 Chris Withers ch...@simplistix.co.uk: I wouldn't have a problem if integrating with the windows package manager was an optional extra, but I think it's one of many types of package management that need to be worried about, so might be easier to get the others working and let anyone who wants anything beyond a pure-python packaging system that works across platforms, regardless of whether binary extensions are needed, do the work themselves... There are many (I believe) Windows users for whom bdist_wininst is just what they want. For those people, where's the incentive to switch in what you propose? You're not providing the features they currently have, and frankly do the work yourself is no answer (not everyone can, often for entirely legitimate reasons). If such users could ignore the new offering, that would be fine - but they can't, if projects stop providing bdist_wininst installers. That's what's happening with eggs already, and yes, it *is* a pain. And I'm in a position where I *can* build my own bdist_wininst installer - but often, I'll just not bother using a package. So packages lose users - does this matter? Who can tell? In my view, the number one priority is to have a single distribution format. I really don't care what it is. But *one*. bdist_wininst used to be that on Windows, and for all its limitations it was a huge benefit. Eggs messed that up, essentially because they didn't provide all the features of bdist_wininst (uninstallers...) so they didn't replace bdist_wininst, they sat alongside. Now you're proposing to make the same mistake again. Can I repeat that in big letters? The key is a SINGLE DISTRIBUTION FORMAT. If you can persuade everyone to accept a format which ignores clearly stated user requirements, go for it. But if you can't, you're making the problem worse rather than helping. My money's on a solution that acknowledges and addresses user requirements instead. Paul. ___ 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] SIGCHECK() in longobject.c
On Tue, Oct 20, 2009 at 07:57, Mark Dickinson dicki...@gmail.com wrote: On Tue, Oct 20, 2009 at 3:50 PM, Eric Smith e...@trueblade.com wrote: The code was working a few months ago (with all Decimal tests passing), but there have been some changes and bugfixes since then. I might try to resurrect that code, dropping the _Decimal type and just concentrating on Deccoeff. My only concern about this is the effect it would have on IronPython, Jython, PyPy, and other alternate implementations that use the stdlib. Yes, that worries me a bit, too. I have the same worry with the idea of rewriting the entire decimal module in C. The Deccoeff type is very simple, though. It would be easy to create a pure Python version of it, and then do something like: try: from _decimal import Deccoeff # try to get C version except ImportError: from deccoeff import Deccoeff # else use Python fallback code. And this is why you shouldn't have to worry. As long as the tests exercise both the pure Python and C versions then the other VMs are covered. -Brett ___ 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] Interest in integrating C decimal module into Python?
2009/10/20 Stefan Krah stefan-use...@bytereef.org: Hi, as some of you know, recently I've released an arbitrary precision C library for decimal arithmetic together with a Python module: http://www.bytereef.org/libmpdec.html http://www.bytereef.org/fastdec.html Both the library and the module have been tested extensively. Fastdec currently differs from decimal.py in a couple of ways that could be fixed. The license is AGPL, but if there is interest in integrating it into Python I'd release it under a Python-compatible license. There have been several approaches towards getting C decimal arithmetic into Python: http://bugs.python.org/issue2486 Fastdec follows Raymond Hettinger's suggestion to provide wrappers for an independent C implementation. Arguments in favour of fastdec are: * Complete implementation of Mike Cowlishaw's specification * C library can be tested independently * Redundant arithmetic module for tests against decimal.py * Faster than Java BigDecimal * Compares relatively well in speed against gmpy To be clear, I would not want to _replace_ decimal.py. Rather I'd like to see a cdecimal module alongside decimal.py. Why? If it's 100% compatible with decimal.py, just replace it. All the user should see is improved speed. Let's not do another pickle/cpickle. I know that ultimately there should be a PEP for module inclusions. The purpose of this post is to gauge interest. Specifically: 1. Are you generally in favour of a C decimal module in Python? Yes, although I have to admit my interest is fairly theoretical. 2. Would fastdec - after achieving full decimal.py compatibility - be a serious candidate? I don't see why not, if it was 100% compatible with decimal.py 3. Could I use this list to settle a couple of questions, or would perhaps a Python developer be willing to work with me to make it compatible? I'm asking this to avoid doing work that would not find acceptance afterwards. I can't help much here, but I'd prefer to see discussions on python-dev so I'm +1 on keeping discussions here. Waiting eagerly to hear the experts' comments... Paul. ___ 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] Add const to python API - issue 6952
On 20 Oct 2009, at 04:35, Martin v. Löwis wrote: The patch I developed for comment only adds const to the input parameters and used casts to allow output parameters to stay without the const. What specific APIs are you talking about here? Checking my patch I have two functions that need to have output params changed to const to avoid casting. PyOS_strtoul- ptr PyLong_FromString - pend Barry ___ 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] Add const to python API - issue 6952
On Tue, Oct 20, 2009 at 4:03 PM, Barry Scott ba...@barrys-emacs.org wrote:
Checking my patch I have two functions that need to
have output params changed to const to avoid casting.
PyOS_strtoul- ptr
PyLong_FromString - pend
This is a no-win situation. If the string is const in the caller, they
currently need to cast it. If you make the change, then if string is not
const in the caller then they will need to cast it. I've provided a short
example below and marked the lines that generate an incompatible pointer
type warning with gcc.
I suggest following POSIX's lead and omitted the const in these cases.
void test_const(const char **foo);
void test_noconst(char **foo);
int main(void) {
char *noconst_var;
const char *const_var;
test_const(noconst_var); // generates a warning
test_const(const_var);
test_noconst(noconst_var);
test_noconst(const_var); // generates a warning
return 0;
}
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com
___
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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Tue, 20 Oct 2009 21:49:42 +0100, Paul Moore p.f.mo...@gmail.com wrote: Can I repeat that in big letters? The key is a SINGLE DISTRIBUTION FORMAT. ok - but that pretty much exists.. If you can persuade everyone to accept a format which ignores clearly stated user requirements, go for it. But if you can't, you're making the problemorse rather than helping. My money's on a solution that acknowledges and addresses user requirements instead. What solution is that exactly? You don't say.. I would be happy to revamp pythonpkgmgr and backgrade to have a tk interface if it is felt that would help. That's not so difficult - certainly not on my side. I don't know which iceberg the people that want to keep command line interfaces forever still live on, but they seem very good at sinking any attempts of passage by forward moving boats.. Distutils roadmap for windows is to apply more freeze spray.. it's a cryogenic source code freezing iceberg... It's just there for windows users to crash their boats into.. Try and see for yourself.. David ___ 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] Interest in integrating C decimal module into Python?
On Tue, Oct 20, 2009 at 3:00 PM, Paul Moore p.f.mo...@gmail.com wrote: 2009/10/20 Stefan Krah stefan-use...@bytereef.org: Hi, as some of you know, recently I've released an arbitrary precision C library for decimal arithmetic together with a Python module: http://www.bytereef.org/libmpdec.html http://www.bytereef.org/fastdec.html Both the library and the module have been tested extensively. Fastdec currently differs from decimal.py in a couple of ways that could be fixed. The license is AGPL, but if there is interest in integrating it into Python I'd release it under a Python-compatible license. There have been several approaches towards getting C decimal arithmetic into Python: http://bugs.python.org/issue2486 Fastdec follows Raymond Hettinger's suggestion to provide wrappers for an independent C implementation. Arguments in favour of fastdec are: * Complete implementation of Mike Cowlishaw's specification * C library can be tested independently * Redundant arithmetic module for tests against decimal.py * Faster than Java BigDecimal * Compares relatively well in speed against gmpy To be clear, I would not want to _replace_ decimal.py. Rather I'd like to see a cdecimal module alongside decimal.py. Why? If it's 100% compatible with decimal.py, just replace it. All the user should see is improved speed. Let's not do another pickle/cpickle. For example other python implementations might decide to use python version as long as builtin version does not appear. Python versions are usually also better targets for jit than mixed versions. C level versions also usually have more bugs (just statistics), so some people might want to choose pure-python version. In general - some people have some reasons. Cheers, fijal ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Wed, Oct 21, 2009 at 5:49 AM, Paul Moore p.f.mo...@gmail.com wrote: 2009/10/20 Chris Withers ch...@simplistix.co.uk: I wouldn't have a problem if integrating with the windows package manager was an optional extra, but I think it's one of many types of package management that need to be worried about, so might be easier to get the others working and let anyone who wants anything beyond a pure-python packaging system that works across platforms, regardless of whether binary extensions are needed, do the work themselves... There are many (I believe) Windows users for whom bdist_wininst is just what they want. For those people, where's the incentive to switch in what you propose? You're not providing the features they currently have, and frankly do the work yourself is no answer (not everyone can, often for entirely legitimate reasons). I am not so familiar with msi or wininst internals, but isn't it possible to install w.r.t. a given prefix ? Basically, making it possible to use a wininst in a virtualenv if required (in which case I guess it would not register with the windows db - at least it should be possible to disable it). The main problem with bdist_wininst installers is that they don't work with setuptools dependency stuff (at least, that's the reason given by windows users for a numpy egg on windows, whereas we used to only provide an exe). But you could argue it is a setuptools pb as much as a wininst pb, I guess. David ___ 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] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
On Tue, Oct 20, 2009 at 7:44 PM, David Cournapeau courn...@gmail.com wrote: On Wed, Oct 21, 2009 at 5:49 AM, Paul Moore p.f.mo...@gmail.com wrote: 2009/10/20 Chris Withers ch...@simplistix.co.uk: There are many (I believe) Windows users for whom bdist_wininst is just what they want. For those people, where's the incentive to switch in what you propose? You're not providing the features they currently have, and frankly do the work yourself is no answer (not everyone can, often for entirely legitimate reasons). I am not so familiar with msi or wininst internals, but isn't it possible to install w.r.t. a given prefix ? This is definitely supported by the msi. In fact, you can do this at the command line (although I don't know if this is considered officially supported or not): $ argparse-1.0.2.win32-py2.6.msi /quiet TARGETDIR=C:\TempPython $ dir C:\TempPython\Lib\site-packages Volume in drive C has no label. Volume Serial Number is B6E6-4B4D Directory of C:\TempPython\Lib\site-packages 10/20/2009 10:04 PMDIR . 10/20/2009 10:04 PMDIR .. 10/20/2009 10:03 PM 1,584 argparse-1.0.2-py3.1.egg-info 10/09/2009 11:03 AM86,620 argparse.py Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ 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] Add const to python API - issue 6952
I suggest following POSIX's lead and omitted the const in these cases. Thanks, that sounds reasonable. Regards, Martin ___ 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
