Re: [Python-Dev] Modules of plat-* directories
There are open issues related to plat-XXX. Le Lundi 24 Octobre 2011 00:03:42 Martin v. Löwis a écrit : no, we make no changes to them unless a user actually requests a change Matthias Klose asked for socket SIO* constants in september 2006 (5 years ago). http://bugs.python.org/issue1565071 I would prefer to see such constants in the socket module. On a specific system, these constants are not just part of the API - they are part of the ABI. So a system vendor cannot just change their values. Once defined, they must stay fixed forever. Thiemo Seufer noticed that the linux2 platform definition is incorrect for several architectures, namely Alpha, PA-RISC(hppa), MIPS and SPARC. in september 2008 (3 years ago). He proposed to add a sublevel: Lib/plat- linux2/CDROM.py would become: - Lib/plat-linux2-alpha/CDROM.py - Lib/plat-linux2-hppa/CDROM.py - Lib/plat-linux2-mips/CDROM.py, - Lib/plat-linux2-sparc/CDROM.py - (and a default for other platforms like Intel x86?) = http://bugs.python.org/issue3990 I really don't like this idea (of adding the architecture in the directory name) :-p IMO plat-XXX is wrong by design. It would be better if at least these files were regenerated at build, but Martin doesn't want to regenerate them. And there is still the problem of Mac OS X which embed 3 binarires for 3 architectures in the same FAT file. Victor ___ 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] Deprecation policy
Hi, our current deprecation policy is not so well defined (see e.g. [0]), and it seems to me that it's something like: 1) deprecate something and add a DeprecationWarning; 2) forget about it after a while; 3) wait a few versions until someone notices it; 4) actually remove it; I suggest to follow the following process: 1) deprecate something and add a DeprecationWarning; 2) decide how long the deprecation should last; 3) use the deprecated-remove[1] directive to document it; 4) add a test that fails after the update so that we remember to remove it[2]; Other related issues: PendingDeprecationWarnings: * AFAIK the difference between PDW and DW is that PDW are silenced by default; * now DW are silence by default too, so there are no differences; * I therefore suggest we stop using it, but we can leave it around[3] (other projects might be using it for something different); Deprecation Progression: Before, we more or less used to deprecated in release X and remove in X+1, or add a PDW in X, DW in X+1, and remove it in X+2. I suggest we drop this scheme and just use DW until X+N, where N is =1 and depends on what is being removed. We can decide to leave the DW for 2-3 versions before removing something widely used, or just deprecate in X and remove in X+1 for things that are less used. Porting from 2.x to 3.x: Some people will update directly from 2.7 to 3.2 or even later versions (3.3, 3.4, ...), without going through earlier 3.x versions. If something is deprecated on 3.2 but not in 2.7 and then is removed in 3.3, people updating from 2.7 to 3.3 won't see any warning, and this will make the porting even more difficult. I suggest that: * nothing that is available and not deprecated in 2.7, will be removed until 3.x (x needs to be defined); * possibly we start backporting warnings to 2.7 so that they are visible while running with -3; Documenting the deprecations: In order to advertise the deprecations, they should be documented: * in their doc, using the deprecated-removed directive (and possibly not the 'deprecated' one); * in the what's new, possibly listing everything that is currently deprecated, and when it will be removed; Django seems to do something similar[4]. (Another thing I would like is a different rending for deprecated functions. Some part of the docs have a deprecation warning on the top of the section and the single functions look normal if you miss that. Also while linking to a deprecated function it would be nice to have it rendered with a different color or something similar.) Testing the deprecations: Tests that fail when a new release is made and the version number is bumped should be added to make sure we don't forget to remove it. The test should have a related issue with a patch to remove the deprecated function and the test. Setting the priority of the issue to release blocker or deferred blocker can be done in addition/instead, but that works well only when N == 1 (the priority could be updated for every release though). The tests could be marked with an expected failure to give some time after the release to remove them. All the deprecation-related tests might be added to the same file, or left in the test file of their module. Where to add this: Once we agree about the process we should write it down somewhere. Possible candidates are: * PEP387: Backwards Compatibility Policy[5] (it has a few lines about this); * a new PEP; * the devguide; I think having it in a PEP would be good, the devguide can then link to it. Best Regards, Ezio Melotti [0]: http://bugs.python.org/issue13248 [1]: deprecated-removed doesn't seem to be documented in the documenting doc, but it was added here: http://hg.python.org/cpython/rev/03296316a892 [2]: see e.g. http://hg.python.org/cpython/file/default/Lib/unittest/test/test_case.py#l1187 [3]: we could also introduce a MetaDeprecationWarning and make PendingDeprecationWarning inherit from it so that it can be used to pending-deprecate itself. Once PendingDeprecationWarning is gone, the MetaDeprecationWarning will become useless and can then be used to meta-deprecate itself. [4]: https://docs.djangoproject.com/en/dev/internals/deprecation/ [5]: http://www.python.org/dev/peps/pep-0387/ ___ 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] Deprecation policy
On Mon, 24 Oct 2011 15:58:11 +0300 Ezio Melotti ezio.melo...@gmail.com wrote: I suggest to follow the following process: 1) deprecate something and add a DeprecationWarning; 2) decide how long the deprecation should last; 3) use the deprecated-remove[1] directive to document it; 4) add a test that fails after the update so that we remember to remove it[2]; This sounds like a nice process. PendingDeprecationWarnings: * AFAIK the difference between PDW and DW is that PDW are silenced by default; * now DW are silence by default too, so there are no differences; * I therefore suggest we stop using it, but we can leave it around[3] Agreed as well. [3]: we could also introduce a MetaDeprecationWarning and make PendingDeprecationWarning inherit from it so that it can be used to pending-deprecate itself. Once PendingDeprecationWarning is gone, the MetaDeprecationWarning will become useless and can then be used to meta-deprecate itself. People may start using MetaDeprecationWarning to deprecate their metaclasses. It sounds wrong to deprecate it. Regards Antoine. ___ 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] Case consistency [was: Re: [Python-checkins] cpython: Cleanup code: remove int/long idioms and simplify a while statement.]
Is there a reason to check for
if s[:5] == 'pass ' or s[:5] == 'PASS ':
instead of
if s[:5].lower() == 'pass'
?
If so, it should be documented; otherwise, I would rather see the more
inclusive form, that would also allow things like Pass
-jJ
On Sun, Oct 23, 2011 at 4:21 PM, florent.xicluna
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/67053b135ed9
changeset: 73076:67053b135ed9
user: Florent Xicluna florent.xicl...@gmail.com
date: Sun Oct 23 22:11:00 2011 +0200
summary:
Cleanup code: remove int/long idioms and simplify a while statement.
diff --git a/Lib/ftplib.py b/Lib/ftplib.py
--- a/Lib/ftplib.py
+++ b/Lib/ftplib.py
@@ -175,10 +175,8 @@
# Internal: sanitize a string for printing
def sanitize(self, s):
- if s[:5] == 'pass ' or s[:5] == 'PASS ':
- i = len(s)
- while i 5 and s[i-1] in {'\r', '\n'}:
- i = i-1
+ if s[:5] in {'pass ', 'PASS '}:
+ i = len(s.rstrip('\r\n'))
s = s[:5] + '*'*(i-5) + s[i:]
return repr(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] Deprecation policy
On Mon, Oct 24, 2011 at 06:17, Antoine Pitrou solip...@pitrou.net wrote: On Mon, 24 Oct 2011 15:58:11 +0300 Ezio Melotti ezio.melo...@gmail.com wrote: I suggest to follow the following process: 1) deprecate something and add a DeprecationWarning; 2) decide how long the deprecation should last; 3) use the deprecated-remove[1] directive to document it; 4) add a test that fails after the update so that we remember to remove it[2]; This sounds like a nice process. I have thought about this extensively when I did the stdlib reorg for Python 3, and the only difference from approach Ezio's is proposing was I was thinking of introducing a special deprecate() function to warnings or something that took a Python version argument so it would automatically turn into an error once the version bump occurred. But then I realized other apps wouldn't necessarily care, so short of adding an argument which let people specify a different version number to compare against, I kind of sat on the idea. I also thought about specifying when to go from PendingDeprecationWarning to DeprecationWarning, but as has been suggested, PendingDeprecationWarning is not really useful to the core anymore since But adding something to test.support for our tests which requires a specified version # would also work and be less invasive to users, eg. with test.support.deprecated(remove_in='3.4'): deprecated_func() And obviously if we don't plan on removing the feature any time soon, the test can specify Python 4.0 as the removal version. But the important thing is to require some specification in the test so we don't forget to stick to our contract of when to remove something. P.S.: Did we ever discuss naming py3k Python 4 instead, in honor of King Arthur from Holy Grail not being able to ever count straight to three (eg. the holy hand grenade scene)? Maybe we need to have the next version of Python be Python 6 since the Book of Armaments says you should have 4, and 5 is right out. =) -Brett PendingDeprecationWarnings: * AFAIK the difference between PDW and DW is that PDW are silenced by default; * now DW are silence by default too, so there are no differences; * I therefore suggest we stop using it, but we can leave it around[3] Agreed as well. [3]: we could also introduce a MetaDeprecationWarning and make PendingDeprecationWarning inherit from it so that it can be used to pending-deprecate itself. Once PendingDeprecationWarning is gone, the MetaDeprecationWarning will become useless and can then be used to meta-deprecate itself. People may start using MetaDeprecationWarning to deprecate their metaclasses. It sounds wrong to deprecate it. Regards Antoine. ___ 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/brett%40python.org ___ 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] Use our strict mbcs codec instead of the Windows ANSI API
Hi, I propose to raise Unicode errors if a filename cannot be decoded on Windows, instead of creating a bogus filenames with questions marks. Because this change is incompatible with Python 3.2, even if such filenames are unusable and I consider the problem as a (Python?) bug, I would like your opinion on such change before working on a patch. -- Windows works internally on Unicode strings since Windows 95 (or something like that), but provides also an ANSI API using the ANSI code page and byte strings for backward compatibility. It was already proposed to drop completly the bytes API in our nt (os) module, but it may break the Python backward compatibility (and it is difficult to list Python programs using the bytes API to access the file system). The ANSI API uses MultiByteToWideChar (decode) and WideCharToMultiByte (encode) functions in the default mode (flags=0): MultiByteToWideChar() replaces undecodable bytes by '?' and WideCharToMultiByte() ignores unencodable characters (!!!). This behaviour produces invalid filenames (see for example the issue #13247) and *the user is unable to detect codec errors*. In Python 3.2, I changed the MBCS codec to make it strict: it raises a UnicodeEncodeError if a character cannot be encoded to the ANSI code page (e.g. encode Ł to cp1252) and a UnicodeDecodeError if a character cannot be decoded from the ANSI code page (e.g. b'\xff' from cp932). I propose to reuse our MBCS codec in strict mode (error handler=strict), to notice directly encode/decode errors, with the Windows native (wide character) API. It should simplify the source code: replace 2 versions of a function by 1 version + optional code to decode arguments and/or encode the result. -- Read also the previous thread: [Python-Dev] Byte filenames in the posix module on Windows Wed Jun 8 00:23:20 CEST 2011 http://mail.python.org/pipermail/python-dev/2011-June/111831.html -- FYI I patched again Python MBCS codec: it now handles correclty ignore and replace mode (to encode and decode), but now also supports any error handler. -- We might use the PEP 383 to store undecoable bytes as surrogates (U+DC80- U+DCFF). But the situation is the opposite of the situtation on UNIX: on Windows, the problem is more on encoding (text-bytes) than on decoding (bytes-text). On UNIX, problems occur when the system is misconfigured (e.g. wrong locale encoding). On Windows, problems occur when your application uses the old (ANSI) API, whereas your filesystem is fully Unicode compliant and you created Unicode filenames with a program using the new (Windows) API. Only few programs are fully Unicode compliant. A lot of programs fail if a filename cannot be encoded to the ANSI code page (just 2 examples: Mercurial and Visual Studio). Victor ___ 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] Use our strict mbcs codec instead of the Windows ANSI API
On Tue, Oct 25, 2011 at 8:57 AM, Victor Stinner victor.stin...@haypocalc.com wrote: The ANSI API uses MultiByteToWideChar (decode) and WideCharToMultiByte (encode) functions in the default mode (flags=0): MultiByteToWideChar() replaces undecodable bytes by '?' and WideCharToMultiByte() ignores unencodable characters (!!!). This behaviour produces invalid filenames (see for example the issue #13247) and *the user is unable to detect codec errors*. In Python 3.2, I changed the MBCS codec to make it strict: it raises a UnicodeEncodeError if a character cannot be encoded to the ANSI code page (e.g. encode Ł to cp1252) and a UnicodeDecodeError if a character cannot be decoded from the ANSI code page (e.g. b'\xff' from cp932). I propose to reuse our MBCS codec in strict mode (error handler=strict), to notice directly encode/decode errors, with the Windows native (wide character) API. It should simplify the source code: replace 2 versions of a function by 1 version + optional code to decode arguments and/or encode the result. So we'd be taking existing failures that appear at whatever point the corrupted filename is used and replacing them with explicit failures at the point where the offending string is converted to or from encoded bytes? That sounds reasonable to me, and a lot closer to the way Python behaves on POSIX based systems. Regards, 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] memcmp performance
-On [20111024 09:22], Stefan Behnel (stefan...@behnel.de) wrote:I agree. Given that the analysis shows that the libc memcmp() isparticularly fast on many Linux systems, it should be up to the Pythonpackage maintainers for these systems to set that option externally throughthe optimisation CFLAGS.Indeed, this is how I constructed my Python 3.3 and Python 2.7 :setenv CFLAGS '-fno-builtin-memcmp'just before I configured.I would like to revisit changing unicode_compare: adding aspecial arm for using memcmp when the "unicode kinds" are thesame will only work in two specific instances:(1) the strings are the same kind, the char size is 1 * We could add THIS to unicode_compare, but it seems extremely specialized by itself(2) the strings are the same kind, the char size is 1, and checking for equality * Since unicode_compare can't detect equality checking, we can't really add this to unicode_compare at allThe problem is, of course, that memcmp won't compare for less-thanor greater-than correctly (unless on a BIG ENDIAN machine) forchar sizes of 2 or 4.If we wanted to put memcmp in unicodeobject.c, it would probably needto go into PyUnicode_RichCompare (so we would have some more semanticinformation). I may try to put together a patch for that, if peoplethink that's a good idea? It would be JUST adding a call to memcmpfor two instances specified above.From: Jeroen Ruigrok van der Werven asmo...@in-nomine.orgIn the same stretch, stuff like this needs to be documented. Packagemaintainers cannot be expected to follow each and every mailinglist's postsfor nuggets of information like this. Been there, done that, it's impossibleto keep track.I would like to second that: the whole point of a Makefile/configurationfile is to capture knowledge like this so it doesn't get lost.I would prefer the option would be part of a standard build Pythondistributes, but as long as the information gets captured SOMEWHEREso that (say) Fedora Core 17 has Python 2.7 built with -fno-builtin-memcmp,I would be happy. Gooday, Richie___ 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] Use our strict mbcs codec instead of the Windows ANSI API
+1 from me! Mark On 25/10/2011 9:57 AM, Victor Stinner wrote: Hi, I propose to raise Unicode errors if a filename cannot be decoded on Windows, instead of creating a bogus filenames with questions marks. Because this change is incompatible with Python 3.2, even if such filenames are unusable and I consider the problem as a (Python?) bug, I would like your opinion on such change before working on a patch. -- Windows works internally on Unicode strings since Windows 95 (or something like that), but provides also an ANSI API using the ANSI code page and byte strings for backward compatibility. It was already proposed to drop completly the bytes API in our nt (os) module, but it may break the Python backward compatibility (and it is difficult to list Python programs using the bytes API to access the file system). The ANSI API uses MultiByteToWideChar (decode) and WideCharToMultiByte (encode) functions in the default mode (flags=0): MultiByteToWideChar() replaces undecodable bytes by '?' and WideCharToMultiByte() ignores unencodable characters (!!!). This behaviour produces invalid filenames (see for example the issue #13247) and *the user is unable to detect codec errors*. In Python 3.2, I changed the MBCS codec to make it strict: it raises a UnicodeEncodeError if a character cannot be encoded to the ANSI code page (e.g. encode Ł to cp1252) and a UnicodeDecodeError if a character cannot be decoded from the ANSI code page (e.g. b'\xff' from cp932). I propose to reuse our MBCS codec in strict mode (error handler=strict), to notice directly encode/decode errors, with the Windows native (wide character) API. It should simplify the source code: replace 2 versions of a function by 1 version + optional code to decode arguments and/or encode the result. -- Read also the previous thread: [Python-Dev] Byte filenames in the posix module on Windows Wed Jun 8 00:23:20 CEST 2011 http://mail.python.org/pipermail/python-dev/2011-June/111831.html -- FYI I patched again Python MBCS codec: it now handles correclty ignore and replace mode (to encode and decode), but now also supports any error handler. -- We might use the PEP 383 to store undecoable bytes as surrogates (U+DC80- U+DCFF). But the situation is the opposite of the situtation on UNIX: on Windows, the problem is more on encoding (text-bytes) than on decoding (bytes-text). On UNIX, problems occur when the system is misconfigured (e.g. wrong locale encoding). On Windows, problems occur when your application uses the old (ANSI) API, whereas your filesystem is fully Unicode compliant and you created Unicode filenames with a program using the new (Windows) API. Only few programs are fully Unicode compliant. A lot of programs fail if a filename cannot be encoded to the ANSI code page (just 2 examples: Mercurial and Visual Studio). Victor ___ 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/skippy.hammond%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
[Python-Dev] Use our strict mbcs codec instead of the Windows ANSI API
Victor Stinner writes: I propose to raise Unicode errors if a filename cannot be decoded on Windows, instead of creating a bogus filenames with questions marks. By bogus you mean sometimes (?) invalid and the OS will refuse to use them, causing a later hard-to-diagnose exception, rather than not what the user thinks he wants, right? In the hard errors case, a hearty +1 (I'm dealing with this in an experimental version of XEmacs and it's a right PITA if the codec doesn't complain). Backward compatibility is important, but here the costs of fixing such bugs outweigh the value of bug-compatibility. In the latter (doing things behind the users back rather than actually breaking the program), I'm basically +1 but do worry about backward compatibility. ___ 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] cpython (2.7): Whoops, PyException_GetTraceback() is not documented on 2.7
Georg Brandl wrote: On 10/23/11 20:54, petri.lehtinen wrote: http://hg.python.org/cpython/rev/5c4781a237ef changeset: 73073:5c4781a237ef branch: 2.7 parent: 73071:11da12600f5b user:Petri Lehtinen pe...@digip.org date:Sun Oct 23 21:52:10 2011 +0300 summary: Whoops, PyException_GetTraceback() is not documented on 2.7 If it exists there, why not document it instead? :) Hmm, an interesting idea. I'll see what I can do :) Petri ___ 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] cpython (2.7): Whoops, PyException_GetTraceback() is not documented on 2.7
Petri Lehtinen wrote: Georg Brandl wrote: On 10/23/11 20:54, petri.lehtinen wrote: http://hg.python.org/cpython/rev/5c4781a237ef changeset: 73073:5c4781a237ef branch: 2.7 parent: 73071:11da12600f5b user:Petri Lehtinen pe...@digip.org date:Sun Oct 23 21:52:10 2011 +0300 summary: Whoops, PyException_GetTraceback() is not documented on 2.7 If it exists there, why not document it instead? :) Hmm, an interesting idea. I'll see what I can do :) It seems it doesn't exist on 2.7 after all. I just failed with my hg-fu and thought it was there. Petri ___ 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] memcmp performance
Martin v. Löwis, 23.10.2011 23:44: I am still rooting for -fno-builtin-memcmp in both Python 2.7 and 3.3 ... (after we put memcmp in unicode_compare) -1. We shouldn't do anything about this. Python has the tradition of not working around platform bugs, except if the work-arounds are necessary to make something work at all - i.e. in particular not for performance issues. If this is a serious problem, then platform vendors need to look into it (CPU vendor, compiler vendor, OS vendor). If they don't act, it's probably not a serious problem. In the specific case, I don't think it's a problem at all. It's not that memcmp is slow with the builtin version - it's just not as fast as it could be. Adding a compiler option would put a maintenance burden on Python - we already have way too many compiler options in configure.in, and there is no good procedure to ever take them out should they not be needed anymore. I agree. Given that the analysis shows that the libc memcmp() is particularly fast on many Linux systems, it should be up to the Python package maintainers for these systems to set that option externally through the optimisation CFLAGS. Stefan ___ 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] memcmp performance
-On [20111024 09:22], Stefan Behnel (stefan...@behnel.de) wrote: I agree. Given that the analysis shows that the libc memcmp() is particularly fast on many Linux systems, it should be up to the Python package maintainers for these systems to set that option externally through the optimisation CFLAGS. In the same stretch, stuff like this needs to be documented. Package maintainers cannot be expected to follow each and every mailinglist's posts for nuggets of information like this. Been there, done that, it's impossible to keep track. -- Jeroen Ruigrok van der Werven asmodai(-at-)in-nomine.org / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | GPG: 2EAC625B Only in sleep can one find salvation that resembles Death... ___ 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] cpython (3.2): Issue #13255: wrong docstrings in array module.
On Mon, 24 Oct 2011 13:17:53 +0200 florent.xicluna python-check...@python.org wrote: @@ -2557,7 +2557,7 @@ extend() -- extend array by appending multiple elements from an iterable\n\ fromfile() -- read items from a file object\n\ fromlist() -- append items from the list\n\ -fromstring() -- append items from the string\n\ +frombytes() -- append items from the string\n\ index() -- return index of first occurrence of an object\n\ insert() -- insert a new item into the array at a provided position\n\ pop() -- remove and return item (default last)\n\ @@ -2565,7 +2565,7 @@ reverse() -- reverse the order of the items in the array\n\ tofile() -- write all items to a file object\n\ tolist() -- return the array converted to an ordinary list\n\ -tostring() -- return the array converted to a string\n\ +tobytes() -- return the array converted to a string\n\ The alphabetical order should probably be kept. Regards Antoine. ___ 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
