Re: [Python-Dev] PEP 3144 review.
Peter Moody wrote: what you want is strict=True, just checked in. I've been meaning to send an update to the PEP explaining why this choice was made. I'm hoping this will ameliorate your confusion. If the ip property remains and equality is still broken as Steven describes, then no, it won't really alleviate my concerns. I've also previously registered my objections to using a boolean flag for this instead of a separate method. However, I'll wait and see what the PEP update says before commenting further. 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] PEP 3144 review.
As a side note, I would be in favor of dropping the concept of a mask from the library, and only support a prefix length. -1 IPv6 doesn't support masks at all, and even for IPv4, I think there are conventions (if not RFCs) against using them in a way that does not correspond to a prefix length. Then the module should only support netmasks of the form (say) '255.255.255.224' (equivalent to /27), and reject those like 255.3.255.255. It currently accepts them. Many applications still display netmasks in dot-quad form, and I would be terribly annoyed if I had to count the bits myself before passing it to IPv4Address. I wouldn't ask for that: it should certainly be possible to supply masks. However, I would want to reject masks that don't correspond to a prefix, and have only the prefix length in the internal representation. 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
Re: [Python-Dev] Misc/maintainers.rst
One thing I'd like to see in the list are real names of committers, not tracker names. Of course, people looking for people to assign a bug to should not have to search for the tracker name, so I'd like to make another request (that Brett already made when we switched trackers): Could we *please* have tracker names that match the committer names? I'm opposed. I never type my committer name - I don't even know what it is (martin.v.loewis, martin.vonloewis, martin.von.loewis, something else?). In the tracker, I have to type my account name, so I need to remember. I have been using loewis as my account name in the net for nearly two decades now, so I have little interest in starting to have different account names, now. (This doesn't even need to be done by the individual users, I would volunteer to rename all committer accounts and notify them by email that their name changed. This will also be coordinated with the new names used for Mercurial commits, if a change will be made.) IIUC, there will be relatively little control over Mercurial committer names. Every user will have to configure ~/.hgrc, which should list a single name/email address pair, to be used for all Mercurial repositories. So I put Martin v. Löwis mar...@v.loewis.de into .hgrc, which is my name and my email address. It's not the same as the tracker name or the subversion committer name; it can't possibly be (since it comes from an entirely different namespace). 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
Re: [Python-Dev] PEP 3144 review.
On 14 Sep 2009, at 17:44, Peter Moody wrote:
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance,
can you take a look/make a pronouncement?
x=ipaddr.IPv4Network( '192.168.1.1/240.255.0.0' )
x
IPv4Network('192.168.1.1/16')
You can decide on which bug this shows.
1) parse must raise exception on bad input
2) repr does not show input
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
[Python-Dev] Python build question (fixing pymath.c).
Hello all, I'm looking for advice on how to clean up an ugliness (one that I'm at least partly responsible for) in the Python build setup. Here's the problem: some of the exported functions (e.g. atanh, log1p) in the Python/pymath.c file aren't needed by the Python core at all; they're exported solely for use in the math and cmath modules. Even worse, these exported functions have no '_Py' or 'Py' prefix. Since I'm currently working on adding some oft-requested functions to the math module (gamma, lgamma, erf, ...) it seemed like a good time to clean this up. So I've now got a file Modules/math_support.c that contains some functions needed by both mathmodule.c and cmathmodule.c, as well as a couple of functions only currently needed by the math module. How should I incorporate this file into the build? One obvious solution seems to be to build an extra math_support.so file that's then used by both mathmodule.so and cmathmodule.so. Is this a sensible solution? Are there better ways? A complication to bear in mind is that some users may want to alter Modules/Setup.dist so that either the math module and/or the cmath module is included in the core Python executable. Cluelessly yours, 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] PEP 3144 review.
On Sat, Sep 26, 2009 at 6:34 AM, Barry Scott ba...@barrys-emacs.org wrote:
On 14 Sep 2009, at 17:44, Peter Moody wrote:
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance,
can you take a look/make a pronouncement?
x=ipaddr.IPv4Network( '192.168.1.1/240.255.0.0' )
x
IPv4Network('192.168.1.1/16')
You can decide on which bug this shows.
1) parse must raise exception on bad input
2) repr does not show input
Barry
thank you, Barry, for your continued interest. Since it may have been
lost in the 200+ messages on this topic, issues with the current
implementation can be filed at:
http://code.google.com/p/ipaddr-py/issues/entry
In case you missed it, I'm trying to move discussion of the PEP over
to ipaddr-py-...@googlegroups.com b/c pep-0001 is fairly explicit
about trying to avoid long open-ended discussions. I'm pretty sure bug
reports like this at the end of 200+ messages qualifies as long and
open-ended.
Cheers,
/peter
___
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] Misc/maintainers.rst
Martin v. Löwis wrote: One thing I'd like to see in the list are real names of committers, not tracker names. Of course, people looking for people to assign a bug to should not have to search for the tracker name, so I'd like to make another request (that Brett already made when we switched trackers): Could we *please* have tracker names that match the committer names? I'm opposed. I never type my committer name - I don't even know what it is (martin.v.loewis, martin.vonloewis, martin.von.loewis, something else?). In the tracker, I have to type my account name, so I need to remember. I have been using loewis as my account name in the net for nearly two decades now, so I have little interest in starting to have different account names, now. Same - my tracker is my normal online account name (ncoghlan), while my committer name is my full name (nick.coghlan). Having roundup store an extra field with committer names (and letting people see both names in the user lists on the tracker) seems like a better option than asking us to change our account names. 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 build question (fixing pymath.c).
On Sun, Sep 27, 2009 at 00:21, Mark Dickinson dicki...@gmail.com wrote: Hello all, I'm looking for advice on how to clean up an ugliness (one that I'm at least partly responsible for) in the Python build setup. Here's the problem: some of the exported functions (e.g. atanh, log1p) in the Python/pymath.c file aren't needed by the Python core at all; they're exported solely for use in the math and cmath modules. Even worse, these exported functions have no '_Py' or 'Py' prefix. Since I'm currently working on adding some oft-requested functions to the math module (gamma, lgamma, erf, ...) it seemed like a good time to clean this up. So I've now got a file Modules/math_support.c that contains some functions needed by both mathmodule.c and cmathmodule.c, as well as a couple of functions only currently needed by the math module. How should I incorporate this file into the build? One obvious solution seems to be to build an extra math_support.so file that's then used by both mathmodule.so and cmathmodule.so. Is this a sensible solution? Are there better ways? Are you planning on exposing any of this outside of those two modules? If not then I would change the name to _math.so A complication to bear in mind is that some users may want to alter Modules/Setup.dist so that either the math module and/or the cmath module is included in the core Python executable. If you are mucking with Modules.Setup.dist you better know how to figure out that those two modules depend on another .so. -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] PEP 3144 review.
On Sat, Sep 26, 2009 at 11:08 PM, Nick Coghlan ncogh...@gmail.com wrote: Peter Moody wrote: what you want is strict=True, just checked in. I've been meaning to send an update to the PEP explaining why this choice was made. I'm hoping this will ameliorate your confusion. If the ip property remains and equality is still broken as Steven describes, then no, it won't really alleviate my concerns. I've also previously registered my objections to using a boolean flag for this instead of a separate method. However, I'll wait and see what the PEP update says before commenting further. I've mailed the PEP patch in, hopefully it will be checked in and updated shortly. To be explicit though, unless I'm drastically misreading what you're asking for, I consider the design you're proposing to be broken from a usability perspective (striving for academic/pedantic correctness over accepted practice). I have no intention of adding any sort of AddressWithNetmask classes or making other fundamental design changes you've suggested. If what the community requires is the library you've described, then ipaddr is not that library. Cheers, /peter 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] Fuzziness in io module specs - PEP update proposition V2
Hello Below is a corrected version of the PEP update, adding the start/end indexes proposition and fixing functions signatures. Does anyone disagree with these specifications ? Or can we consider it as a target for the next versions of the io module ? I would have no problem to implement this behaviour in my own pure python FileIO system, however if someone is willing to patch the _fileio implementation, it'd save a lot of time - I most probably won't have the means to setup a C compilation environment under windows and linux, and properly update/test this, before January (when I get freelance...). I launch another thread on other to-be-discussed IO points B-) Regards, Pascal PEP UPDATE for new I/O system - v2 === **Truncate and file pointer semantics** Rationale : The current implementation of truncate() always move the file pointer to the new end of file. This behaviour is interesting for compatibility, if the file has been reduced and the file pointer is now past its end, since some platforms might require 0 = filepointer = filesize. However, there are several arguments against this semantic: * Most common standards (posix, win32…) allow the file pointer to be past the end of file, and define the behaviour of other stream methods in this case * In many cases, moving the filepointer when truncating has no reasons to happen (if we’re extending the file, or reducing it without going beneath the file pointer) * Making 0 = filepointer = filesize a global rule of the python IO module doesn’t seems possible, since it would require modifications of the semantic of other methods (eg. seek() should raise exceptions or silently disobey when asked to move the filepointer past the end of file), and lead to incoherent situations when concurrently accessing files without locking (what if another process truncates to 0 bytes the file you’re writing ?) So here is the proposed semantic, which matches established conventions: *IOBase.truncate(n: int = None) - int* Resizes the file to the size specified by the positive integer n, or by the current filepointer position if n is None. The file must be opened with write permissions. If the file was previously larger than size, the extra data is discarded. If the file was previously shorter than size, its size is increased, and the extended area appears as if it were zero-filled. In any case, the file pointer is left unchanged, and may point beyond the end of file. Note: trying to read past the end of file returns an empty string, and trying to write past the end of file extends it by zero-ing the gap. On rare platforms which don't support file pointers to be beyond the end of file, all these behaviours shall be faked thanks to internal storage of the wanted file pointer position (silently extending the file, if necessary, when a write operation occurs). *Propositions of doc update* *RawIOBase*.read(n: int) - bytes Read up to n bytes from the object and return them. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes. If 0 bytes are returned, and n was not 0, this indicates end of file. If the object is in non-blocking mode and no bytes are available, the call returns None. *RawIOBase*.readinto(b: bytearray, [start: int = None], [end: int = None]) - int start and end are used as slice indexes, so that the bytearray taken into account is actually range = b[start:end] (or b[start:], b[:end] or b[:], depending on the arguments which are not None). Read up to len(range) bytes from the object and store them in b, returning the number of bytes read. Like .read, fewer than len(range) bytes may be read, and 0 indicates end of file if len(range) is not 0. None is returned if a non-blocking object has no bytes available. The length of b is never changed. ___ 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 build question (fixing pymath.c).
On Sun, Sep 27, 2009 at 8:48 AM, Brett Cannon br...@python.org wrote: On Sun, Sep 27, 2009 at 00:21, Mark Dickinson dicki...@gmail.com wrote: [...] So I've now got a file Modules/math_support.c that contains some functions needed by both mathmodule.c and cmathmodule.c, as well as a couple of functions only currently needed by the math module. How should I incorporate this file into the build? One obvious solution seems to be to build an extra math_support.so file that's then used by both mathmodule.so and cmathmodule.so. Is this a sensible solution? Are there better ways? Are you planning on exposing any of this outside of those two modules? No. If not then I would change the name to _math.so That makes sense. A complication to bear in mind is that some users may want to alter Modules/Setup.dist so that either the math module and/or the cmath module is included in the core Python executable. If you are mucking with Modules.Setup.dist you better know how to figure out that those two modules depend on another .so. Sure. I'll at least add a comment pointing out the dependence, though. Thanks, 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] Python 2.7 Mac universal builds seem broken on trunk
On 27 Sep 2009, at 03:12, Ned Deily wrote: In article 90a90a3c-e037-4fca-95d2-a46a5c6dd...@barrys-emacs.org, Barry Scott ba...@barrys-emacs.org wrote: I'm working with http://svn.python.org/projects/python/trunk on Mac OS X 10.6.1 using Apples xcode gcc 4.2.1. When I run the following commands: ./configure --enable-framework --with-universal-archs=32-bit | tee build.config.log make clean all | tee build.make.log I end up with a x86_64 Python image. No matter what I use for archs its always the same. I would expect to see -arch arg to GCC but it is not there. export CFLAG=-arch i386 I should have used CFLAGS... did not work either. Am I doing something wrong or is this broken on trunk? You need to add the enable-universalsdk parameter to configure: ... --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk Thanks that worked with the 10.5 sdk. Be aware, though, that universal build support on 10.6 is a bit of a work in progress as there are still some interesting unexplained universal build issues when building on Snow Leopard (see, for instance, the comments in http://bugs.python.org/issue6957). At the moment, the focus is on getting 2.6.3 out the door and the standard installer for that will be built on 10.5. O.k. 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
[Python-Dev] IO module precisions and exception hierarchy
Found in current io PEP : Q: Do we want to mandate in the specification that switching between reading and writing on a read-write object implies a .flush()? Or is that an implementation convenience that users should not rely on? - it seems that the only important matter is : file pointer positions and bytes/characters read should always be the ones that the user expects, as if there were no buffering. So flushing or not may stay a non-mandatory behaviour, as long as the buffered streams ensures this data integrity. Eg. If a user opens a file in r/w mode, writes two bytes in it (which stay buffered), and then reads 2 bytes, the two bytes read should be those on range [2:4] of course, even though the file pointer would, due to python buffering, still be at index 0. Q from me : What happens in read/write text files, when overwriting a three-bytes character with a single-byte character ? Or at the contrary, when a single chinese character overrides 3 ASCII characters in an UTF8 file ? Is there any system designed to avoid this data corruption ? Or should TextIO classes forbid read+write streams ? IO Exceptions : Currently, the situation is kind of fuzzy around EnvironmentError subclasses. * OSError represents errors notified by the OS via errno.h error codes (as mirrored in the python errno module). errno.h errors (less than 125 error codes) seem to represent the whole of *nix system errors. However, Windows has many more system errors (15000+). So windows errors, when they can't be mapped to one of the errno errors are raises as WindowsError instances (a subclass of OSError), with the special attribute winerror indicating that win32 error code. * IOError are errors raised because of I/O problems, but they use errno codes, like OSError. Thus, at the moment IOErrors rather have the semantic of particular case of OSError, and it's kind of confusing to have them remain in their own separate tree... Furthermore, OSErrors are often used where IOErrors would perfectly fit, eg. in low level I/O functions of the OS module. Since OSErrors and IOErrors are slightly mixed up when we deal with IO operations, maybe the easiest way to make it clearer would be to push to their limits already existing designs. - the os module should only raise OSErrors, whatever the os operation involved (maybe it's already the case in CPython, isn't it ?) - the io module should only raise IOErrors and its subclasses, so that davs can easily take measures depending on the cause of the io failure (except 1 OSError exception, it's already the case in _fileio) - other modules refering to i/o might maybe keep their current (fuzzy) behaviour, since they're more platform specific, and should in the end be replaced by a crossplatform solution (at least I'd love it to happen) Until there, there would be no real benefits for the user, compared to catching EnvironmentErrors as most probably do. But the sweet thing would be to offer a concise but meaningfull IOError hierarchy, so that we can easily handle most specific errors gracefully (having a disk full is not the same level of gravity as simply having another process locking your target file). Here is a very rough beginning of IOError hierarchy. I'd liek to have people's opinion on the relevance of these, as well as on what other exceptions should be distinguished from basic IOErrors. IOError +-InvalidStreamError (eg. we try to write on a stream opened in readonly mode) +-LockingError +-PermissionError (mostly *nix chmod stuffs) +-FileNotFoundError +-DiskFullError +-MaxFileSizeError (maybe hard to implement, happens when we exceed 4Gb on fat32 and stuffs...) +-InvalidFileNameError (filepath max lengths, or ? / : characters in a windows file name...) Regards, Pascal ___ 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] PEP 3144 review.
Dave M. On 27 Sep 2009, at 07:56, Martin v. Löwis mar...@v.loewis.de wrote: As a side note, I would be in favor of dropping the concept of a mask from the library, and only support a prefix length. -1 IPv6 doesn't support masks at all, and even for IPv4, I think there are conventions (if not RFCs) against using them in a way that does not correspond to a prefix length. Then the module should only support netmasks of the form (say) '255.255.255.224' (equivalent to /27), and reject those like 255.3.255.255. It currently accepts them. Many applications still display netmasks in dot-quad form, and I would be terribly annoyed if I had to count the bits myself before passing it to IPv4Address. I wouldn't ask for that: it should certainly be possible to supply masks. However, I would want to reject masks that don't correspond to a prefix, and have only the prefix length in the internal representation. +1 on rejection of netmasks without direct CIDR prefix equivalents. AFAIK Cisco routers accept them but I don't see how they would be useful in practice (unless someone can demonstrate their need for this). 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/drkjam%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] IO module precisions and exception hierarchy
Pascal Chambon wrote: - it seems that the only important matter is : file pointer positions and bytes/characters read should always be the ones that the user expects, as if there were no buffering. That sounds right to me. Q from me : What happens in read/write text files, when overwriting a three-bytes character with a single-byte character ? I think you deserve whatever you get. If you want to be able to overwrite things that accurately, you should be dealing with the stream at the byte level. Here is a very rough beginning of IOError hierarchy. +-InvalidFileNameError (filepath max lengths, or ? / : characters in a windows file name...) This might be a bit too precise. Unix just has EINVAL, which covers any kind of invalid parameter, not just file names. -- Greg ___ 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] PEP 3144 review.
Peter Moody peter at hda3.com writes: To be explicit though, unless I'm drastically misreading what you're asking for, I consider the design you're proposing to be broken from a usability perspective (striving for academic/pedantic correctness over accepted practice). It is certainly not academic correctness, it is concern over the understandibility of the library. The behaviour you are proposing is confusing, and even if you think it is more practical (which I doubt it is), it should still be avoided IMO. While 192.168.1.2/24 may be an accepted notation in some situations, it is not a notation for a *network* but for an (address, mask) pair, or an (address, network) pair. There was a proposal to have a separate parse_address_and_mask method which would return a (Address, Network) tuple, I still don't know why you don't seem to consider it seriously, rather than trying to make the Network class a kind of all-in-one type conflating different concepts. 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
Re: [Python-Dev] IO module precisions and exception hierarchy
Pascal Chambon wrote: Found in current io PEP : Q: Do we want to mandate in the specification that switching between reading and writing on a read-write object implies a .flush()? Or is that an implementation convenience that users should not rely on? - it seems that the only important matter is : file pointer positions and bytes/characters read should always be the ones that the user expects, as if there were no buffering. So flushing or not may stay a non-mandatory behaviour, as long as the buffered streams ensures this data integrity. Eg. If a user opens a file in r/w mode, writes two bytes in it (which stay buffered), and then reads 2 bytes, the two bytes read should be those on range [2:4] of course, even though the file pointer would, due to python buffering, still be at index 0. Q from me : What happens in read/write text files, when overwriting a three-bytes character with a single-byte character ? Or at the contrary, when a single chinese character overrides 3 ASCII characters in an UTF8 file ? Is there any system designed to avoid this data corruption ? Or should TextIO classes forbid read+write streams ? IO Exceptions : Currently, the situation is kind of fuzzy around EnvironmentError subclasses. * OSError represents errors notified by the OS via errno.h error codes (as mirrored in the python errno module). errno.h errors (less than 125 error codes) seem to represent the whole of *nix system errors. However, Windows has many more system errors (15000+). So windows errors, when they can't be mapped to one of the errno errors are raises as WindowsError instances (a subclass of OSError), with the special attribute winerror indicating that win32 error code. * IOError are errors raised because of I/O problems, but they use errno codes, like OSError. Thus, at the moment IOErrors rather have the semantic of particular case of OSError, and it's kind of confusing to have them remain in their own separate tree... Furthermore, OSErrors are often used where IOErrors would perfectly fit, eg. in low level I/O functions of the OS module. Since OSErrors and IOErrors are slightly mixed up when we deal with IO operations, maybe the easiest way to make it clearer would be to push to their limits already existing designs. - the os module should only raise OSErrors, whatever the os operation involved (maybe it's already the case in CPython, isn't it ?) - the io module should only raise IOErrors and its subclasses, so that davs can easily take measures depending on the cause of the io failure (except 1 OSError exception, it's already the case in _fileio) - other modules refering to i/o might maybe keep their current (fuzzy) behaviour, since they're more platform specific, and should in the end be replaced by a crossplatform solution (at least I'd love it to happen) Until there, there would be no real benefits for the user, compared to catching EnvironmentErrors as most probably do. But the sweet thing would be to offer a concise but meaningfull IOError hierarchy, so that we can easily handle most specific errors gracefully (having a disk full is not the same level of gravity as simply having another process locking your target file). Here is a very rough beginning of IOError hierarchy. I'd liek to have people's opinion on the relevance of these, as well as on what other exceptions should be distinguished from basic IOErrors. IOError +-InvalidStreamError (eg. we try to write on a stream opened in readonly mode) +-LockingError +-PermissionError (mostly *nix chmod stuffs) +-FileNotFoundError +-DiskFullError +-MaxFileSizeError (maybe hard to implement, happens when we exceed 4Gb on fat32 and stuffs...) +-InvalidFileNameError (filepath max lengths, or ? / : characters in a windows file name...) Personally I'd love to see a richer set of exceptions for IO errors, so long as they can be implemented for all supported platforms and no information (err number from the os) is lost. I've been implementing a fake 'file' type [1] for Silverlight which does IO operations using local browser storage. The use case is for an online Python tutorial running in the browser [2]. Whilst implementing the exception behaviour (writing to a file open in read mode, etc) I considered improving the exception messages as they are very poor - but decided that being similar to CPython was more important. Michael [1] http://code.google.com/p/trypython/source/browse/trunk/trypython/app/storage.py and http://code.google.com/p/trypython/source/browse/trunk/trypython/app/tests/test_storage.py [2] http://www.trypython.org/ Regards, Pascal ___ 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/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog
Re: [Python-Dev] Fuzziness in io module specs - PEP update proposition V2
Hello, So here is the proposed semantic, which matches established conventions: *IOBase.truncate(n: int = None) - int* [...] I still don't think there is a sufficient benefit in breaking compatibility. If you want the file pointer to remain the same, you can save it first and restore it afterwards manually. *Propositions of doc update* Please open tracker issues for these kinds of suggestions. 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
Re: [Python-Dev] IO module precisions and exception hierarchy
Le Sun, 27 Sep 2009 10:20:23 +0200, Pascal Chambon a écrit :
Q: Do we want to mandate in the specification that switching between
reading and writing on a read-write object implies a .flush()?
It doesn't and shouldn't be mandated in the specification, IMO. An
implementation should be free to optimize out those implicit flush()
calls for performance reasons.
Eg. If a user opens a file in r/w mode, writes two bytes in it (which
stay buffered), and then reads 2 bytes, the two bytes read should be
those on range [2:4] of course, even though the file pointer would, due
to python buffering, still be at index 0.
Actually the raw file pointer would be at index N, where N is at least
the buffer size (say 4096).
However, it is not specified how the raw file pointer behaves when using
a Buffered{Reader, Writer, Random} wrapper over it. The buffered object
is free to do what it wants with the raw stream until flush() is called
(or the file is closed, which calls flush() implicitly).
Even after flush() is called, the raw file pointer can still be at
whatever place, but the raw file contents are consistent with the view
given by the buffered object.
Q from me : What happens in read/write text files, when overwriting a
three-bytes character with a single-byte character ? Or at the contrary,
when a single chinese character overrides 3 ASCII characters in an UTF8
file ? Is there any system designed to avoid this data corruption ? Or
should TextIO classes forbid read+write streams ?
What happens isn't specified, but in practice (with the current
implementation) the overwriting will happen at the byte level, without
any check for correctness at the character level.
Actually, read+write text streams are implemented quite crudely, and
little testing is done of them. The reason, as you discovered, is that
the semantics are too weak, and it is not obvious how stronger semantics
could look like. People wanting to do sophisticated random reads+writes
over a text file should probably handle the encoding themselves and
access the file at the binary level.
Here is a very rough beginning of IOError hierarchy. I'd liek to have
people's opinion on the relevance of these, as well as on what other
exceptions should be distinguished from basic IOErrors.
This deserves its own PEP IMO, although I'm not sure it would be accepted
(ISTR the idea of a detailed IO exception hierarchy was already refused
in the past).
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
Re: [Python-Dev] Fuzziness in io module specs - PEP update proposition V2
Pascal Chambon wrote: Hello Below is a corrected version of the PEP update, adding the start/end indexes proposition and fixing functions signatures. Does anyone disagree with these specifications ? Or can we consider it as a target for the next versions of the io module ? I would have no problem to implement this behaviour in my own pure python FileIO system, however if someone is willing to patch the _fileio implementation, it'd save a lot of time - I most probably won't have the means to setup a C compilation environment under windows and linux, and properly update/test this, before January (when I get freelance...). I launch another thread on other to-be-discussed IO points B-) Regards, Pascal PEP UPDATE for new I/O system - v2 === **Truncate and file pointer semantics** Rationale : The current implementation of truncate() always move the file pointer to the new end of file. This behaviour is interesting for compatibility, if the file has been reduced and the file pointer is now past its end, since some platforms might require 0 = filepointer = filesize. However, there are several arguments against this semantic: * Most common standards (posix, win32…) allow the file pointer to be past the end of file, and define the behaviour of other stream methods in this case * In many cases, moving the filepointer when truncating has no reasons to happen (if we’re extending the file, or reducing it without going beneath the file pointer) * Making 0 = filepointer = filesize a global rule of the python IO module doesn’t seems possible, since it would require modifications of the semantic of other methods (eg. seek() should raise exceptions or silently disobey when asked to move the filepointer past the end of file), and lead to incoherent situations when concurrently accessing files without locking (what if another process truncates to 0 bytes the file you’re writing ?) So here is the proposed semantic, which matches established conventions: *IOBase.truncate(n: int = None) - int* Resizes the file to the size specified by the positive integer n, or by the current filepointer position if n is None. The file must be opened with write permissions. If the file was previously larger than size, the extra data is discarded. If the file was previously shorter than size, its size is increased, and the extended area appears as if it were zero-filled. Instead of than size, perhaps than n. In any case, the file pointer is left unchanged, and may point beyond the end of file. Note: trying to read past the end of file returns an empty string, and trying to write past the end of file extends it by zero-ing the gap. On rare platforms which don't support file pointers to be beyond the end of file, all these behaviours shall be faked thanks to internal storage of the wanted file pointer position (silently extending the file, if necessary, when a write operation occurs). *Propositions of doc update* *RawIOBase*.read(n: int) - bytes Read up to n bytes from the object and return them. Fewer than n bytes may be returned if the operating system call returns fewer than n bytes. If 0 bytes are returned, and n was not 0, this indicates end of file. If the object is in non-blocking mode and no bytes are available, the call returns None. *RawIOBase*.readinto(b: bytearray, [start: int = None], [end: int = None]) - int start and end are used as slice indexes, so that the bytearray taken into account is actually range = b[start:end] (or b[start:], b[:end] or b[:], depending on the arguments which are not None). Read up to len(range) bytes from the object and store them in b, returning the number of bytes read. Like .read, fewer than len(range) bytes may be read, and 0 indicates end of file if len(range) is not 0. None is returned if a non-blocking object has no bytes available. The length of b is never changed. Should an exception be raised if start and/or end are out of range? ___ 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] PEP 3144 review.
Antoine Pitrou writes: There was a proposal to have a separate parse_address_and_mask method which would return a (Address, Network) tuple, I still don't know why you don't seem to consider it seriously, rather than trying to make the Network class a kind of all-in-one type conflating different concepts. Because he thinks about the problem space differently from you. Specifically, AFAICS he does not (maybe even can't) see a reason to distinguish an AddressWithMask from a Network. If so, it's a reasonable API choice for him to choose not to have separate classes to represent such similar concepts. That's all there is to it. I personally do not have a problem with that, except that you apparently can't grasp his way of thinking, and he apparently can't grasp yours. I'm -1 on PEP 3144 primarily because of this communications gap. Secondarily because I agree that it's unnatural that a Network instance can have an arbitrary distinguished address other than those defined in the RFCs (the network and broadcast addresses), especially since it matters to equality comparisons. (But I personally would use ipaddr if it were in the stdlib despite that.) ___ 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] IO module precisions and exception hierarchy
Pascal Chambon wrote: Found in current io PEP : Q: Do we want to mandate in the specification that switching between reading and writing on a read-write object implies a .flush()? Or is that an implementation convenience that users should not rely on? - it seems that the only important matter is : file pointer positions and bytes/characters read should always be the ones that the user expects, as if there were no buffering. So flushing or not may stay a non-mandatory behaviour, as long as the buffered streams ensures this data integrity. Eg. If a user opens a file in r/w mode, writes two bytes in it (which stay buffered), and then reads 2 bytes, the two bytes read should be those on range [2:4] of course, even though the file pointer would, due to python buffering, still be at index 0. +1 Q from me : What happens in read/write text files, when overwriting a three-bytes character with a single-byte character ? Or at the contrary, when a single chinese character overrides 3 ASCII characters in an UTF8 file ? Is there any system designed to avoid this data corruption ? Or should TextIO classes forbid read+write streams ? If the characters are always the same number of bytes) then overwriting could be possible; that would, however, make the behaviour more complicated (sometimes you can, sometimes you can't), so it's probably just simpler to forbid read+write text streams. ___ 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] IO module precisions and exception hierarchy
MRAB python at mrabarnett.plus.com writes: If the characters are always the same number of bytes) then overwriting could be possible; that would, however, make the behaviour more complicated (sometimes you can, sometimes you can't), so it's probably just simpler to forbid read+write text streams. Forbidding them would be gratuitous. There are perfectly safe uses, for example if all writes are appends, or if you use a fixed-size encoding. (and besides, it would break backwards compatibility) 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
Re: [Python-Dev] IO module precisions and exception hierarchy
On Sep 27, 2009, at 4:20 AM, Pascal Chambon wrote: Thus, at the moment IOErrors rather have the semantic of particular case of OSError, and it's kind of confusing to have them remain in their own separate tree... Furthermore, OSErrors are often used where IOErrors would perfectly fit, eg. in low level I/O functions of the OS module. Since OSErrors and IOErrors are slightly mixed up when we deal with IO operations, maybe the easiest way to make it clearer would be to push to their limits already existing designs. How about just making IOError = OSError, and introducing your proposed subclasses? Does the usage of IOError vs OSError have *any* useful semantics? James ___ 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] PEP 3144 review.
I personally do not have a problem with that, except that you apparently can't grasp his way of thinking, and he apparently can't grasp yours. If I was the only one disagreeing it wouldn't be that annoying (except for me :-)). I'm -1 on PEP 3144 primarily because of this communications gap. I must say I have started to lean in that direction, too. If it is not possible to produce a result (a PEP) that solves all major design issues, it will produce the kind of little-liked modules that people have recently complained about in an stdlib-sig thread. 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
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Sun, Sep 27, 2009 at 12:41 AM, Martin v. Löwis mar...@v.loewis.de wrote: Guido van Rossum wrote: I realize I'm late to this party, but this is just a naming issue, right? Not really (AFAIU). For any network, there are two special addresses, one with the last bits all zeros, one with the last bits all ones. We can call them A and B, or network and broadcast, or zeros and ones, or whatever we care. But their definitions are two well-defined functions for all networks (assuming a network is defined as an IP address and a number of bits), even if in an extreme case the functions return the same value. For the broadcast address, it's different, since you might also use it in programming (i.e. when sending broadcasts). So there is no need to look up the broadcast address in the configuration? Don't you have to look up the rest of the network configuration too? (Or otherwise how do you know your network address and the value of /N?) Now, it seems that people will typically use undirected broadcasts (INADDR_BROADCAST). However, I assume there are also applications for directed broadcasts; in this case, it would matter to know the broadcast address of a network. I don't know, and it seems you are not familiar with an actual case either. I would assume that apps doing such low-level work would have direct access to the complete network configuration, of which the broadcast address to use would be a separate argument. The ipaddr library seems most useful for doing manipulations and computations on addresses and networks that may bear no relationship to the current host's configuration -- e.g. off-line verification of firewall configurations, or whatever. What is actually configured on a particular host to be the broadcast address is a separate issue, even if *by convention* in most cases it is given by one of the above functions -- the network object doesn't care, the configuration object is something else (and outside the scope of this PEP). It's a little bit stronger than convention; there are RFCs saying that the all-ones (-1) address has to be the broadcast address. Sure, but what is the status of those RFCs? (Plenty of RFCs are unimplemented or superseded by others etc.) In any case we seem to agree that 'broadcast' is a fine name for the 'all ones' address so I don't want to argue this point any further. :) This is like saying that it is out of scope of the socket protocol whether TCP is the IP protocol 6, and that individual hosts may do it differently - yes, they may, but then everything stops working. Well, except that if al hosts on a closed network were to define their alternate value in the appropriate header, then everything would work (within that closed network!), even Python (which gets the TCP value from the system header too). But I don't think that that is relevant to ipaddr, which has to be able to make decisions about arbitrary IP addresses and networks without having access to the hosts or their configurations. It can only look at the syntax. IMO real life examples don't matter for the definitions of the functions That I agree with. and I would personally be happy to name them network and broadcast, since I know their definitions and their typical uses and these match pretty closely. The expectation should be clearly set that these are pure functions though and do not imply knowledge of the configuration of any given host. That I also agree with. However, there is this issue of /31 networks, where an 8-year-old RFC specifies how to do broadcasts on these. I think RFCs should be considered wherever applicable. Considered wherever applicable, yes. I'm assuming you're talking about RFC 3021 -- which says standards track but I can't find whether it is actually a standard or how widespread its implementation is. It might well be obsolete by now, or widely ignored, or irrelevant outside a few drivers. Another question is whether it *always* applies when a /31 network is used. If not, then we're back to the situation where we can't know the configuration, and declaring the RFC applicable in all cases doesn't make it so. RFC 3021 adds an odd wart to the all ones and all zeros functions (or perhaps only to all ones?). If after further examination of the facts we find that it should be honored, then what do we do for .network and .broadcast on a /32 network? Is that an error or should it just return the one IP address of which the network consists? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PEP 3144 review.
On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
To be explicit though, unless I'm drastically misreading what you're
asking for, I consider the design you're proposing to be broken from a
usability perspective (striving for academic/pedantic correctness over
accepted practice).
It is certainly not academic correctness, it is concern over the
understandibility of the library. The behaviour you are proposing is
confusing,
and even if you think it is more practical (which I doubt it is), it should
still be avoided IMO. While 192.168.1.2/24 may be an accepted notation in
some
situations, it is not a notation for a *network* but for an (address, mask)
pair, or an (address, network) pair.
There was a proposal to have a separate parse_address_and_mask method which
would return a (Address, Network) tuple, I still don't know why you don't seem
to consider it seriously, rather than trying to make the Network class a kind
of
all-in-one type conflating different concepts.
The reason (aside from the name) that I'm not going to include this in
ipaddr is that it would require the user to deal with two objects when
one would suffice. It's similar to getting two return values from
float().
integer, fraction = float('1.25')
crazy, right?
Finally, to Stephen's point about seeing the other side of the
argument, I wrote this offlist a week ago:
I *understand* what you're saying, I *understand* that 192.168.1.1/24
isn't a network, 192.168.1.0/24 is a network, and 192.168.1.1 is an ip
address on that network and it has an associated netmask that helps
describe its network, etc. etc. what I'm saying is that, enforcing
that restriction by introducing 2 new classes (ipv4 is not comparable
with ipv6, I've actually got a good quote from Vint Cerf about this,
so any AddressWithNetmask (?!?) class would have to be duplicated for
both addr types) or something else as of yet described, is not useful.
it is in fact, detrimental (optionally enforcing that restriction via
an argument to the Network constructors is, however, useful)
Cheers,
/peter
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/python-dev%40hda3.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] PEP 3144 review.
Peter Moody peter at hda3.com writes:
The reason (aside from the name) that I'm not going to include this in
ipaddr is that it would require the user to deal with two objects when
one would suffice.
You make it sound like it's a burden, but dealing with two objects is not
something extraordinary or bizarre, it happens all the time when you do network
programming: e.g. ('127.0.0.1', 80).
(or would you argue that Address objects should have an optional distinguishing
port number, for convenience reasons?)
If you need the two objects, whether you access them through separate variables
(`network` and `host`) or through attribute access (`network` and
`network.host`) doesn't really matter. You can even pretend the tuple is an
atomic object and store it as-is if you want. I'm not sure what annoys you here.
It's similar to getting two return values from
float().
I don't see how it's similar, since a float is a clearly defined atomic entity.
Most float operations become meaningless if you consider the integral and the
fractional part separately.
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
Re: [Python-Dev] PEP 3144 review.
On Mon, 28 Sep 2009 02:47:27 am Peter Moody wrote:
There was a proposal to have a separate parse_address_and_mask
method which would return a (Address, Network) tuple, I still don't
know why you don't seem to consider it seriously, rather than
trying to make the Network class a kind of all-in-one type
conflating different concepts.
The reason (aside from the name) that I'm not going to include this
in ipaddr is that it would require the user to deal with two objects
when one would suffice. It's similar to getting two return values
from float().
integer, fraction = float('1.25')
crazy, right?
Not if you want a separate integer and fraction object. There are plenty
of use-cases for such things, and the math module includes a function,
modf(), that does precisely that..
Finally, to Stephen's point about seeing the other side of the
argument, I wrote this offlist a week ago:
I *understand* what you're saying, I *understand* that
192.168.1.1/24 isn't a network,
But you still want to treat it as one.
Could you explain what benefit there is for allowing the user to create
network objects that don't represent networks? Is there a use-case
where these networks-that-aren't-networks are something other than a
typo? Under what circumstances would I want to specify a network as
192.168.1.1/24 instead of 192.168.1.0/24?
--
Steven D'Aprano
___
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] PEP 3144 review.
On Sun, Sep 27, 2009 at 10:30 AM, Steven D'Aprano st...@pearwood.info wrote:
On Mon, 28 Sep 2009 02:47:27 am Peter Moody wrote:
There was a proposal to have a separate parse_address_and_mask
method which would return a (Address, Network) tuple, I still don't
know why you don't seem to consider it seriously, rather than
trying to make the Network class a kind of all-in-one type
conflating different concepts.
The reason (aside from the name) that I'm not going to include this
in ipaddr is that it would require the user to deal with two objects
when one would suffice. It's similar to getting two return values
from float().
integer, fraction = float('1.25')
crazy, right?
Not if you want a separate integer and fraction object. There are plenty
of use-cases for such things, and the math module includes a function,
modf(), that does precisely that..
Finally, to Stephen's point about seeing the other side of the
argument, I wrote this offlist a week ago:
I *understand* what you're saying, I *understand* that
192.168.1.1/24 isn't a network,
But you still want to treat it as one.
Could you explain what benefit there is for allowing the user to create
network objects that don't represent networks? Is there a use-case
where these networks-that-aren't-networks are something other than a
typo? Under what circumstances would I want to specify a network as
192.168.1.1/24 instead of 192.168.1.0/24?
this is pretty ridiculous. if in the last two months you haven't seen
a single use case, then you haven't been paying attention.
--
Steven D'Aprano
___
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/python-dev%40hda3.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] PEP 3144 review.
On Sun, Sep 27, 2009 at 10:22 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
The reason (aside from the name) that I'm not going to include this in
ipaddr is that it would require the user to deal with two objects when
one would suffice.
You make it sound like it's a burden, but dealing with two objects is not
something extraordinary or bizarre, it happens all the time when you do
network
programming: e.g. ('127.0.0.1', 80).
(or would you argue that Address objects should have an optional
distinguishing
port number, for convenience reasons?)
I'm not sure what you're talking about, I've never argued to add layer
4 information to ipaddr.
If you need the two objects, whether you access them through separate
variables
(`network` and `host`) or through attribute access (`network` and
`network.host`) doesn't really matter. You can even pretend the tuple is an
atomic object and store it as-is if you want. I'm not sure what annoys you
here.
this is tautological. if you need two objects, then two objects is
what you need. I'm saying that you don't need two objects for this,
that common accepted practice is to represent this as one. Note,
there is *nothing* stopping you currently from using two objects for
this, an IPAddress object and a strict=True IPNetwork object.
I'm not sure what annoys you about this.
It's similar to getting two return values from
float().
I don't see how it's similar, since a float is a clearly defined atomic
entity.
Most float operations become meaningless if you consider the integral and the
fractional part separately.
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/python-dev%40hda3.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] PEP 3144 review.
Peter Moody peter at hda3.com writes: (or would you argue that Address objects should have an optional distinguishing port number, for convenience reasons?) I'm not sure what you're talking about, I've never argued to add layer 4 information to ipaddr. It was an analogy, just like your float analogy. I'm not sure what annoys you about this. I have already explained it: what annoys me is that it makes `Network` a hybrid object conflating two independent concepts, and makes the library less understandable as a result. Others have already pointed out that it makes operations like equality confusing. 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
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
(or would you argue that Address objects should have an optional
distinguishing
port number, for convenience reasons?)
I'm not sure what you're talking about, I've never argued to add layer
4 information to ipaddr.
It was an analogy, just like your float analogy.
I'm not sure what annoys you about this.
I have already explained it: what annoys me is that it makes `Network` a
hybrid
object conflating two independent concepts, and makes the library less
understandable as a result.
I understand that this is your assertion.
Here's the thing, your use case is already supported. IPv?Network
objects can only be created of network addresses, exceptions are
raised if all the host bits aren't 0, you can create and only deal
with IPv4Address('192.168.1.1') and IPv4Network('192.168.1.0/24',
strict=True) etc etc. That's not how I (nor many other network
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
There have been folks on both sides claiming that this design is both
fundamentally confusing and fundamentally sound. The confused have
obviously been more vocal and less willing to compromise. So, the
basic design of the library stands as it is, minor implementation and
documentation bugs not withstanding. I'm not going to make ipaddr
less useful (strictly removing functionality), more bulky and
confusing (adding more confusingly named classes and methods) or
otherwise break the library in a vain attempt to have it included in
the stdlib.
Cheers,
/peter
Others have already pointed out that it makes operations like equality
confusing.
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/python-dev%40hda3.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] PEP 3144 review.
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
He's claiming your solution to address your use case is confusing, not
that the use case is invalid.
I'm not going to make ipaddr
less useful (strictly removing functionality), more bulky and
confusing (adding more confusingly named classes and methods) or
otherwise break the library in a vain attempt to have it included in
the stdlib.
If I understand correctly, the proposal for addressing the issue is to
make two rather simple changes:
1) if strict=False, mask off the bits described by the netmask when
creating an IPNetwork, such that the host bits are always 0.
2) add a single new function:
def parse_net_and_addr(s):
return (IPNetwork(s), IPAddress(s.split('/')[0]))
James
___
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] PEP 3144: IP Address Manipulation Library for the Python Standard Library
For the broadcast address, it's different, since you might also use it in programming (i.e. when sending broadcasts). So there is no need to look up the broadcast address in the configuration? Don't you have to look up the rest of the network configuration too? (Or otherwise how do you know your network address and the value of /N?) You would have to know either the broadcast address directly, or the network (i.e. address and prefix length). What is actually configured on a particular host to be the broadcast address is a separate issue, even if *by convention* in most cases it is given by one of the above functions -- the network object doesn't care, the configuration object is something else (and outside the scope of this PEP). It's a little bit stronger than convention; there are RFCs saying that the all-ones (-1) address has to be the broadcast address. Sure, but what is the status of those RFCs? (Plenty of RFCs are unimplemented or superseded by others etc.) The one that says that the broadcast address is -1 (and 0 should also be supported) is STD 3. The one that talks about 31-bit prefixes (RFC 3021) is a proposed standard. RFC 3021 adds an odd wart to the all ones and all zeros functions (or perhaps only to all ones?). To both: it allows them to be used as host addresses, even though STD 3 says that they are reserved and must not be assigned to hosts. If after further examination of the facts we find that it should be honored, then what do we do for .network and .broadcast on a /32 network? For these, I would first like to find out what their specification is. 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
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight f...@fuhm.net wrote:
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
He's claiming your solution to address your use case is confusing, not that
the use case is invalid.
this isn't actually true.
Steven D'Aprano wrote:
Could you explain what benefit there is for allowing the user to create
network objects that don't represent networks? Is there a use-case
where these networks-that-aren't-networks are something other than a
typo? Under what circumstances would I want to specify a network as
192.168.1.1/24 instead of 192.168.1.0/24?
that pretty flatly states that my use case is invalid.
I'm not going to make ipaddr
less useful (strictly removing functionality), more bulky and
confusing (adding more confusingly named classes and methods) or
otherwise break the library in a vain attempt to have it included in
the stdlib.
If I understand correctly, the proposal for addressing the issue is to make
two rather simple changes:
i wish it were this easy.
1) if strict=False, mask off the bits described by the netmask when creating
an IPNetwork, such that the host bits are always 0.
I haven't heard anyone suggest auto-masking bits, but otherwise that
would be strict=True.
2) add a single new function:
def parse_net_and_addr(s):
return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor functions. In fact, when I asked for explicit
clarification of what was required, a new constructor function ala
IPAddress and IPNetwork (so the current classes remain largely the
same and the various constructors enforce certain restrictions), I
was told, no, a new object AddressWithMask was actually required. I've
no problem with a constructor like this, but this is not what people
have been asking for.
Cheers,
/peter
James
___
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] PEP 3144 review.
Peter Moody peter at hda3.com writes:
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight foom at fuhm.net wrote:
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
He's claiming your solution to address your use case is confusing, not that
the use case is invalid.
this isn't actually true.
Steven D'Aprano wrote:
[...]
That's Steven, your original sentence was about me.
1) if strict=False, mask off the bits described by the netmask when creating
an IPNetwork, such that the host bits are always 0.
I haven't heard anyone suggest auto-masking bits, but otherwise that
would be strict=True.
I would expect strict=True to raise an error if the lower bits are non-zero, not
to silently erase them. strict=False would be the option that silently erases
lower bits.
(that's why it's named `strict`, after all :-))
2) add a single new function:
def parse_net_and_addr(s):
return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor functions.
Well, method in that context meant class method since the results aren't
dependent on a particular instance. Of course, both a class method or a
module-level function would be fine.
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
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 1:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight foom at fuhm.net wrote:
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
He's claiming your solution to address your use case is confusing, not that
the use case is invalid.
this isn't actually true.
Steven D'Aprano wrote:
[...]
That's Steven, your original sentence was about me.
my original sentence was about everyone who was arguing that the
current implementation was designed for an invalid use-case. it was in
reply to your email, but it was to everyone (you, Nick, rdm, Steven,
etc)
1) if strict=False, mask off the bits described by the netmask when
creating
an IPNetwork, such that the host bits are always 0.
I haven't heard anyone suggest auto-masking bits, but otherwise that
would be strict=True.
I would expect strict=True to raise an error if the lower bits are non-zero,
not
to silently erase them. strict=False would be the option that silently erases
lower bits.
(that's why it's named `strict`, after all :-))
2) add a single new function:
def parse_net_and_addr(s):
return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor functions.
Well, method in that context meant class method since the results aren't
dependent on a particular instance. Of course, both a class method or a
module-level function would be fine.
so this is not the response I got when I asked what was required
before. Would adding this constructor function satisfy your concerns
(given sensible strict settings in the constructor, etc)?
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/python-dev%40hda3.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] PEP 3144 review.
Peter Moody peter at hda3.com writes:
def parse_net_and_addr(s):
return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor functions.
Well, method in that context meant class method since the results aren't
dependent on a particular instance. Of course, both a class method or a
module-level function would be fine.
so this is not the response I got when I asked what was required
before. Would adding this constructor function satisfy your concerns
(given sensible strict settings in the constructor, etc)?
Assuming the Network type loses the notion of a specific host (or host address,
or `ip`) attached to it, yes.
Or to put it more clearly:
Network('192.168.0.1/24', strict=False)
Network('192.168.0.0/24')
Network('192.168.0.1/24', strict=False) == Network('192.168.0.0/24')
True
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
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
def parse_net_and_addr(s):
return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor functions.
Well, method in that context meant class method since the results
aren't
dependent on a particular instance. Of course, both a class method or a
module-level function would be fine.
so this is not the response I got when I asked what was required
before. Would adding this constructor function satisfy your concerns
(given sensible strict settings in the constructor, etc)?
Assuming the Network type loses the notion of a specific host (or host
address,
or `ip`) attached to it, yes.
this is less useful (strictly removing functionality) and is an
example of what I explicitly said I was not going to do with ipaddr.
Cheers,
/peter
Or to put it more clearly:
Network('192.168.0.1/24', strict=False)
Network('192.168.0.0/24')
Network('192.168.0.1/24', strict=False) == Network('192.168.0.0/24')
True
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/python-dev%40hda3.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] PEP 389: argparse - new command line parsing module
Below is a new PEP based on discussions from the stdlib-sig, which proposes to add the argparse module to the standard library in Python 2.7 and 3.2. Looking forward to your feedback! Steve http://www.python.org/dev/peps/pep-0389/ -- PEP: 389 Title: argparse - new command line parsing module Version: $Revision: 75097 $ Last-Modified: $Date: 2009-09-27 12:42:40 -0700 (Sun, 27 Sep 2009) $ Author: Steven Bethard steven.beth...@gmail.com Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 25-Sep-2009 Python-Version: 2.7 and 3.2 Post-History: Abstract This PEP proposes inclusion of the argparse [1]_ module in the Python standard library in Python 2.7 and 3.2. Motivation == The argparse module is a command line parsing library which provides more functionality than the existing command line parsing modules in the standard library, getopt [2]_ and optparse [3]_. It includes support for positional arguments (not just options), subcommands, required options, options syntaxes like /f and +rgb, zero-or-more and one-or-more style arguments, and many other features the other two lack. The argparse module is also already a popular third-party replacement for these modules. It is used in projects like IPython (the Scipy Python shell) [4]_, is included in Debian testing and unstable [5]_, and since 2007 has had various requests for its inclusion in the standard library [6]_ [7]_ [8]_. This popularity suggests it may be a valuable addition to the Python libraries. Why aren't getopt and optparse enough? == One argument against adding argparse is that thare are already two different option parsing modules in the standard library [9]_. The following is a list of features provided by argparse but not present in getopt or optparse: * While it is true there are two *option* parsing libraries, there are no full command line parsing libraries -- both getopt and optparse support only options and have no support for positional arguments. The argparse module handles both, and as a result, is able to generate better help messages, avoiding redundancies like the ``usage=`` string usually required by optparse. * The argparse module values practicality over purity. Thus, argparse allows required options and customization of which characters are used to identify options, while optparse explicitly states the phrase 'required option' is self-contradictory and that the option syntaxes ``-pf``, ``-file``, ``+f``, ``+rgb``, ``/f`` and ``/file`` are not supported by optparse, and they never will be. * The argparse module allows options to accept a variable number of arguments using ``nargs='?'``, ``nargs='*'`` or ``nargs='+'``. The optparse module provides an untested recipe for some part of this functionality [10]_ but admits that things get hairy when you want an option to take a variable number of arguments. * The argparse module supports subcommands, where a main command line parser dispatches to other command line parsers depending on the command line arguments. This is a common pattern in command line interfaces, e.g. ``svn co`` and ``svn up``. Why isn't the functionality just being added to optparse? = Clearly all the above features offer improvements over what is available through optparse. A reasonable question then is why these features are not simply provided as patches to optparse, instead of introducing an entirely new module. In fact, the original development of argparse intended to do just that, but because of various fairly constraining design decisions of optparse, this wasn't really possible. Some of the problems included: * The optparse module exposes the internals of its parsing algorithm. In particular, ``parser.largs`` and ``parser.rargs`` are guaranteed to be available to callbacks [11]_. This makes it extremely difficult to improve the parsing algorithm as was necessary in argparse for proper handling of positional arguments and variable length arguments. For example, ``nargs='+'`` in argparse is matched using regular expressions and thus has no notion of things like ``parser.largs``. * The optparse extension APIs are extremely complex. For example, just to use a simple custom string-to-object conversion function, you have to subclass ``Option``, hack class attributes, and then specify your custom option type to the parser, like this:: class MyOption(Option): TYPES = Option.TYPES + (mytype,) TYPE_CHECKER = copy(Option.TYPE_CHECKER) TYPE_CHECKER[mytype] = check_mytype parser = optparse.OptionParser(option_class=MyOption) parser.add_option(-m, type=mytype) For comparison, argparse simply allows conversion functions to be used as ``type=`` arguments directly, e.g.:: parser = argparse.ArgumentParser()
Re: [Python-Dev] IO module precisions and exception hierarchy
Antoine Pitrou wrote: This deserves its own PEP IMO, although I'm not sure it would be accepted (ISTR the idea of a detailed IO exception hierarchy was already refused in the past). Not as such - a big exception hierarchy rewrite was rejected, but nothing specifically limited to the IO exceptions. Michael's response cut to the heart of the issue though - a richer IO exception hierarchy can make life interesting for compatibility purposes (especially when creating file-like interfaces to non-file objects). 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] Fuzziness in io module specs - PEP update proposition V2
On Sun, Sep 27, 2009 at 4:33 AM, Antoine Pitrou solip...@pitrou.net wrote: So here is the proposed semantic, which matches established conventions: *IOBase.truncate(n: int = None) - int* [...] I still don't think there is a sufficient benefit in breaking compatibility. If you want the file pointer to remain the same, you can save it first and restore it afterwards manually. What compatibility, though? f.truncate() behaves different in 2.x than in 3.x, and in 2.x it seems to match the POSIX semantics (i.e. the seek position is unchanged even though the file size is). Perhaps the changed semantics was an oversight or a mistake? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] IO module precisions and exception hierarchy
Nick Coghlan wrote: Antoine Pitrou wrote: This deserves its own PEP IMO, although I'm not sure it would be accepted (ISTR the idea of a detailed IO exception hierarchy was already refused in the past). Not as such - a big exception hierarchy rewrite was rejected, but nothing specifically limited to the IO exceptions. Michael's response cut to the heart of the issue though - a richer IO exception hierarchy can make life interesting for compatibility purposes (especially when creating file-like interfaces to non-file objects). Some of the error messages are truly awful though as things stand, especially for someone new to Python. Try to read from a file handle opened in read mode for example: IOError: [Errno 9] Bad file descriptor Michael Cheers, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] PEP 389: argparse - new command line parsing module
I am going to state upfront that I am +1 for this and I encouraged
Steven to submit this PEP on the stdlib-SIG. I still remember watching
Steven's lightning talk at PyCon 2009 on argparse and being impressed
by it (along with the rest of the audience which was obviously
impressed as well).
I think argprase is a good improvement over what we have now (getopt
and optparse), it's stable, considered best-of-breed by the community
for a while (as shown as how many times argparse has been suggestion
for inclusion), and Steven is already a core committer so is already
set to maintain the code. That covers the usual checklist we have for
even looking at a PEP to add a module to the standard library.
On Sun, Sep 27, 2009 at 13:59, Steven Bethard steven.beth...@gmail.com wrote:
[SNIP]
Deprecation of getopt and optparse
==
There is still some debate over the best way (if at all) to encourage
users to move from getopt and optparse to their replacement,
argparse. The current recommendation of this PEP is the following
conservative deprecation strategy:
* Python 3.2, Python 2.7 and any later Python 2.X releases --
PendingDeprecation warnings, which by default are not displayed,
and documentation notes directing users of getopt and optparse to
argparse.
* Python 3.3 -- Same as above
* Python 3.4 -- Deprecation warnings for getopt and optparse, which
by default *are* displayed.
Though this is slower than the usual deprecation process, it seems
prudent to avoid producing any casually visible Deprecation warnings
until Python 3.X has had some additional time to attract developers.
Just to give people ideas of how long these deprecations would last,
if Python 3.2 is released in June 2010 and we continue on our 18 month
release schedule (and actually release that quickly which we typically
don't), then getopt/optparse would have a pending deprecation for 3
years (until June 2013) and a deprecation warning for 1.5 years (until
January 2015), so 4.5 years total once the deprecations began and six
years since Python 3.0 came out. And obviously the deprecation can be
extended if it turns out Python 3 pick up is now at a rate we expect
(but only if people who plan to port are having issues; this does not
concern those who plan to stay on Python 2 indefinitely and do not
care about Python 3).
And we can also document suggestions on how to transition off of
getopt/optparse like Steven has in the argparse code
(http://argparse.googlecode.com/svn/tags/r101/doc/argparse-vs-optparse.html#upgrading-optparse-code).
Open Issues
===
The argparse module supports Python from 2.3 up through 3.2 and as a
result relies on traditional ``%(foo)s`` style string formatting. It
has been suggested that it might be better to use the new style
``{foo}`` string formatting [13]_. This seems like a good idea, but
would break backwards compatibility for existing argparse-based
scripts unless we can come up with a way to reasonably support both
syntaxes.
I see two solutions to this. One is to auto-detect either format and
then do the right thing. Seems potentially messy, although getting the
regex right shouldn't be a problem.
The other option is to rename the module if it is added to the
standard library ala simplejson/json. That would alleviate any issues
with someone including their own copy of argparse with their
application using %()s string interpolation over {}. I don't have a
name to suggest at the moment (nor do I think we should start
discussing that now unless this is a chosen solution), but it would
deal with the problem.
Either way, with {} being the future and talk of someday dropping %, I
think we should make sure the newer syntax is at least supported, if
not the only way to do things.
-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] PEP 389: argparse - new command line parsing module
Brett Cannon wrote:
I am going to state upfront that I am +1 for this and I encouraged
Steven to submit this PEP on the stdlib-SIG. I still remember watching
Steven's lightning talk at PyCon 2009 on argparse and being impressed
by it (along with the rest of the audience which was obviously
impressed as well).
I think argprase is a good improvement over what we have now (getopt
and optparse), it's stable, considered best-of-breed by the community
for a while (as shown as how many times argparse has been suggestion
for inclusion), and Steven is already a core committer so is already
set to maintain the code. That covers the usual checklist we have for
even looking at a PEP to add a module to the standard library.
I've used argparse and really like it. I could also have done with the
subcommand support in recent changes to unittest.
+1 for inclusion.
Michael
On Sun, Sep 27, 2009 at 13:59, Steven Bethard steven.beth...@gmail.com wrote:
[SNIP]
Deprecation of getopt and optparse
==
There is still some debate over the best way (if at all) to encourage
users to move from getopt and optparse to their replacement,
argparse. The current recommendation of this PEP is the following
conservative deprecation strategy:
* Python 3.2, Python 2.7 and any later Python 2.X releases --
PendingDeprecation warnings, which by default are not displayed,
and documentation notes directing users of getopt and optparse to
argparse.
* Python 3.3 -- Same as above
* Python 3.4 -- Deprecation warnings for getopt and optparse, which
by default *are* displayed.
Though this is slower than the usual deprecation process, it seems
prudent to avoid producing any casually visible Deprecation warnings
until Python 3.X has had some additional time to attract developers.
Just to give people ideas of how long these deprecations would last,
if Python 3.2 is released in June 2010 and we continue on our 18 month
release schedule (and actually release that quickly which we typically
don't), then getopt/optparse would have a pending deprecation for 3
years (until June 2013) and a deprecation warning for 1.5 years (until
January 2015), so 4.5 years total once the deprecations began and six
years since Python 3.0 came out. And obviously the deprecation can be
extended if it turns out Python 3 pick up is now at a rate we expect
(but only if people who plan to port are having issues; this does not
concern those who plan to stay on Python 2 indefinitely and do not
care about Python 3).
And we can also document suggestions on how to transition off of
getopt/optparse like Steven has in the argparse code
(http://argparse.googlecode.com/svn/tags/r101/doc/argparse-vs-optparse.html#upgrading-optparse-code).
Open Issues
===
The argparse module supports Python from 2.3 up through 3.2 and as a
result relies on traditional ``%(foo)s`` style string formatting. It
has been suggested that it might be better to use the new style
``{foo}`` string formatting [13]_. This seems like a good idea, but
would break backwards compatibility for existing argparse-based
scripts unless we can come up with a way to reasonably support both
syntaxes.
I see two solutions to this. One is to auto-detect either format and
then do the right thing. Seems potentially messy, although getting the
regex right shouldn't be a problem.
The other option is to rename the module if it is added to the
standard library ala simplejson/json. That would alleviate any issues
with someone including their own copy of argparse with their
application using %()s string interpolation over {}. I don't have a
name to suggest at the moment (nor do I think we should start
discussing that now unless this is a chosen solution), but it would
deal with the problem.
Either way, with {} being the future and talk of someday dropping %, I
think we should make sure the newer syntax is at least supported, if
not the only way to do things.
-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/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
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] PEP 3144 review.
Peter Moody wrote:
Steven D'Aprano wrote:
Could you explain what benefit there is for allowing the user to create
network objects that don't represent networks? Is there a use-case
where these networks-that-aren't-networks are something other than a
typo? Under what circumstances would I want to specify a network as
192.168.1.1/24 instead of 192.168.1.0/24?
that pretty flatly states that my use case is invalid.
Looks like Steven was asking you to explain your use case to him rather
than stating that it didn't exist. (although I will grant that the
network definition use case had been well covered, I will also grant
that these threads have been somewhat interminable and I can easily
understand someone missing those use case definitions - the example of
being able to define a network given only the network mask and the IP
address of the host running the current application should be mentioned
explicitly in the PEP)
1) if strict=False, mask off the bits described by the netmask when creating
an IPNetwork, such that the host bits are always 0.
I haven't heard anyone suggest auto-masking bits, but otherwise that
would be strict=True.
Actually, that's exactly what I suggested in this thread - that
IPNetwork should lose the ip property and that the definition of
network equality should be based on the network address not on the
host address that happened to be used when constructing the network object.
The part that is confusing with the current library implementation is
the fact that we can have two IPNetwork objects, supposedly describing
the same network, compare unequal because they happened to be defined
differently. It would be analagous to having Decimal('3.0') !=
Decimal('3.00').
2) add a single new function:
def parse_net_and_addr(s):
return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor functions. In fact, when I asked for explicit
clarification of what was required, a new constructor function ala
IPAddress and IPNetwork (so the current classes remain largely the
same and the various constructors enforce certain restrictions), I
was told, no, a new object AddressWithMask was actually required. I've
no problem with a constructor like this, but this is not what people
have been asking for.
No, AddressWithMask was merely defined as a concept separate from an IP
Network to indicate how the current IPNetwork class was being overloaded
with two distinct concepts and hence exhibiting unnecessary behavioural
quirks.
The use case for given a netmask and an arbitrary host on that network,
give me the appropriate IPNetwork object has been well established by
this discussion (although still isn't particularly well described even
in the latest PEP update). This is what strict=False covers, and I'm
now happy that practicality means this is appropriate default behaviour
for the IPNetwork constructor.
The use case for create an IPNetwork object and have it *remember*
which particular host address was used to define it is still not
established at all.
It is this latter use case which is covered by the AddressWithMask
concept (which may be perfectly validly represented as a simple
IPNetwork/IPAddress tuple, which was also mentioned when the concern was
first raised).
The main concern here is to take the AddressWithMask behaviour *off*
the IPNetwork objects. It interferes with their interpretation as
descriptions of networks because they maintain a piece of irrelevant
state and pay attention to it in comparison operations.
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] PEP 3144 review, and the inclusion process
Peter Moody peter at hda3.com writes: this is less useful (strictly removing functionality) and is an example of what I explicitly said I was not going to do with ipaddr. (please note the conditional wording here) Assuming that a significant number of people agree that there is a design problem, if you don't want to make the necessary changes, then I don't see a reason why ipaddr would enter the stdlib. The functionality (IP address handling) hasn't really seen a huge demand. On stdlib-sig recently, a number of people complained that our criteria for including existing libraries in the stdlib should be higher (they complained about the quality of some existing modules, including optparse, which by the way prompted the current proposal to get argparse in the stdlib). I think this PEP is a good moment to judge and decide how demanding or tolerant we (and especially the complainers ;-)) want to be. 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
Re: [Python-Dev] IO module precisions and exception hierarchy
Le Mon, 28 Sep 2009 06:41:17 +1000, Nick Coghlan a écrit : Not as such - a big exception hierarchy rewrite was rejected, but nothing specifically limited to the IO exceptions. Michael's response cut to the heart of the issue though - a richer IO exception hierarchy can make life interesting for compatibility purposes (especially when creating file-like interfaces to non-file objects). Well, not more interesting than currently where you need to replicate errno numbers if you want to make the errors precise enough, since an API consumer wanting to check specific error conditions will discriminate on errno. If you don't want to go to that level of perfection, you just have to raise a plain IOError (or OSError :-)) without bothering about errno or subclasses; like you would do today. 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
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, 27 Sep 2009 14:57:34 -0700, Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. FWIW, +1 from IPython: we ship a private copy of argparse as well (we use it in several places but we want the basic ipython to be installable just with the stdlib). Steven was gracious enough to relicense it as BSD at our request: http://mail.scipy.org/pipermail/ipython-dev/2009-September/005537.html so we could ship this copy without any GPL incompatibilities, but we'd much rather rely on stdlib components. Best, f ___ 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] PEP 3144 review.
On Sun, Sep 27, 2009 at 5:13 PM, Steven D'Aprano st...@pearwood.info wrote:
On Mon, 28 Sep 2009 03:53:27 am Peter Moody wrote:
I *understand* what you're saying, I *understand* that
192.168.1.1/24 isn't a network,
But you still want to treat it as one.
Could you explain what benefit there is for allowing the user to
create network objects that don't represent networks? Is there a
use-case where these networks-that-aren't-networks are something
other than a typo? Under what circumstances would I want to specify
a network as 192.168.1.1/24 instead of 192.168.1.0/24?
this is pretty ridiculous. if in the last two months you haven't seen
a single use case, then you haven't been paying attention.
No, I haven't read every single email in excruciating detail in this
extremely long thread. I'd bet most other people haven't.
I'm trying to understand why you want something which, in *my*
ignorance, seems patently ridiculous to me: allowing Network objects
which aren't Networks, particularly since in private email to me you
denied that there was a use-case for the requested (Address object +
netmask).
no, it seems as though you're either misrepresenting my position or
you misunderstood what I said. I said that there wasn't a use-case for
explicitly pulling that functionality out into a a new class, and
having 6 classes.
But it seems to me that this is exactly what you have in the
current implementation, except you call it a Network object, and have
rejected the suggestion that the non-network bits of the address should
be zeroed.
I have not rejected this. I have rejected the suggestion that the
current IPv?Network classes do this by default.
That is, you've rejected the idea of having:
IPv4Network(192.168.1.1/24)
IPv4Network(192.168.1.0/24)
yes, I and everyone have rejected that idea. this should either raise
an error, or do what it does now, that is, return
IPv4Network('192.168.1.1/24')
as reducing functionality, presumably because the address 192.168.1.1 is
lost.
good guess.
Sounds just like an Address+netmask to me, with added
network-like behaviour.
Some people have requested a way of explicitly calculating a network
from an Address and netmask, and you've been hostile to the idea. But
it seems to me that your API does exactly that.
You mean the suggestion to include an IPv?Network object attribute
with the IPv?Address objects? I thought that was dropped long ago.
I'm not the only person who thinks your API conflates two different
concepts into a single class, and I'm trying to see your side of the
argument. But your hostile attitude isn't making it easy.
apologies if you find me hostile. I'm not sure how you'd expect me to
be if, after 2 months 200+ messages, both on list and off, you were
unable to recall a single use-case.
--
Steven D'Aprano
___
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/python-dev%40hda3.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] PEP 3144 review, and the inclusion process
Peter Moody peter at hda3.com writes: I've never said otherwise. In fact, from an email last night, If what the community requires is the library you've described, then ipaddr is not that library. The changes *you* require make ipaddr significantly less useful to me. I'm not prepared to make those changes in an attempt seek acceptance to the stdlib, especially if the stdlib is in such flux that I'll get to do this again in 18 months. Well, then I'm not sure why we have a PEP at all. If you don't want any significant changes and if you consider it to be *your* library, ipaddr can remain a third-party package that interested people can easily install (no pun ;-)) since AFAIK it's pure Python. It will also make maintenance easier for you, while freeing us (core developers) from having to bother about it in our daily development tasks. At least that's what I would advocate right now - not sure about what others think. 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
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:31 PM, Fernando Perez fperez@gmail.comwrote: On Sun, 27 Sep 2009 14:57:34 -0700, Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. FWIW, +1 from IPython: we ship a private copy of argparse as well (we use it in several places but we want the basic ipython to be installable just with the stdlib). Steven was gracious enough to relicense it as BSD at our request: +1 Coincidentally I was converting several packages to argparse as I saw the python-dev mail come in. A great deal of hairy code needed to jury-rig sub-commands and other advanced processing with optparse is simply disappearing. I like the idea that stdlib can evolve to encompass best of breed solutions and that effort is being expended to improve existing functionality even if it means increasing the diversity of APIs. ~Kevin ___ 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] PEP 389: argparse - new command line parsing module
Hello, I am neutral on the idea of adding argparse. However, I'm -1 on deprecating optparse. It is very widely used (tons of scripts use it), and ok for many uses; deprecating it is totally unhelpful and gratuitous. 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
Re: [Python-Dev] PEP 3144 review.
Nick Coghlan wrote: The use case for given a netmask and an arbitrary host on that network, give me the appropriate IPNetwork object has been well established by this discussion (although still isn't particularly well described even in the latest PEP update). This is what strict=False covers, I think I'd rather have a separate constructor function or method for this, rather than a somewhat cryptically named boolean parameter. -- Greg ___ 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] PEP 3144 review.
On Sun, 27 Sep 2009 at 13:59, Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
def parse_net_and_addr(s):
?return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor functions.
Well, method in that context meant class method since the results aren't
dependent on a particular instance. Of course, both a class method or a
module-level function would be fine.
so this is not the response I got when I asked what was required
before. Would adding this constructor function satisfy your concerns
(given sensible strict settings in the constructor, etc)?
Assuming the Network type loses the notion of a specific host (or host address,
or `ip`) attached to it, yes.
this is less useful (strictly removing functionality) and is an
example of what I explicitly said I was not going to do with ipaddr.
In that case, I vote -1 on the inclusion of ipaddr in the stdlib.
--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] IO module precisions and exception hierarchy
Michael Foord wrote: Some of the error messages are truly awful though as things stand, especially for someone new to Python. Try to read from a file handle opened in read mode for example: IOError: [Errno 9] Bad file descriptor Subdividing the IOError exception won't help with that, because all you have to go on when deciding which exception to raise is the error code returned by the OS. If the same error code results from a bunch of different things, there's not much Python can do to sort them out. The error messages produced for the various error codes could perhaps be improved, but that's an orthogonal issue. -- Greg ___ 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] PEP 3144 review.
Peter Moody wrote: On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou solip...@pitrou.net wrote: Assuming the Network type loses the notion of a specific host (or host address, or `ip`) attached to it, yes. this is less useful (strictly removing functionality) and is an example of what I explicitly said I was not going to do with ipaddr. Would you be kind enough to explain exactly what use case you have for retaining this information? Apologies if you've done so before -- I've been trying to follow this discussion, but that point doesn't seem to have come through clearly. -- Greg ___ 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] PEP 389: argparse - new command line parsing module
On Sep 27, 2009, at 6:00 PM, Michael Foord wrote: Brett Cannon wrote: I am going to state upfront that I am +1 for this and I encouraged Steven to submit this PEP on the stdlib-SIG. I still remember watching Steven's lightning talk at PyCon 2009 on argparse and being impressed by it (along with the rest of the audience which was obviously impressed as well). I think argprase is a good improvement over what we have now (getopt and optparse), it's stable, considered best-of-breed by the community for a while (as shown as how many times argparse has been suggestion for inclusion), and Steven is already a core committer so is already set to maintain the code. That covers the usual checklist we have for even looking at a PEP to add a module to the standard library. I've used argparse and really like it. I could also have done with the subcommand support in recent changes to unittest. +1 for inclusion. +1 as well. I wish I had been able to use this library for a recent project using sub-commands. Doug ___ 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] PEP 3144 review.
On Sun, Sep 27, 2009 at 9:26 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Would you be kind enough to explain exactly what use case you have for retaining this information? Apologies if you've done so before -- I've been trying to follow this discussion, but that point doesn't seem to have come through clearly. Please don't apologize. It shouldn't matter how many times it's been mentioned on the mailing list. The PEP process is intended to summarize the discussion. A PEP should pretty much stand alone, with specific external links when necessary. The use case should be added to the PEP. ___ 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] PEP 3144 review.
Looking though the tests you have setup for ipaddr it is clear that
you want the following to be True
ip1 = ipaddr.IPv4Network('1.1.1.0/24')
ip2 = ipaddr.IPv4Network('1.1.1.1/24')
ip1 == ip2
based on this test
self.assertEquals(ip1.compare_networks(ip2), 0)
but your = operators all compare against _ip instead of network. I
submitted a patch for review @ http://codereview.appspot.com/124057
___
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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou solip...@pitrou.net wrote: I am neutral on the idea of adding argparse. However, I'm -1 on deprecating optparse. It is very widely used (tons of scripts use it), and ok for many uses; deprecating it is totally unhelpful and gratuitous. Could you elaborate? If you are worried about Python 2.X scripts, note from the PEP that the only things that will ever show up in Python 2.X are: PendingDeprecation warnings, which by default are not displayed, and documentation notes directing users of getopt and optparse to argparse. I think these messages are useful for folks using 2.X who some day would like to migrate to 3.X, and at the same time should have zero effect on existing scripts. If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? 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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? Transitioning to Python 3 is already a pain. bytes/str/unicode things are going to be enough by themselves to drive people nuts. We don't want to be forcing them to change APIs if optparse is already working just fine for them. The job is the stdlib is not to force people to use the best or right tools. Several years in the future I would be more supportive of depreacting optparse, but more ways in which 2.x and 3.x grow farther apart are not going to help jumping the great version divide. The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. 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
[Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. So, why even bother deprecating it if nobody is going to see the warnings? I feel like I'm repeating the PEP, but here it is again anyway. There will be messages in the docs and pending deprecation warnings (which don't show up by default but can be requested) starting in Python 2.7 and 3.2. Regular deprecation warnings wouldn't show up until Python 3.4, 3 years away. This compromise was intended exactly to address the issue you brought up about people getting over the Python 3 transition. 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] PEP 3144 review.
Finally, to Stephen's point about seeing the other side of the argument, I wrote this offlist a week ago: I *understand* what you're saying, I *understand* that 192.168.1.1/24 isn't a network, But you still want to treat it as one. Could you explain what benefit there is for allowing the user to create network objects that don't represent networks? Is there a use-case where these networks-that-aren't-networks are something other than a typo? Under what circumstances would I want to specify a network as 192.168.1.1/24 instead of 192.168.1.0/24? It's fairly obvious to me why the library should support 192.168.1.1/24 as an input, and return a network. End-users are likely going to enter such things (e.g. 82.94.164.162/29), as they will know one IP address in the network (namely, of one machine that they are looking at), and they will know the prefix length (more often, how large the network is - 8 or 16 or 32). So very clearly, end users should not be required to make the computation in their heads. So Python code has to make the computation, and it seems most natural that the IP library is the piece of code that is able to compute a network out of that input. Does that answer your question? 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
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
-1 for deprecating getopt. getopt is super-simple and especially useful for c programmers learning python. +1 for argparse.+1 for eventual deprecation of optparse - optparse and argparse have a very similar syntax and having both is just confusing. tsboapooowtdi On Mon, Sep 28, 2009 at 6:46 AM, Steven Bethard steven.beth...@gmail.comwrote: On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. So, why even bother deprecating it if nobody is going to see the warnings? I feel like I'm repeating the PEP, but here it is again anyway. There will be messages in the docs and pending deprecation warnings (which don't show up by default but can be requested) starting in Python 2.7 and 3.2. Regular deprecation warnings wouldn't show up until Python 3.4, 3 years away. This compromise was intended exactly to address the issue you brought up about people getting over the Python 3 transition. 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/ubershmekel%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] PEP 389: argparse - new command line parsing module
If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? I personally consider getopt superior to both optparse and argparse. Those are terribly verbose in specifying arguments, whereas getopt's sequence-of-letters is really nice and compact. 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
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
2009/9/27 Steven Bethard steven.beth...@gmail.com: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? Transitioning to Python 3 is already a pain. bytes/str/unicode things are going to be enough by themselves to drive people nuts. We don't want to be forcing them to change APIs if optparse is already working just fine for them. The job is the stdlib is not to force people to use the best or right tools. Several years in the future I would be more supportive of depreacting optparse, but more ways in which 2.x and 3.x grow farther apart are not going to help jumping the great version divide. -- Regards, Benjamin ___ 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] PEP 389: argparse - new command line parsing module
2009/9/27 Steven Bethard steven.beth...@gmail.com: On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson benja...@python.org wrote: 2009/9/27 Steven Bethard steven.beth...@gmail.com: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? Transitioning to Python 3 is already a pain. bytes/str/unicode things are going to be enough by themselves to drive people nuts. We don't want to be forcing them to change APIs if optparse is already working just fine for them. The job is the stdlib is not to force people to use the best or right tools. Several years in the future I would be more supportive of depreacting optparse, but more ways in which 2.x and 3.x grow farther apart are not going to help jumping the great version divide. The first release where any real deprecation message would show up is Python 3.4, more than 3 years away. If you think 3 years isn't long enough for people to be over the Python 3 transition, let's stick in another version in there and make it 4.5 years. So, why even bother deprecating it if nobody is going to see the warnings? -- Regards, Benjamin ___ 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] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 9:09 PM, Martin v. Löwis mar...@v.loewis.de wrote: If you think getopt and optparse should stick around in 3.X, why is that? If you think there are things that getopt and optparse do better than argparse, could you please give some examples? I personally consider getopt superior to both optparse and argparse. Those are terribly verbose in specifying arguments, whereas getopt's sequence-of-letters is really nice and compact. Thanks for the concrete example. Although I'm unconvinced that the characters you save in the sequence of letters in the getopt.getopt call aren't afterwards wasted on type conversions, if/else statements and variable assignments in the subsequent loop, it would be pretty simple to add to argparse something like:: ArgumentParser.add_getopt_arguments(options[, long_options]) Then you could replace your getopt code:: try: opts, args = getopt.getopt(sys.argv[1:], ho:v, [help, output=]) except getopt.GetoptError, err: # print help information and exit: print str(err) # will print something like option -a not recognized usage() sys.exit(2) output = None verbose = False for o, a in opts: if o == -v: verbose = True elif o in (-h, --help): usage() sys.exit() elif o in (-o, --output): output = a else: assert False, unhandled option with argparse code like:: parser = argparse.ArgumentParser() parser.add_getopt_arguments(ho:v, [help, output=]) args = parser.parse_args() verbose = args.v output = args.o or args.output If something like this were available, would you be alright with deprecating getopt? 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
