Re: [Python-Dev] Misc/maintainers.rst

[Nick Coghlan]

Fred Drake wrote:
> On Thu, Sep 17, 2009 at 10:38, Georg Brandl  wrote:
>> So the plan would be to consolidate these into another set of rst docs,
>> having them in the repo, editable by every committer, as well as
>> published
>> somewhere on python.org (devdocs.python.org or somesuch).
> 
> On Sep 17, 2009, at 1:56 PM, Brett Cannon wrote:
>> dev.python.org would be nice to have, from which we can simply
>> redirect www.python.org/dev/ to dev.python.org. www.python.org/dev/
>> can then get cleaned up be made simpler to navigate and more obvious
>> for how people can get started.
> 
> Many years ago, we decided to add docs.python.org with the "current"
> version of the documentation, so people would be able to find the docs
> more easily.  Since then, we've had problems with keeping
> docs.python.org and www.python.org/doc/ in sync, and with different
> styles being applied to the sites.

We can avoid that problem by having the URLs just be alternative names
for the same thing (as Brett suggested), rather than having them be
actually different sites (as is the case for docs.python.org and
www.python.org/doc).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Paul Moore]

2009/9/18 R. David Murray :
> On Fri, 18 Sep 2009 at 11:04, Andrew McNamara wrote:
>>
>> [attribution lost; apparently Steven D'Aprano given the CC]
>>>
>>> To a non-specialist, "the network address" is ambiguous. There are many
>>> addresses in a network, and none of them are the entire network. It's
>>> like saying, given a list [2, 4, 8, 12], what's "the list item"?
>>
>> A "network address" is an IP address and mask, but I understand your
>> confusion - we're mixing terminology from disperate domains. In my
>> postings, I have tried to refer to Network (a containter) and Address
>> (an item).
>
> Apparently not, in many people's vocabulary.  The 'network address'
> is used to designate the IP address whose bits corresponding to the one
> bits in the mask have been set to zero (ie: the first IP address in the
> network range).
>
> It is interesting how this item seems to lead to the greatest amount of
> confusion on everyone's part, and I'm guessing it is because the common
> terminology and usage blurs the line between addresses and networks.
> And that's what we are trying to make clear(er) through a well structured
> API.

How non-expert do you want to get? My immediate reaction is that the
network address of my PC is 157.215.187.94 - it's what comes up ad "IP
address" when I type ipconfig. I understand why that's "wrong", and I
see why the definitions above are "better", but that doesn't affect my
instinct.

Suggestion - just don't use the term "network address" anywhere in the
library, the PEP, or its documentation. The term seems too loaded with
contradictory meanings to be useful. If the concept behind it (one of
the many concepts - among our concepts...) is useful, then maybe coin
a new term specific to the module.

Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] conceptual clarity

[R. David Murray]

On Thu, 17 Sep 2009 at 20:29, Peter Moody wrote:

On Thu, Sep 17, 2009 at 6:17 PM, Andrew McNamara
 wrote:

off to patch the pep and implement some of the non controversial changes.


It might be a good idea to add some use-cases to the PEP.


There are several use-cases in the PEP already.

The problem is, for every use-case where one can show that the
existing implementation is confusing, I can come up with a use-case
showing where the existing implementation makes more sense than
anything proposed.


Then all of those use cases should be in the PEP, so we can try to find
the best refinement we can of the API for handling all of them.

