Re: up to date books?
John Salerno wrote: ... > Just one more quick question: I'm basically learning programming for > fun, and I'm concentrating on C# right now. Python seems interesting, > but I was wondering if I should even bother. Would it supplement C# in > any way, or can C# do everything Python can? C# and Python are both Turing-complete (net of limitations to finite amounts of storage, in the real world), so of course "they can do" exactly the same things as each other in some pretty strong sense -- so can machine language, Fortran, ... Exactly because of this, this is hardly ever a sensible question to ask. It clearly can be more _convenient and practical_ to "do some thing" in C# than machine language, because C# is a higher-level language than machine language, which increases your productivity (this applies to most tasks, but for a few things, such as some interrupt-response routines in embedded systems, machine language can instead be vastly more practical and productive). Similarly, Python is a higher-level language than C#, which further increases your productivity (and again this applies to most tasks, but for a few lower-level things C# may in fact be more practical and productive). Besides considerations connected to the language themselves, similar issues (pushing the same way) apply to their implementations -- Python vs C# as well as C# vs machine language. As far as I know, to deploy C# applications you need a dotNet runtime (or perhaps a Mono runtime, if you find it robust enough for your purposes); with machine language you'd be restricted to a particular family of CPUs (or emulators thereof, such as VirtualPC to emulate intel CPUs under MacOSX with PowerPC CPUs). Similarly, with Python you can deploy on the same runtimes as you can with C# (using the IronPython implementation, which compiles Python to Microsoft CLR intermediate-code) -- but alternatively you can deploy to JVMs (with the Jython implementation), to a variety of architectures and OSs using a Python-dedicated runtime/VM (with the classic, CPython implementation), to some Nokia cellphones (Series 60 ones, I believe) using the Python runtime which Nokia has developed and released, one day to the Parrot VM, etc, etc... in practice, therefore, Python pervades more niches than C#, and thus offers more practical deployment options, just like C# is more pervasive and deployable than machine language. However, I believe the language-level (and therefore programmer-productivity) issue will be even more important in most cases. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: up to date books?
Glad to hear that my efforts to cover some of 2.3's release features in a mostly-2.2 book were appreciated. I'm probably going to do the same thing for the 2nd edition of the Nutshell: wait until 2.5 alpha's out so I can mention _its_ feechurz in a mostly-2.4 book... meaning the 2nd ed of the Nutshell may be almost a year away... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: up to date books?
One of my most popular talks is "re-learning Python" -- can be anywhere between 1 and 4 hours, depending on level of detail -- it's all about the changes 1.5.2 -> today's Python, why they came about and why you would want to use them... Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Unfortunate newbie questions!
Alessandro Bottoni wrote: ... > > - In college, I came to admire the Schaum's Outline book > >approach--again heavy on problems and solutions! What's > >the closest Python equivalent? > > Maybe this: > > Python Cookbook > Alex Martelli, David Ascher > O'Reilly I'd rather suggest the 2nd edition, who's by Alex Martelli, Anna Martelli Ravenscroft, and David Ascher -- it IS a better book, believe me. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Rational numbers
On Feb 23, 12:00 pm, [EMAIL PROTECTED] wrote: ... > > > + gmpy is looking pretty unmaintained (dead) to me (newest update of > > > cvs 10 months ago). > > I worked withAlex Martelli(gmpy's maintainer) to fix a bug found by > mensanator. With Alex's permission, I released it as gmpy 1.04a. Alex > has not updated cvs with the fix. Heh, I see why one might get that impression -- I'm in the process of moving gmpy from sourceforge (where I find it harder and harder, and ever more problematic, to work) to code.google.com 's new hosting facility -- gmpy 1.02 prerelease (more updated than that "1.04a", and particularly including your fix, Case) is already available at http://code.google.com/p/gmpy/ but I have made no official announcement yet (partly because what's available is yet limited: sources, and binaries for Python 2.3, 2.4 and 2.5 but only for MacOSX 10.4 on Macs with intel processors)... building binaries for Windows (not having a Windows machine or development system) or Universal binaries for the Mac (due to problems building Universal versions of the underlying GMP in its latest, 4.2 incarnation... I'm running out of PPC-based Macs, and have none left with MaxOSX 10.3...) is much more problematic for me. To call this (Google Code) release 1.02, with a "1.04" (?) out from another source, may be confusing, but I'd rather not "force" the number upwards I do have one new co-owner on the Google Code "version" of gmpy (Chip Turner, once author of a similar GMP wrapper for perl, now a Python convert and a colleague of mine) but I suspect that won't make the building of Windows (and Universal Mac) binaries much easier. If anybody who has easy access to Microsoft's MSVC++.NET (and is willing to try building GMP 4.2 with/for it), or a PPC Mac with XCode installed (possibly with MacOSX 10.3...), wants to volunteer to build "the missing binaries" for the platforms that the current owners of gmpy can't easily support, we could complete, test and release the definitive 1.02, and move on with the development (I could get enthusiastic about this again, if I could develop just the sources, and the binaries for the one architecture I really use -- Macs w/intel -- rather than strive each time with binaries for architectures that are quite a pain for me...!-). Anybody who's interested in helping out is welcome to mail me and/or use the "wiki" and "issues" entry of the Google Code gmpy site... Thanks, Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Rational numbers
On Feb 23, 2:52 pm, [EMAIL PROTECTED] wrote: > > Am I hallucinating? Didn't I see at least some version > > of gmpy for Python 2.5 on SourceForge awhile back? > > I distinctly remember thinking that I don't have to > > direct people to your site, but SourceForge is not > > showing anything beyond vesion 1.01 for Python 2.4. > > Alex released versions 1.02 and 1.03 as CVS updates only. I think he > may have made an announcement that 1.02 included alpha support for > Python 2.5. 1.04a is 1.03 with one additional fix. I don't think there > has been an official release, though. Right: apparently sourceforce doesn't want me to do "releases" any more (quite apart from the utter mess that doing a "release" on sourceforce always was and still is), though I can still update the cvs repository -- that's part of why I'm moving to Google Code hosting. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Rational numbers
On Feb 23, 3:44 pm, [EMAIL PROTECTED] wrote: ... > I can keep building gmpy for Windows. I actually use MINGW since > getting GMP compiled under MSVC is "challanging". I should be able to > build new binaries for Windows this weekend. And I would be happy to > point everyone to a real release. Great! May I add you as a Member to the Google Code gmpy project? After which, you should be able to use svn to get the latest sources, make fixes, etc, etc -- including (if I understand the Google Code mechanics correctly) simply uploading the Windows installer or whatever, if it passes all tests (formal and informal) satisfactorily. Please don't use the "1.02 prerelease" sources zip -- the SVN trunk is more updated, I'll make a "1.02 definitive" sources zip once we have gmpy built and working correctly on all variants of Windows and Mac that we're going to support (I suggest that the binaries be made for Python 2.3, 2.4 and 2.5, for Windows, Mac intel and Mac PPC -- unless we can make Mac Universal work, but I'm finding that quite problematic... a PPC Mac somewhere I shd be able to find:-). Thanks, Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Rational numbers
On Feb 24, 12:25 am, Toby A Inkster <[EMAIL PROTECTED]> wrote: > aleaxit wrote: > > If anybody who has easy access to Microsoft's MSVC++.NET (and is willing > > to try building GMP 4.2 with/for it), or a PPC Mac with XCode installed > > (possibly with MacOSX 10.3...) > > I'm writing this message on a MacOS 10.3.9 box with Xcode 1.5 (gcc 3.3) > installed. If you tell me how, I'd be happy to compile it for you. > > Contact me through the feedback form on the site below. Thanks, but unfortunately getting GMP 4.2 built right on any platform is never a trivial task -- GMP's maintainer is apparently actively hostile to any attempts of making fixes to GMP to make it build correctly on MAC OS X, in particular. I have a correspondent who thinks he's got a working patch (for PPC on MacOSX 10.4, at least); he's very busy but I hope he'll send it to me eventually. gmpy itself is or should be pretty trivial to build on any platform (and I'll always happily accept any fixes that make it better on any specific platform, since it's easy to make them conditional so they'll apply to that platform only), but the underlying GMP is anything but:- (. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Rational numbers
On Feb 25, 3:09 pm, Fernando Perez <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > gmpy itself is or should be pretty trivial to build on any platform > > (and I'll always happily accept any fixes that make it better on any > > specific platform, since it's easy to make them conditional so they'll > > apply to that platform only), but the underlying GMP is anything but:- > > (. > > Alex, have you had a look at SAGE? > > http://modular.math.washington.edu/sage/ > > it uses GMP extensively, so they've had to patch it to work around these > issues. You can look at the SAGE release (they package everything as the > original tarball + patches) for the GMP-specific stuff you need, though I > suspect you'll still want to play with SAGE a little bit :). It's a mighty > impressive system. Thanks Fernando, I will take a look at that. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: gmpy moving to code.google.com
On Feb 27, 9:10 am, "Daniel Nogradi" <[EMAIL PROTECTED]> wrote: > > > Hi Alex, > > > > I did another test, this time with python 2.4 on suse and things are > > > worse than in the previous case (which was python 2.5 on fedora 3), > > > ouput of 'python gmp_test.py' follows: > > > Interesting! gmpy interacts with decimal.Decimal by "monkey- > > patching" that class on the fly; clearly the monkey-patching isn't > > working with 2.4 on SuSE, so all the addition attempts are failing > > (all 6 of them). > > > So the issue is finding out why this strategy is failing there, while > > succeeding on other Linux distros, Mac, and Windows. > > > To that end, I have added a feature in the latest svn trunk (revision > > 11) to set gmpy's own options.debug flag from an environment variable > > named GMPY_DEBUG at startup (if that environment variable is set). > > > If you could please svn up and rebuild, then running with GMPY_DEBUG > > set in the environment should give something like: > > > brain:~/gmpy alex$ GMPY_DEBUG=1 python -c 'import gmpy' 2>&1 | tail -5 > > mp_allocate( 4->8 ) > > mp_allocate( 4->8 ) ->0x60b8b0 > > gmpy_module at 0x63390 > > gmpy_module imported decimal OK > > gmpy_module tweaked decimal OK > > > This is the expected behavior when module decimal is present, while, > > when it's absent, you should see something like: > > > brain:~/gmpy alex$ GMPY_DEBUG=1 python2.3 -c 'import gmpy' 2>&1 | > > tail -5 > > Initing new not in zcache > > mp_allocate( 4->8 ) > > mp_allocate( 4->8 ) ->0x3017d0 > > gmpy_module at 0x6de70 > > gmpy_module could not import decimal > > > In each case, what matters is the last line or two after "gmpy_module > > at" -- the rest of the copious debugging output is irrelevant here. > > > Module decimal is expected to be present from 2.4 forward (though it > > could also be explicitly installed on 2.3). However, from the test > > failures you report, it looks like SuSE's 2.4 does not have decimal > > available for importing when gmpy is starting up -- so I'd like to > > confirm that first. > > > If it's confirmed, it will be interesting to discover how this > > happens (but that requires a SuSE installation, which I don't have) > > and secondarily what is gmpy to do about it -- maybe offer a warning > > on startup when module decimal is unexpectedly not importable but > > then skip the relevant unittests in that case? (Note that the tests > > ARE already skipped if module decimal is not importable _at test > > time_ -- what's really weird is that apparently on SuSE decimal CAN > > be imported by the tests but CANNOT be imported earlier while gmpy is > > loading, which is truly puzzling). > > > I'd appreciate reports about this behavior on as many Python/Linux > > installations as possible -- yours, of course (to check my guess that > > the problem is that decimal can't be imported while gmpy is loading), > > but also others' (to see how widespread the problem is, etc, etc). > > > Thanks again for reporting this, and thanks in advance to anybody > > who'll lend a hand in tracking down this little strangeness!!! > > Okay, here is a summary. The notation is: > > platform version python version debug unittest > > where debug will be either 'pass' or 'fail' if that particular > platform and python version passes or fails the GMPY_DEBUG=1 > importing/tweaking test. Unittest will also be 'pass' or 'fail' if the > full unittesting passes or fails respectively. > > Fedora 3 python 2.5passpass > Fedora 3 python 2.4passfail > Fedora 3 python 2.3.4 fail pass > Suse 9.3 python 2.4passfail > Suse 10 python 2.4.1 passpass > Suse 10.2(64bit) python 2.5 passfail > > The output from each test is zipped and you can grab it from > here:http://lorentz.leidenuniv.nl/~nogradi/gmpy_test.zip Thanks for all the testing! So, Ziga's next post explains that the 2.4 problems are 2.4.0 bugs fixed since 2.4.1 -- I don't think I can do anything about in gmpy, nor (I think) even if I could should I go to great complications to support old, known-buggy, easily upgradable (I hope) releases of Python. The 2.5 issues have nothing to do with decimal -- they _do_ have to do with 64-bit builds: For the hash(z) issue, I think I know what to do -- instead of claiming I know what the hash value should be (which clearly I don't when it can be either a 32-bit or 64-bit build:-), I'll just claim that the hash value of z is the same as the the hash value of long(z). I have svn committed that change (svn repository for gmpy is now at revision 14) -- could you please svn up and run the tests again (ideally after updating the Python 2.4 installations to 2.4.1 or better, but that's minor, what I'd really need to see would be the results on the 64-bit build... thanks! I _am_ a bit surprised at the other failure, the one of: ix(_g.mpz(sys.maxint)) == sys.maxint where ix is operator.index -- particularly considering th
Re: gmpy moving to code.google.com
On Feb 27, 1:38 pm, "Ziga Seilnacht" <[EMAIL PROTECTED]> wrote: > Alex Martelli wrote: > > On Feb 27, 2007, at 2:59 AM, Daniel Nogradi wrote: > > > > Hi Alex, > > > > I did another test, this time with python 2.4 on suse and things are > > > worse than in the previous case (which was python 2.5 on fedora 3), > > > ouput of 'python gmp_test.py' follows: > > > Interesting! gmpy interacts with decimal.Decimal by "monkey- > > patching" that class on the fly; clearly the monkey-patching isn't > > working with 2.4 on SuSE, so all the addition attempts are failing > > (all 6 of them). > > > So the issue is finding out why this strategy is failing there, while > > succeeding on other Linux distros, Mac, and Windows. > > This is a bug in Python's decimal module in release 2.4.0. It was > fixed > in release 2.4.1: > > http://svn.python.org/view?rev=38708&view=rev Thanks! This was really helpful and saved me a lot of head- scratching. I'm wondering if I should specifically test for 2.4.0 in the tests, and give a clear error message about decimal interoperability with other types being broken in that release and suggesting an upgrade, rather than producing "mysterious" test breakages... done -- I think this may simplify things in the future. Thanks, Alex -- http://mail.python.org/mailman/listinfo/python-list
