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 " 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sat, Sep 26, 2009 at 6:34 AM, Barry Scott 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 [email protected] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
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). 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. > 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. 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. > 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. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python build question (fixing pymath.c).
On Sun, Sep 27, 2009 at 00:21, Mark Dickinson 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sat, Sep 26, 2009 at 11:08 PM, Nick Coghlan 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 | [email protected] | Brisbane, Australia > --- > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python build question (fixing pymath.c).
On Sun, Sep 27, 2009 at 8:48 AM, Brett Cannon wrote: > On Sun, Sep 27, 2009 at 00:21, Mark Dickinson 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk
On 27 Sep 2009, at 03:12, Ned Deily wrote: In article <[email protected]>, Barry Scott 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
Dave M. On 27 Sep 2009, at 07:56, "Martin v. Löwis" 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/drkjam%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
Peter Moody 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IO module precisions and exception hierarchy
MRAB 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Sun, Sep 27, 2009 at 12:41 AM, "Martin v. Löwis" 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou wrote:
> Peter Moody 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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
Peter Moody 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 10:30 AM, Steven D'Aprano 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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 10:22 AM, Antoine Pitrou wrote:
> Peter Moody 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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
Peter Moody 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 11:17 AM, Antoine Pitrou wrote:
> Peter Moody 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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
Peter Moody hda3.com> writes:
>
> On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 1:15 PM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight 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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
Peter Moody 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
> Peter Moody 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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 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
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()
parser.add_opti
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 | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fuzziness in io module specs - PEP update proposition V2
On Sun, Sep 27, 2009 at 4:33 AM, Antoine Pitrou 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 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
[email protected]
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 | [email protected] | Brisbane, Australia
---
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review, and the inclusion process
Peter Moody 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fuzziness in io module specs - PEP update proposition V2
Le Sun, 27 Sep 2009 14:24:52 -0700, Guido van Rossum a écrit : [truncate()] > > What compatibility, though? Compatibility accross the 3.x line. > 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? Perhaps it was, indeed. I don't know who made that decision in the first place. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review, and the inclusion process
On Sun, Sep 27, 2009 at 3:32 PM, Antoine Pitrou wrote: > Peter Moody 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. 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. > The functionality (IP address handling) hasn't really seen a huge demand. then no one would be the worse off if I don't make those suggested changes. > 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. Sounds like design by committee to satisfy the squeakiest wheel. I'm trying, but I can't think of anything worse. Cheers, /peter > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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). 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. That is, you've rejected the idea of having: >>> IPv4Network(192.168.1.1/24) IPv4Network(192.168.1.0/24) as reducing functionality, presumably because the address 192.168.1.1 is lost. 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. 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. -- Steven D'Aprano ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 5:13 PM, Steven D'Aprano 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
> [email protected]
> 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review, and the inclusion process
Peter Moody 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:31 PM, Fernando Perez wrote: > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 wrote:
Peter Moody 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
Peter Moody wrote: On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
On Sun, Sep 27, 2009 at 9:26 PM, Greg Ewing 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson wrote: > 2009/9/27 Steven Bethard : >> 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson wrote: > 2009/9/27 Steven Bethard : >> 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 wrote: > On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson > wrote: > > 2009/9/27 Steven Bethard : > >> 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 > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ubershmekel%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
2009/9/27 Steven Bethard : > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
2009/9/27 Steven Bethard : > On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson > wrote: >> 2009/9/27 Steven Bethard : >>> 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 9:09 PM, "Martin v. Löwis" 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson wrote: > 2009/9/27 Steven Bethard : >> On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson >> wrote: >>> 2009/9/27 Steven Bethard : 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. > > But that doesn't tell me why we should deprecate optparse, when it may > work perfectly well for some people. Because it's basically unmaintained, and anything you can do in optparse you can do in argparse with almost identical syntax. So encouraging people to move from getopt and optparse to argparse is a net gain for us as Python maintainers -- that's two fewer modules in the standard library that someone has to take care of bug reports for. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
Martin v. Löwis v.loewis.de> writes: > > > 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? > > > [...] > > 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. The thing is, it doesn't create a network, it creates a hybrid "network plus host" which retains knowledge about the original host (that is, 192.168.1.1 rather than simply 192.168.1.0, if you enter "192.168.1.1/24"). That's what the OP meant with "networks-that-aren't-networks", and that's what people are objecting to. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