--David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (09/11/09 - 09/18/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2396 open (+27) / 16366 closed (+29) / 18762 total (+56)

Open issues with patches:   953

Average duration of open issues: 664 days.
Median duration of open issues: 420 days.

Open Issues Breakdown
   open  2363 (+27)
pending32 ( +0)

Issues Created Or Reopened (56)
___

pdb documentation shows running as script using "python" not "py 09/11/09
CLOSED http://bugs.python.org/issue6885created  MLModel 
  
   

cgi.py runs python, not python3  09/11/09
   http://bugs.python.org/issue6886created  MLModel 
  
   

executables in lib use /usr/bin/env python, not python3  09/11/09
   http://bugs.python.org/issue6887created  MLModel 
  
   

pdb alias command with no arguments is broken09/11/09
CLOSED http://bugs.python.org/issue6888created  MLModel 
  
   

«Python’s default encoding is the ‘ascii’ encoding.» 09/11/09
CLOSED http://bugs.python.org/issue6889created  flox
  
   

IOError has no __unicode__ method - and loses information09/11/09
CLOSED http://bugs.python.org/issue6890created  michael.foord   
  
   26backport  

small typo in «unicode.rst»: «the Uniode APIs should be used 09/11/09
CLOSED http://bugs.python.org/issue6891created  flox
  
   

optparser example in optparse documentation is broken09/12/09
CLOSED http://bugs.python.org/issue6892created  MLModel 
  
   

defaultdict example in py3 doc should mention the new Counter cl 09/12/09
   http://bugs.python.org/issue6893created  ezio.melotti
  
   

urllib2 doesn't respect "no_proxy" environment  (python2.6.2)09/12/09
   http://bugs.python.org/issue6894created  xelnor  
  
   patch   

locale._parse_localename fails when localename does not contain  09/12/09
   http://bugs.python.org/issue6895created  santhosh.thottingal 
  
   patch   

Intermittent failures in test_mailbox09/12/09
   http://bugs.python.org/issue6896created  ezio.melotti
  
   

imaplib fails during login   09/12/09
   http://bugs.python.org/issue6897created  debatem1
  
   

Unicode  Error   09/13/09
CLOSED http://bugs.python.org/issue6898created  vitvn   
  
   

Base.replace breaks tree 09/13/09
   http://bugs.python.org/issue6899created  loewis  
  
   patch   

Sub-optimal "Locate" button behaviour in Windows CHM file09/13/09
   http://bugs.python.org/issue6900created  tom_seddon  
  
   

Runaway programs often become unresponsive to CTRL-C 09/13/09
CLOSED http://bugs.python.org/issue6901created  bernie  
  
   

Built-in types format incorrectly with 0 padding.09/13/09
   http://bugs.python.org/issue6902created  eric.smith  
  
   

pdb - print in for iteration prints None after printing  09/14/09
CLOSED http://bugs.python.org/issue6903created  MLModel 
  
 

[Python-Dev] OS X buildbot

[Thomas Heller]

I have updated the OS X buildbot to Snow Leopard.

-- 
Thomas

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Fuzziness in io module specs

[Pascal Chambon]

Hello everyone

I'm currently working on a reimplementation of io.FileIO, which would 
allow cross-platform file range locking and all kinds of other safety 
features ; however I'm slightly stuck due to some specification 
fuzziness in the IO docs.

CF http://bugs.python.org/issue6939

The main points that annoy me at the moment :
- it is unclear what truncate() methods do with the file pointer, and 
even if the current implementation simply moves it to the truncation 
point, it's very contrary to the standard way of doing under unix, where 
the file pointer is normally left unchanged. Shouldn't we specify that 
the file pointer remains unmoved, and fix the _fileio module accordingly ?
- exceptions are not always specified, and even if most of them are 
IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if 
we try to wrap a wrong file descriptor when instanciating a new FileIO). 
This might lead to bad program crashes if some people don't "refuse the 
temptation to guess" and only get prepared to catch IOErrors
- the doc sometimes says that when we receive an empty string from a 
read() operation, without exceptions, it means the file is empty. 
However, with the current implementation, if we call file.read(0), we 
simply receive "", even though it doesn't mean that we're at EOF. 
Shouldn't we avoid this (rare, I admit) ambiguity on the return value, 
by preventing read(0) ? Or at least, note in the doc that (we receive an 
empty string) <-> (the file is at EOF OR we called read with 0 as 
parameter) ?


Are there some arguments that I don't know, which lead to this or that 
particular implementation choice ?
I'd strongly advocate very detailled specifications, letting no room for 
cross-platform subtilities (that's also a strong goal of my 
reimplemntation), since that new IO system (which saved me a lot of 
coding time, by the way) should become the base of many programs.


So wouldn't it be a godo idea to write some kind of mini-pep, just to 
fix the corner cases of the current IO documentation ? I might handle 
it, if no more-knowledgeable people feels like it.


Regards,
Pascal
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fuzziness in io module specs

[Guido van Rossum]

Why not propose an update to the existing PEP to clarify the vaguenesses?

On Fri, Sep 18, 2009 at 12:17 PM, Pascal Chambon
 wrote:
