[Python-Dev] Possible small csv.DictReader change
A new issue in the tracker: http://bugs.python.org/issue3436 points out that the csv module's DictReader class doesn't know the fieldnames defined in the file until you've fetched the first row of data. It's fairly easy to change the behavior so that __init__ automatically grabs the fieldnames if they aren't passed into it (I attached a patch) but Raymond commented that __init__() shouldn't read any line(s) from the file, instead preferring a separate method to set the fieldnames attribute. There's the issue though of whether __init__() should implicitly read the fieldnames from the file or if that task should be delegated to a separate method which must be called either by the user or from the next() method. If you have an opinion either way, I'd appreciate it if you added a comment to that issue. Regardless which way this issue plays out, is it something that can be put into 2.6 & 3.0 or does it need to wait at this point? Thanks, Skip ___ 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] Any PEP about 2.6 -> 3000 code transition?
I've added a setup.py to the python-incompatibilities projects code, so adding c-extention modules should now be much easier. I don't do much c-development myself, so I'm not the right person to do this, but anybody that feels like adding C-extensions to this project is more than welcome to do so. Just mail me for write access. http://code.google.com/p/python-incompatibility/ ___ 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] Matrix product
On Sun, 27 Jul 2008 02:23:11 am [EMAIL PROTECTED] wrote: > How about just making a matrix multiply function that can take many > arguments? I think this is pretty readable: > > mmul(a, b, c, d) > > Additionally, mmul could then optimize the order of the > multiplications (e.g., depending the dimensions of the matrices, it > may be much more efficient to perform a*((b*c)*d) rather than > ((a*b)*c)*d). But be careful there: matrix multiplication is associative, so that a*b*c = (a*b)*c = a*(b*c), but that doesn't necessarily apply once the elements of the matrices are floats. For instance, a*(b*c) might underflow some elements to zero, while multiplying (a*b)*c does not. As a general rule, compilers should not mess with the order of floating point calculations. Also, some classes that people might want to multiply may not be associative even in principle. E.g. the vector cross product: (a*b)*c != a*(b*c) in general. I think a product() function that multiplies the arguments from left to right would be useful. But it won't solve the problems that people want custom operators to solve. I'm not even sure if it will solve the problem of matrix multiplication. -- Steven. ___ 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] Matrix product
The desire for a new operator for matrix mutltiplication is because binary prefix operators are horrible for expressin this kind of thing, right? Stuff like this is hard to write, read, and debug (especially when checking it against an infix formula): mmul(mmul(mmul(a, b), c), d) How about just making a matrix multiply function that can take many arguments? I think this is pretty readable: mmul(a, b, c, d) Additionally, mmul could then optimize the order of the multiplications (e.g., depending the dimensions of the matrices, it may be much more efficient to perform a*((b*c)*d) rather than ((a*b)*c)*d). (please forgive typos--writing this on a smartphone) -- Daniel Stutzbach ___ 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] Infix operators
Sebastien Loisel wrote: However, just for posterity (and I'm not going to pursue the argument further than this), I'll say this. The problem of determining the meaning (or overridability or whatever) of x=4$6 is the same as the problem of determining the meaning of x=fooz(4,6). Since it's not a good argument against user-defined functions, I don't see it as a good argument against user-defined operators. The namespace of usefully mnemonic function names is infinitely larger than that of usefully mnemonic punctuation marks. User-defined functions are good, but once you have those there is no reason to have user-defined operators *as well*. Cheers, Nick. ___ 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] Status of mingw and Python 2.6 ?
Jim Kleckner wrote: > I gave it a try with cygwin-hosted mingw just to see > if that would work as an alternative to VS2008/VC9 to > figure out some linkage problems. > > I tried: > python setup.py build_ext --compiler mingw32 > > and got a version string issue noted below which > rejects the version string printed from the loader > ld as an inappropriate form. > > I seem to recall that mingw was expected to work with 2.6. > Is it? > [...] > > File "c:\Python26\lib\distutils\version.py", line 107, in parse >raise ValueError, "invalid version number '%s'" % vstring > ValueError: invalid version number '2.18.50.20080523' There are actually two problems with MinGW. Your issue is the same as See http://bugs.python.org/issue2234 But MinGW is also not completely compatible with the msvcr90.dll runtime: http://bugs.python.org/issue3308 For example, if the extension module contains standard date functions (using time_t), it won't load. -- Amaury Forgeot d'Arc ___ 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
