Re: [Python-Dev] Special file "nul" in Windows and os.stat
> Sorry, I meant to imply that we would guard FindFirstFile in the same > manner that _stati64 and friends do already (using strpbrk/wcspbrk to > search for "?*" in the path). At that point, you have essentially > duplicated the CRT code with the added improvement of using > GetFileAttributes* to retrieve the high-precision timestamps. So, I > think my opinion has changed now to say: first, use GetFileAttributes*, > and if that fails use _stati64/_wstati64. No. We want to phase out usage of the standard C library wherever we can. Duplicating its logic is fine. Also, I don't think Python should implement its own logic of what a valid file name is - the approach of using strpbrk is flawed. IIRC, some version of the CRT (or some other C library) used GetFileAttributes to determine whether a file name is valid. > While I understand your reasoning, I thought we were letting the > platform decide what are and are not files. This bug appeared because we > are imposing our own notion of what a file is or is not, probably only > by ignorance of the differences of GetFileAttribute* and FindFirstFile. > So, my suggestion is basically a compromise of keeping higher precision > timestamps for paths where GetFileAttribute* works and retaining the old > behavior for all others. Sure, but I really dislike the string parsing that the CRT does (and I don't want to go back to using the CRT for stat-like calls). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Special file "nul" in Windows and os.stat
> Perhaps a note should be added to the docs that the 'existence' of 'nul', > etc, is inconsistent in Windows and hence, at present, in Python. That is a statement that I want to get better confirmation on also. What is the precise condition where Windows (or perhaps just Python?) would claim that nul exists? > In part, it seems to me, that anyone doing Windows-specific stuff should > decide for themselves whether 'nul' exists for their purposes or not. No. The intention of os.path.exists clearly is that if it says that it exists, there is a high chance that you can subsequently open it, and vice versa. Of course, there are other issues, such as timing and permissions, but in general, Python applications should not have to "bypass" the standard library with platform-specific knowledge. It's somewhat unfortunate that os.path.exists() is implemented on top of stat(2), which does much more than finding out whether the file exists. Alas, it is the POSIX tradition that this "ought" to work, so this strategy is just a fact of life. I don't know what the actual use case is for testing "existence" of "nul", but I guess a "natural" problem is that the user says she wants to create a file named "nul", and the application checks whether this is a new file name, which it isn't (it exists in every directory, if I understand correctly). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Request for inclusion in 2.5.2 (5-for-1)
Neal Norwitz wrote: > On Nov 2, 2007 2:23 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >> Neal - where does the 2.5 branch stand at the moment? This would be a >> simple fix to slip into 2.5.2 if there's still time. > > I'm not sure if this was before my last status mail. We are hoping to > get a release candidate out in a week or two. It was more than a week but less than two weeks after your last status message, but you hadn't said anything yet about freezing the branch to cut a release candidate - hence my question :) > I agree with Guido that this isn't a bugfix and therefore shouldn't be > backported to 2.5. I was actually referring to the contextmanager bug with that comment - I was just a little vague with my pronouns. All sorted now though. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] XML codec?
I have a patch ready (http://bugs.python.org/issue1399) that adds an XML codec. This codec implements encoding detection as specified in http://www.w3.org/TR/2004/REC-xml-20040204/#sec-guessing and could be used for the decoding phase of an XML parser. Other use cases are: The codec could be used for transcoding an XML input before passing it to the real parser, if the parser itself doesn't support the encoding in question. A text editor could use the codec to decode an XML file. When the user changes the XML declaration and resaves the file, it would be saved in the correct encoding. I'd like to have this codec in 2.6 and 3.0. Any comments? Servus, Walter ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (10/31/07 - 11/07/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1322 open (+15) / 11560 closed (+17) / 12882 total (+32) Open issues with patches: 418 Average duration of open issues: 684 days. Median duration of open issues: 786 days. Open Issues Breakdown open 1317 (+15) pending 5 ( +0) Issues Created Or Reopened (32) ___ Bug tracker link in about tutorial page is wrong 11/01/07 CLOSED http://bugs.python.org/issue1368created ksjohnson Reference to Python24 path in Python 2.5 doc 11/01/07 CLOSED http://bugs.python.org/issue1369created ksjohnson Doc changes left over after mega-merge from trunk11/01/07 CLOSED http://bugs.python.org/issue1370created gvanrossum Two bsddb tests temporarily commented out in py3k branch 11/01/07 CLOSED http://bugs.python.org/issue1371created gvanrossum py3k zlibmodule.c: int overflow in PyZlib_decompress 11/02/07 http://bugs.python.org/issue1372created PeterW patch, 64bit turn off socket timeout in test_xmlrpc 11/02/07 CLOSED http://bugs.python.org/issue1373created hupp py3k, patch IDLE - minor FormatParagraph bug fix 11/02/07 http://bugs.python.org/issue1374created taleinat patch hotshot IndexError when loading stats11/02/07 http://bugs.python.org/issue1375created ratsberg uu module catches a wrong exception type 11/02/07 CLOSED http://bugs.python.org/issue1376created billiejoex test_import breaks on Linux 11/02/07 http://bugs.python.org/issue1377created gvanrossum py3k fromfd() and dup() for _socket on WIndows11/03/07 http://bugs.python.org/issue1378created roudkerk patch reloading imported modules sometimes fail with 'parent not in sy 11/03/07 CLOSED http://bugs.python.org/issue1379created _doublep py3k, patch fix for test_asynchat and test_asyncore on pep3137 branch11/03/07 CLOSED http://bugs.python.org/issue1380created hupp py3k, patch cmath is numerically unsound 11/03/07 http://bugs.python.org/issue1381created inducer py3k-pep3137: patch for test_ctypes 11/04/07 CLOSED http://bugs.python.org/issue1382created amaury.forgeotdarc py3k, patch Backport abcoll to 2.6 11/04/07 http://bugs.python.org/issue1383created baranguren patch Windows fix for inspect tests11/04/07 CLOSED http://bugs.python.org/issue1384created tiran py3k, patch hmac module violates RFC for some hash functions, e.g. sha51211/04/07 CLOSED http://bugs.python.org/issue1385created jowagner py3k py3k-pep3137: patch to ensure that all codecs return bytes 11/04/07 CLOSED http://bugs.python.org/issue1386created amaury.forgeotdarc py3k, patch py3k-pep3137: patch for hashlib on Windows 11/04/07
Re: [Python-Dev] XML codec?
> Any comments? -1. First, (as already discussed on the tracker,) "xml" is a bad name for an encoding. How would you encode "Hello" "in xml"? Then, I'd claim that the problem that the codec solves doesn't really exist. IOW, most XML parsers implement the auto-detection of encodings, anyway, and this is where architecturally this functionality belongs. For a text editor, much more useful than a codec would be a routine (say, xml.detect_encoding) which performs the auto-detection. Finally, I think the codec is incorrect. When saving XML to a file (e.g. in a text editor), there should rarely be encoding errors, since one could use character references in many cases. Also, the XML spec talks about detecting EBCDIC, which I believe your implementation doesn't. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