> Hello everyone
>
> I'm currently working on a reimplementation of io.FileIO, which would allow
> cross-platform file range locking and all kinds of other safety features ;
> however I'm slightly stuck due to some specification fuzziness in the IO
> docs.
> CF     http://bugs.python.org/issue6939
>
> The main points that annoy me at the moment :
> - it is unclear what truncate() methods do with the file pointer, and even
> if the current implementation simply moves it to the truncation point, it's
> very contrary to the standard way of doing under unix, where the file
> pointer is normally left unchanged. Shouldn't we specify that the file
> pointer remains unmoved, and fix the _fileio module accordingly ?
> - exceptions are not always specified, and even if most of them are
> IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if we
> try to wrap a wrong file descriptor when instanciating a new FileIO). This
> might lead to bad program crashes if some people don't "refuse the
> temptation to guess" and only get prepared to catch IOErrors
> - the doc sometimes says that when we receive an empty string from a read()
> operation, without exceptions, it means the file is empty. However, with the
> current implementation, if we call file.read(0), we simply receive "", even
> though it doesn't mean that we're at EOF. Shouldn't we avoid this (rare, I
> admit) ambiguity on the return value, by preventing read(0) ? Or at least,
> note in the doc that (we receive an empty string) <-> (the file is at EOF OR
> we called read with 0 as parameter) ?
>
> Are there some arguments that I don't know, which lead to this or that
> particular implementation choice ?
> I'd strongly advocate very detailled specifications, letting no room for
> cross-platform subtilities (that's also a strong goal of my
> reimplemntation), since that new IO system (which saved me a lot of coding
> time, by the way) should become the base of many programs.
>
> So wouldn't it be a godo idea to write some kind of mini-pep, just to fix
> the corner cases of the current IO documentation ? I might handle it, if no
> more-knowledgeable people feels like it.
>
> Regards,
> Pascal
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fuzziness in io module specs

[MRAB]

[Oops! Hit Send to soon]

Pascal Chambon wrote:

Hello everyone

I'm currently working on a reimplementation of io.FileIO, which would 
allow cross-platform file range locking and all kinds of other safety 
features ; however I'm slightly stuck due to some specification 
fuzziness in the IO docs.

CF http://bugs.python.org/issue6939

The main points that annoy me at the moment :
- it is unclear what truncate() methods do with the file pointer, and 
even if the current implementation simply moves it to the truncation 
point, it's very contrary to the standard way of doing under unix, where 
the file pointer is normally left unchanged. Shouldn't we specify that 
the file pointer remains unmoved, and fix the _fileio module accordingly ?


I think that this should be an invariant:

0 <= file pointer <= file size

so the file pointer might sometimes have to be moved.

- exceptions are not always specified, and even if most of them are 
IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if 
we try to wrap a wrong file descriptor when instanciating a new FileIO). 
This might lead to bad program crashes if some people don't "refuse the 
temptation to guess" and only get prepared to catch IOErrors
- the doc sometimes says that when we receive an empty string from a 
read() operation, without exceptions, it means the file is empty. 
However, with the current implementation, if we call file.read(0), we 
simply receive "", even though it doesn't mean that we're at EOF. 
Shouldn't we avoid this (rare, I admit) ambiguity on the return value, 
by preventing read(0) ? Or at least, note in the doc that (we receive an 
empty string) <-> (the file is at EOF OR we called read with 0 as 
parameter) ?



If you ask for 0 bytes then you get 0 bytes.

Are there some arguments that I don't know, which lead to this or that 
particular implementation choice ?
I'd strongly advocate very detailled specifications, letting no room for 
cross-platform subtilities (that's also a strong goal of my 
reimplemntation), since that new IO system (which saved me a lot of 
coding time, by the way) should become the base of many programs.


So wouldn't it be a godo idea to write some kind of mini-pep, just to 
fix the corner cases of the current IO documentation ? I might handle 
it, if no more-knowledgeable people feels like it.



As for the question of whether 'truncate' should be able to lengthen a
file, the method name suggests no; if the method name were 'resize', for
example, then maybe yes, zeroing the new bytes for security.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fuzziness in io module specs

[Matthew Barnett]

Pascal Chambon wrote:

Hello everyone

I'm currently working on a reimplementation of io.FileIO, which would 
allow cross-platform file range locking and all kinds of other safety 
features ; however I'm slightly stuck due to some specification 
fuzziness in the IO docs.

CF http://bugs.python.org/issue6939

The main points that annoy me at the moment :
- it is unclear what truncate() methods do with the file pointer, and 
even if the current implementation simply moves it to the truncation 
point, it's very contrary to the standard way of doing under unix, where 
the file pointer is normally left unchanged. Shouldn't we specify that 
the file pointer remains unmoved, and fix the _fileio module accordingly ?


I think that this should be an invariant:

0 <= file pointer <= file size

so the file pointer might sometimes have to be moved.

- exceptions are not always specified, and even if most of them are 
IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if 
we try to wrap a wrong file descriptor when instanciating a new FileIO). 
This might lead to bad program crashes if some people don't "refuse the 
temptation to guess" and only get prepared to catch IOErrors
- the doc sometimes says that when we receive an empty string from a 
read() operation, without exceptions, it means the file is empty. 
However, with the current implementation, if we call file.read(0), we 
simply receive "", even though it doesn't mean that we're at EOF. 
Shouldn't we avoid this (rare, I admit) ambiguity on the return value, 
by preventing read(0) ? Or at least, note in the doc that (we receive an 
empty string) <-> (the file is at EOF OR we called read with 0 as 
parameter) ?



If you ask for 0 bytes then you get 0 bytes.

Are there some arguments that I don't know, which lead to this or that 
particular implementation choice ?
I'd strongly advocate very detailled specifications, letting no room for 
cross-platform subtilities (that's also a strong goal of my 
reimplemntation), since that new IO system (which saved me a lot of 
coding time, by the way) should become the base of many programs.


So wouldn't it be a godo idea to write some kind of mini-pep, just to 
fix the corner cases of the current IO documentation ? I might handle 
it, if no more-knowledgeable people feels like it.




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fuzziness in io module specs

[James Y Knight]

On Sep 18, 2009, at 3:55 PM, MRAB wrote:


I think that this should be an invariant:

   0 <= file pointer <= file size

so the file pointer might sometimes have to be moved.



As for the question of whether 'truncate' should be able to lengthen a
file, the method name suggests no; if the method name were 'resize',  
for

example, then maybe yes, zeroing the new bytes for security.



Why are you just making things up? There is a *vast* amount of  
precedent for how file operations should work. Python should follow  
that precedent and do like POSIX unless there's a compelling reason  
not to. Quoting:


   If  fildes  refers  to  a  regular  file,  the ftruncate()  
function shall cause the size of the file to be truncated to
   length. If the size of the file previously exceeded length,  
the extra data shall no longer be available to reads on the
   file.  If  the  file  previously  was smaller than this size,  
ftruncate() shall either increase the size of the file or
   fail.   XSI-conformant systems shall increase the size of the  
file.  If the file size is increased, the  extended  area
   shall appear as if it were zero-filled. The value of the seek  
pointer shall not be modified by a call to ftruncate().


James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fuzziness in io module specs

[Daniel Stutzbach]

On Fri, Sep 18, 2009 at 2:17 PM, Pascal Chambon wrote:

> - it is unclear what truncate() methods do with the file pointer, and even
> if the current implementation simply moves it to the truncation point, it's
> very contrary to the standard way of doing under unix, where the file
> pointer is normally left unchanged. Shouldn't we specify that the file
> pointer remains unmoved, and fix the _fileio module accordingly ?
>

+1 on having consistent, documented behavior (regardless of what that
behavior is :) ).


> - exceptions are not always specified, and even if most of them are
> IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if we
> try to wrap a wrong file descriptor when instanciating a new FileIO). This
> might lead to bad program crashes if some people don't "refuse the
> temptation to guess" and only get prepared to catch IOErrors
>

I'd wager that you may also get a WindowsError in some cases, on Windows
systems.  Part of the reason for having several different, but similar,
exceptions is that they may contain operating system specific error codes
and the type of exception helps the programmer figure out how to interpret
those codes.  I'm not really clear on when IOError is preferred over
OSError, but I know that WindowsError necessarily uses a completely
different error numbering system.

The careful programmer should catch EnvironmentError, which is the base
class of all of these different kinds of related errors.

+1 on documenting that the methods may raise an EnvironmentError.


> - the doc sometimes says that when we receive an empty string from a read()
> operation, without exceptions, it means the file is empty. However, with the
> current implementation, if we call file.read(0), we simply receive "", even
> though it doesn't mean that we're at EOF. Shouldn't we avoid this (rare, I
> admit) ambiguity on the return value, by preventing read(0) ? Or at least,
> note in the doc that (we receive an empty string) <-> (the file is at EOF OR
> we called read with 0 as parameter) ?
>

Some programs may rely on read(0) and the behavior matches the behavior of
POSIX, so I'm -1 on changing the behavior.  +1 on documenting the exception
to the rule.


> Are there some arguments that I don't know, which lead to this or that
> particular implementation choice ?
>

The original I/O PEP and some of the code was put together during a sprint
at PyCon 2007.  Our primary goal was to get a decent first cut of the new
I/O system put together quickly.  For nitty-gritty details and corner-cases
like these, there's a good chance that the current undocumented behavior is
simply an accident of implementation.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fuzziness in io module specs

[MRAB]

James Y Knight wrote:


On Sep 18, 2009, at 3:55 PM, MRAB wrote:


I think that this should be an invariant:

   0 <= file pointer <= file size

so the file pointer might sometimes have to be moved.



As for the question of whether 'truncate' should be able to lengthen a
file, the method name suggests no; if the method name were 'resize', for
example, then maybe yes, zeroing the new bytes for security.



Why are you just making things up? There is a *vast* amount of precedent 
for how file operations should work. Python should follow that precedent 
and do like POSIX unless there's a compelling reason not to. Quoting:


   If  fildes  refers  to  a  regular  file,  the ftruncate() 
function shall cause the size of the file to be truncated to
   length. If the size of the file previously exceeded length, the 
extra data shall no longer be available to reads on the
   file.  If  the  file  previously  was smaller than this size, 
ftruncate() shall either increase the size of the file or
   fail.   XSI-conformant systems shall increase the size of the 
file.  If the file size is increased, the  extended  area
   shall appear as if it were zero-filled. The value of the seek 
pointer shall not be modified by a call to ftruncate().



"making things up"? I'm just expressing an opinion!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fuzziness in io module specs

[Antoine Pitrou]

Le Fri, 18 Sep 2009 21:17:29 +0200, Pascal Chambon a écrit :


Hello,

First, thanks for experimenting with this.
(as a sidenote, we lack real-world testing of non-blocking features, 
perhaps you want to take a look)

> I'm currently working on a reimplementation of io.FileIO, which would 
> allow cross-platform file range locking and all kinds of other safety 
> features ;

Hmm, do you *have* to reimplement it in order to add these new features, 
or is it just a personal preference?

> - it is unclear what truncate() methods do with the file pointer, and 
> even if the current implementation simply moves it to the truncation 
> point, it's very contrary to the standard way of doing under unix, 
where 
> the file pointer is normally left unchanged. Shouldn't we specify that 
> the file pointer remains unmoved, and fix the _fileio module 
accordingly ?

Well, first Python and its IO library are cross-platform, so the 
behaviour is not always identical to POSIX behaviour, especially where 
Windows and Unix have different specs.

Second, now that 3.1 is in the wild, we should be reluctant to change the
behaviour just to make it more conformant to what POSIX people can 
expect. What might be convincing would be an actual use case where POSIX-
like behaviour would be significantly more useful than the current on.

> - exceptions are not always specified, and even if most of them are 
> IOErrors, weirdly, in some cases, an OSError is raised instead (ie, if 
> we try to wrap a wrong file descriptor when instanciating a new 
FileIO). 

This is not different than with 2.x here. If you want to trap both 
OSError and IOError, use EnvironmentError (which is the common base class 
for both).

I agree it is slightly annoying and not well-defined, however. Also, 
Python can hardly determine by itself whether an error is caused by IO 
problems or an OS-level malfunction, so the distinction is a bit 
fallacious.

> However, with the current implementation, if we call file.read(0), we 
> simply receive "", even though it doesn't mean that we're at EOF. 
> Shouldn't we avoid this (rare, I admit) ambiguity on the return value, 
> by preventing read(0) ?

Well, if you are asking for 0 bytes, it returns 0 bytes. It's not that
ambiguous, and it helps avoid special-casing the 0 case :)

> So wouldn't it be a godo idea to write some kind of mini-pep, just to 
> fix the corner cases of the current IO documentation ?

Improvements, either to the docs or to the implementation, are always 
welcome. I think you already know where to post them!

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] POSIX [Fuzziness in io module specs]

[Antoine Pitrou]

James Y Knight  fuhm.net> writes:
> 
> Why are you just making things up? There is a *vast* amount of  
> precedent for how file operations should work. Python should follow  
> that precedent and do like POSIX unless there's a compelling reason  
> not to.

Actually, Python is cross-platform and therefore does not necessarily follow
POSIX behaviour, especially when it is desired to hide inconsistencies between
different platform.

(I do agree, of course, that the IO APIs are quite heavily inspired by the POSIX
APIs)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] POSIX [Fuzziness in io module specs]

[Stephen J. Turnbull]

Antoine Pitrou writes:
 > James Y Knight  fuhm.net> writes:
 > > 
 > > Why are you just making things up? There is a *vast* amount of  
 > > precedent for how file operations should work. Python should follow  
 > > that precedent and do like POSIX unless there's a compelling reason  
 > > not to.
 > 
 > Actually, Python is cross-platform and therefore does not
 > necessarily follow POSIX behaviour, especially when it is desired
 > to hide inconsistencies between different platform.

That's what *James* said, except that I prefer his standard, because I
believe POSIX documentation to be more accessible to a variety of
Python developers than other system's, and it's better documented:
rationales are included, history is available, etc.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] POSIX [Fuzziness in io module specs]

[Antoine Pitrou]

Le Sat, 19 Sep 2009 09:19:53 +0900, Stephen J. Turnbull a écrit :
> Antoine Pitrou writes:
>  > James Y Knight  fuhm.net> writes:
>  > > 
>  > > Why are you just making things up? There is a *vast* amount of
>  > > precedent for how file operations should work. Python should follow
>  > > that precedent and do like POSIX unless there's a compelling reason
>  > > not to.
>  > 
>  > Actually, Python is cross-platform and therefore does not necessarily
>  > follow POSIX behaviour, especially when it is desired to hide
>  > inconsistencies between different platform.
> 
> That's what *James* said, except that I prefer his standard,

I don't believe that POSIX compliance is a sufficient argument to ask 
someone to shut up in the discussion of a cross-platform API. Which is 
more or less what James' answer was trying to do. So, no, not exactly the 
same thing that I said.

> I
> believe POSIX documentation to be more accessible to a variety of Python
> developers than other system's, and it's better documented: rationales
> are included, history is available, etc.

I'm not sure that's true. Various Unix/Linux man pages are readily 
available on the Internet, but they regard specific implementations, 
which often depart from the spec in one way or another. POSIX specs 
themselves don't seem to be easily reachable; you might even have to pay 
for them.

cheers

Antoine.

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] POSIX [Fuzziness in io module specs]

[James Y Knight]

On Sep 18, 2009, at 8:58 PM, Antoine Pitrou wrote:

I'm not sure that's true. Various Unix/Linux man pages are readily
available on the Internet, but they regard specific implementations,
which often depart from the spec in one way or another. POSIX specs
themselves don't seem to be easily reachable; you might even have to  
pay

for them.



The POSIX specs are quite easily accessible, without payment.

I got my quote by doing:
man 3p ftruncate

I had previously done:
apt-get install manpages-posix-dev
to install the posix manpages. That package contains the POSIX  
standard as of 2003. Which is good enough for most uses. It seems to  
be available here, if you don't have a debian system:

http://www.kernel.org/pub/linux/docs/man-pages/man-pages-posix/

There's also a webpage, containing the official POSIX 2008 standard:
   http://www.opengroup.org/onlinepubs/9699919799/

And to navigate to ftruncate from there, click "System Interfaces" in  
the left pane, "System Interfaces" in the bottom pane, and then  
"ftruncate" in the bottom pane.


James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3144 review.

[Greg Ewing]

Eric Smith wrote:

My only concern with this is a possible performance issue with v6 
networks. Would this be implemented such that [-1] doesn't need to 
iterate through the (possibly large) address space of a v6 network?


I'm not familiar with v6, but if netmasks work the same
way as they do in v4, then there's no need to iterate
over anything -- it's just a matter of turning on all
the low bits of the address.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com