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

2009-09-19 Thread Stephen J. Turnbull 
Antoine Pitrou writes:

 > 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.

No, as I read it, James said, "when there's precedent, even a
standard, don't make stuff up".  He then referred to the POSIX
standard, which I assume means that's a standard he likes.  But he
didn't say it had to be POSIX, or else shut up.  He said, "respect
precedent" (and implied that ignorance is no excuse, I guess, which is
a little harsh on the Internet).

And I think he'd agree to weaken his dictum to add "and if there's
good reason to vary from the standard, either quote other standards or
give rationale referring to why you want to vary from the standard."

 > I'm not sure that's true [that POSIX is readily available]. [...] 
 > POSIX specs themselves don't seem to be easily reachable; you might
 > even have to pay for them.

Five minutes with Google gives

http://standards.ieee.org/catalog/olis/arch_posix.html (IEEE members only)
http://www.unix.org/version3/ (registration but no fee required)
http://www.opengroup.org/onlinepubs/95399/toc.htm (title page for above,
lets you sneak past the registration, and has higher Googlefu)

Older versions also seem to be readily available.
___
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Pascal Chambon 


@pitrou: non-blocking IO in python ? which ones are you thinking about ?
I have currently no plan to work on asynchronous IO like win32's 
readFileEx() etc. (too many troubles for the benefit), however I'd be 
interested by getting non-blocking operations on IPC pipes (I've crossed 
several people in trouble with that, having a process never end on some 
OSes because they couldn't stop threads blocked on pipes).
This reimplementation is actually necessary to get file locking, because 
advanced win32 operations only work on real file handles, not the 
handles that are underlying the C API layer. Furthermore, some 
interesting features (like O_EXCL | O_CREAT) are not possible with the 
current io implementations. So well, reimplementation required ^^


Else, allright, I'll try to summarize the various points in a PEP-update.

Concerning the "truncate" method however, on second thought I feel we 
might take distance from Posix API for naming, precisely since it's 
anyway too "platform-specific" (windows knows nothing about Posix, and 
even common unix-like systems modify it in a way or another - several 
systems don't zero-fill files when extending them).
When seeing "truncate", in my opinion, most people will think "it's only 
to reduce file size" (for beginners), or will immediately get in mind 
all the tips of posix-like systems (for more experienced developers). 
Shouldn't we, like other cross-platform APIs, use a more unambiguous 
notion, like "setLength" (java) or "resize" (Qt) ? And let the 
filepointer untouched, simply because there are no reasons to move it, 
especially when extending the file (yep, on windows we're forced to move 
the pointer, but it's easy to fix) ?
If it's too late to modify the IO API, too bad, but I don't feel 
comfortable with the "truncate" word. And I don't like the fact that we 
move the filepointer to prevent it from exceeding the file size, whereas 
on the other hand we can seek() anywhere without getting exceptions (and 
so, set the filepointer past the end of file). Having 0 <= filepointer 
<= EOF is OK to me, but then we have to enforce it for all functions, 
not just truncate.


Concerning exceptions, which one is raised is not so important to me, as 
long as it's well documented and not tricky (eg. WindowsErrors are OK to 
me, because they subclass OSError, so most cross-platform programs wont 
even have to know about them).
I had the feeling that IOErrors were for operations on file streams 
(opening, writing/reading, closing...), whereas OSErrors were for 
manipulations on filesystems (renaming, linking, stating...) and 
processes. This semantic would be perfect for me, and it's already 95% 
here, we would just have to fix some unwelcomed OSErrors exceptions in 
the iomodule. Isn't that worth it ? It'd simplify programmers' job a 
lot, and allow a more subtle treatment of exceptions (if everyone just 
catches Environment errors, without being sure of which subcless is 
actually raised, we miss the point of IOError and OSError).


Regards,
Pascal







James Y Knight a écrit :


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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/firephoenix%40wanadoo.fr 









___
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] conceptual clarity

2009-09-19 Thread David Harrison 
2009/9/18 Peter Moody :
> 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.
>
> Cheers,
> /peter

For any given use-case there is bound to be an opposing one, but the
goal is to satisfy the most common or relevant use-cases that we all
experience - can't please all the people all the time etc.

I think that alot of the confusion and disagreements surrounding the
API are due to the absence of use-cases in the PEP - we can all
probably agree an IP address module has intrinsic merit, but how we
expect to use it may vary significantly.  As a result the discussion
seems to be driven by the example implementation, instead of the by
the use-cases that make the module worthwhile being added - I would
normally think it would be the other way round.  Without a clear set
of expectations and use-cases, it would also be hard to propose an
alternate implementation.
___
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Daniel Stutzbach 
On Sat, Sep 19, 2009 at 2:46 AM, Pascal Chambon wrote:

> This reimplementation is actually necessary to get file locking, because
> advanced win32 operations only work on real file handles, not the handles
> that are underlying the C API layer. Furthermore, some interesting features
> (like O_EXCL | O_CREAT) are not possible with the current io
> implementations. So well, reimplementation required ^^
>


> Concerning exceptions, which one is raised is not so important to me, as
> long as it's well documented and not tricky (eg. WindowsErrors are OK to me,
> because they subclass OSError, so most cross-platform programs wont even
> have to know about them).
>

If you use real Windows file handles (instead of the POSIX-ish Windows API),
won't you need to return WindowsErrors?


> I had the feeling that IOErrors were for operations on file streams
> (opening, writing/reading, closing...), whereas OSErrors were for
> manipulations on filesystems (renaming, linking, stating...) and processes.
>

If that were documented and a firm rule, that would certainly be great.
It's not too hard to find counterexamples in the current codebase.  Also,
I'm not sure how one could avoid needing to raise WindowsError in some
cases.

Maybe someone with more knowledge of the history of IOError vs. OSError
could chime in.

Python 2.6:

>>> os.write(f.fileno(), 'blah')
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 9] Bad file descriptor
>>> f.write('blah')
Traceback (most recent call last):
  File "", line 1, in 
IOError: [Errno 9] Bad file descriptor

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Pascal Chambon 
Good example with "os.write(f.fileno(), 'blah')" - and you obtain the 
same error if you try to open an io.FileIo by providing a file 
descriptor instead of a file name as first argument. This would really 
deserve an unification.


Actually, since Windows Error Codes concern any possible error (IO, file 
permissions, memory problems...), I thought the best would be to convert 
them to the most appropriate python standard exception, only defaulting 
to WindowsError (i.e, OSError's hierarchy) when no other exception type 
matches. So at the moment, I use a decorator to automatically convert 
all errors on stream operations into IOErrors. Error codes are not the 
same as unix ones indeed, but I don't know if it's really important 
(imo, most people just want to know if the operation was successful, I 
don't know if many developers scan error codes to act accordingly). For 
IOError types that really matter (eg. file already locked, buffer full), 
the easiest is actually to use subclasses of IOError (the io module 
already does that, even though I'll maybe have to create new exceptions 
for errors like "file already exists" or "file already locked by another 
process")


Regards,
Pascal

Daniel Stutzbach a écrit :
On Sat, Sep 19, 2009 at 2:46 AM, Pascal Chambon 
mailto:[email protected]>> wrote:


This reimplementation is actually necessary to get file locking,
because advanced win32 operations only work on real file handles,
not the handles that are underlying the C API layer. Furthermore,
some interesting features (like O_EXCL | O_CREAT) are not possible
with the current io implementations. So well, reimplementation
required ^^

 


Concerning exceptions, which one is raised is not so important to
me, as long as it's well documented and not tricky (eg.
WindowsErrors are OK to me, because they subclass OSError, so most
cross-platform programs wont even have to know about them).


If you use real Windows file handles (instead of the POSIX-ish Windows 
API), won't you need to return WindowsErrors?
 


I had the feeling that IOErrors were for operations on file
streams (opening, writing/reading, closing...), whereas OSErrors
were for manipulations on filesystems (renaming, linking,
stating...) and processes.


If that were documented and a firm rule, that would certainly be 
great.  It's not too hard to find counterexamples in the current 
codebase.  Also, I'm not sure how one could avoid needing to raise 
WindowsError in some cases.


Maybe someone with more knowledge of the history of IOError vs. 
OSError could chime in.


Python 2.6:

>>> os.write(f.fileno(), 'blah')
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 9] Bad file descriptor
>>> f.write('blah')
Traceback (most recent call last):
  File "", line 1, in 
IOError: [Errno 9] Bad file descriptor

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC
 




___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/firephoenix%40wanadoo.fr
  


___
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Daniel Stutzbach 
On Sat, Sep 19, 2009 at 5:31 AM, Pascal Chambon wrote:

>  Actually, since Windows Error Codes concern any possible error (IO, file
> permissions, memory problems...), I thought the best would be to convert
> them to the most appropriate python standard exception, only defaulting to
> WindowsError (i.e, OSError's hierarchy) when no other exception type
> matches. So at the moment, I use a decorator to automatically convert all
> errors on stream operations into IOErrors. Error codes are not the same as
> unix ones indeed, but I don't know if it's really important (imo, most
> people just want to know if the operation was successful, I don't know if
> many developers scan error codes to act accordingly).
>

I don't often need to check the error code at runtime but seeing the
corresponding message is often critical for debugging.

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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.

2009-09-19 Thread Cameron Simpson 
On 18Sep2009 07:48, Nick Coghlan  wrote:
| Eric Smith wrote:
| > Peter Moody wrote:
| >> indexing is plenty efficient, but the problem is that these names for
| >> these attributes are common to the point of causing confusion if
| >> they're omitted.
| > 
| > After thinking about it some more, I'm okay with names for [-1] and [0].
| > I like .broadcast, and I can live with .network (although it's
| > confusing, since in my view it should return an address, not a network).
| 
| And in fact *does* return an Address - the same address that my_net[0]
| returns.

Yes, I think Eric was complaining about the name being "network", since
we have Network objects and this isn't one.
-- 
Cameron Simpson  DoD#743
http://www.cskk.ezoshosting.com/cs/
___
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.

2009-09-19 Thread Eric Smith 

Cameron Simpson wrote:

On 18Sep2009 07:48, Nick Coghlan  wrote:
| Eric Smith wrote:
| > Peter Moody wrote:
| >> indexing is plenty efficient, but the problem is that these names for
| >> these attributes are common to the point of causing confusion if
| >> they're omitted.
| > 
| > After thinking about it some more, I'm okay with names for [-1] and [0].

| > I like .broadcast, and I can live with .network (although it's
| > confusing, since in my view it should return an address, not a network).
| 
| And in fact *does* return an Address - the same address that my_net[0]

| returns.

Yes, I think Eric was complaining about the name being "network", since
we have Network objects and this isn't one.


Right. thing_commonly_referred_to_as_network_but_is_an_address.

___
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Pascal Chambon 


@pitrou: non-blocking IO in python ? which ones are you thinking about ?
I have currently no plan to work on asynchronous IO like win32's 
readFileEx() etc. (too many troubles for the benefit), however I'd be 
interested by getting non-blocking operations on IPC pipes (I've crossed 
several people in trouble with that, having a process never end on some 
OSes because they couldn't stop threads blocked on pipes).
This reimplementation is actually necessary to get file locking, because 
advanced win32 operations only work on real file handles, not the 
handles that are underlying the C API layer. Furthermore, some 
interesting features (like O_EXCL | O_CREAT) are not possible with the 
current io implementations. So well, reimplementation required ^^


Else, allright, I'll try to summarize the various points in a PEP-update.

Concerning the "truncate" method however, on second thought I feel we 
might take distance from Posix API for naming, precisely since it's 
anyway too "platform-specific" (windows knows nothing about Posix, and 
even common unix-like systems modify it in a way or another - several 
systems don't zero-fill files when extending them).
When seeing "truncate", in my opinion, most people will think "it's only 
to reduce file size" (for beginners), or will immediately get in mind 
all the tips of posix-like systems (for more experienced developers). 
Shouldn't we, like other cross-platform APIs, use a more unambiguous 
notion, like "setLength" (java) or "resize" (Qt) ? And let the 
filepointer untouched, simply because there are no reasons to move it, 
especially when extending the file (yep, on windows we're forced to move 
the pointer, but it's easy to fix) ?
If it's too late to modify the IO API, too bad, but I don't feel 
comfortable with the "truncate" word. And I don't like the fact that we 
move the filepointer to prevent it from exceeding the file size, whereas 
on the other hand we can seek() anywhere without getting exceptions (and 
so, set the filepointer past the end of file). Having 0 <= filepointer 
<= EOF is OK to me, but then we have to enforce it for all functions, 
not just truncate.


Concerning exceptions, which one is raised is not so important to me, as 
long as it's well documented and not tricky (eg. WindowsErrors are OK to 
me, because they subclass OSError, so most cross-platform programs wont 
even have to know about them).
I had the feeling that IOErrors were for operations on file streams 
(opening, writing/reading, closing...), whereas OSErrors were for 
manipulations on filesystems (renaming, linking, stating...) and 
processes. This semantic would be perfect for me, and it's already 95% 
here, we would just have to fix some unwelcomed OSErrors exceptions in 
the iomodule. Isn't that worth it ? It'd simplify programmers' job a 
lot, and allow a more subtle treatment of exceptions (if everyone just 
catches Environment errors, without being sure of which subcless is 
actually raised, we miss the point of IOError and OSError).


Regards,
Pascal

James Y Knight a écrit :


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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/firephoenix%40wanadoo.fr 






___
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Martin v. Löwis 
>> 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.

Then please rest assured that it actually *is* true:
- the Linux man pages are often a literal copy of the POSIX man pages,
  so when you look at a Linux man page, there is a good chance that it
  either is the wording of the POSIX spec, or points out what details
  are specific to POSIX.
- The Open Group publishes POSIX free of charge, and these days also
  free of registration.
- these days, specific implementations typically do *not* deviate from
  POSIX. Some provide additional features, but in a way that does not
  harm compatibility.

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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread R. David Murray 

On Sat, 19 Sep 2009 at 12:31, Pascal Chambon wrote:
stream operations into IOErrors. Error codes are not the same as unix ones 
indeed, but I don't know if it's really important (imo, most people just want 
to know if the operation was successful, I don't know if many developers scan 
error codes to act accordingly). For IOError types that really matter (eg.


Doesn't matter if it isn't very many, I think, just that it can be done.
But I suspect it is fairly common.  I know I have inspected OSError codes
(though I can't remember if I've done it for file operations).

--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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Nick Coghlan 
Pascal Chambon wrote:
> (imo, most people just want to know if the operation was successful, I
> don't know if many developers scan error codes to act accordingly).

And as a user of applications written by those developers, it is a
practice I detest with a passion. Debugging environmental problems is
painful enough without further encouraging applications that lie to
their users as to what has actually gone wrong.

For example, a file not existing, a file being locked by another
process, and the user not having write permissions to the file are
problems that demand very different responses from the user.
Applications that give the same error message for all three problems are
far too common.

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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Antoine Pitrou 

Hello,

Pascal Chambon  gmail.com> writes:
> @pitrou: non-blocking IO in python ? which ones are you thinking about ?

I was talking about the existing support for non-blocking IO in the FileIO class
(look up EAGAIN in fileio.c), as well as in the Buffered* objects.

> If it's too late to modify the IO API, too bad, but I don't feel 
> comfortable with the "truncate" word.

It's certainly too late to modify the IO API only for naming purposes.

> And I don't like the fact that we 
> move the filepointer to prevent it from exceeding the file size,

I don't see what you mean:

>>> with open('foobar', 'wb') as f:
...   f.truncate(0)
... 
0
>>> os.stat('foobar').st_size
0
>>> with open('foobar', 'wb') as f:
...   f.truncate(16)
...   f.tell()
... 
16
16
>>> os.stat('foobar').st_size
16

> I had the feeling that IOErrors were for operations on file streams 
> (opening, writing/reading, closing...), whereas OSErrors were for 
> manipulations on filesystems (renaming, linking, stating...) and 
> processes.

Ok, but the distinction is certainly fuzzy in many cases. I have no problem with
trying to change the corner cases you mention, though.

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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Pascal Chambon 




Antoine Pitrou a écrit :

Hello,

Pascal Chambon  gmail.com> writes:
  

@pitrou: non-blocking IO in python ? which ones are you thinking about ?



I was talking about the existing support for non-blocking IO in the FileIO class
(look up EAGAIN in fileio.c), as well as in the Buffered* objects.

  


Allright, I'll check that EAGAIN stuff, that I hadn't even noticed  :)



And I don't like the fact that we 
move the filepointer to prevent it from exceeding the file size,



I don't see what you mean:

  


Well the sample code you showed is not shocking, but I'd like to have a 
coherency the with file.seek(), because if truncate() prevents 
out-of-bound file pointer, other methods should do the same as well (and 
raise IOError when seeking out of file bounds).




I had the feeling that IOErrors were for operations on file streams 
(opening, writing/reading, closing...), whereas OSErrors were for 
manipulations on filesystems (renaming, linking, stating...) and 
processes.



Ok, but the distinction is certainly fuzzy in many cases. I have no problem with
trying to change the corner cases you mention, though.
  
The case which could be problematic there is the file opening, because 
it can involve problems at all levels of the OS (filesystem not 
existing, permission problems, file locking...), so we should keep it in 
the "EnvironmentError" area.
But as soon as a file is open, I guess only IOErrors can be involved (no 
space left, range locked etc), so enforcing all this to raise IOError 
would be OK I think.
___
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.6.3

2009-09-19 Thread qwavel 


Barry Warsaw wrote:
> 
> On Sep 15, 2009, at 9:53 AM, Ronald Oussoren wrote:
> 
>> The IDLE issue is IMHO a release blocker, as is issue 6851.
> 
> So that leaves 4 release blockers for 2.6.3.
> 

What about this bug:
http://bugs.python.org/issue3890
It appears to me that the SSL module is broken in the 2.6.x line on all
platforms in one of its most common uses (non-blocking).  It also seems that
the problem and solution are well understood, so the solution would make a
good candidate for 2.6.3?
Tom.




-- 
View this message in context: 
http://www.nabble.com/Python-2.6.3-tp25364517p25524412.html
Sent from the Python - python-dev mailing list archive at Nabble.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] Python 2.6.3

2009-09-19 Thread Bill Janssen 
qwavel  wrote:

> What about this bug:
> http://bugs.python.org/issue3890
> It appears to me that the SSL module is broken in the 2.6.x line on all
> platforms in one of its most common uses (non-blocking).  It also seems that
> the problem and solution are well understood, so the solution would make a
> good candidate for 2.6.3?
> Tom.

I might quibble about "most common uses", but I agree this would be a good idea.

Bill
___
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Steven D'Aprano 
On Sat, 19 Sep 2009 08:31:15 pm Pascal Chambon wrote:
> Error codes are not the
> same as unix ones indeed, but I don't know if it's really important
> (imo, most people just want to know if the operation was successful,
> I don't know if many developers scan error codes to act accordingly).

I do. Please don't throw away useful information.


-- 
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Greg Ewing 

Pascal Chambon wrote:


And let the 
filepointer untouched, simply because there are no reasons to move it,


On some systems it may not be possible for the file pointer to
be positioned past the end of the file (I think Classic MacOS
was like that).

I had the feeling that IOErrors were for operations on file streams 
(opening, writing/reading, closing...), whereas OSErrors were for 
manipulations on filesystems (renaming, linking, stating...)


I always thought the distinction was that IOError contains
a C library errno value, whereas OSError contains an
OS-specific error code. So system calls that aren't part
of the C stdlib need to use OSError, at least on some
platforms.

I don't see that file errors vs. everything else is
a very useful distinction to make when catching exceptions.
I almost always end up catching EnvironmentError to make
sure I get both, particularly when working cross-platform.

What we could do with is better platform-independent
ways of distinguishing particular error conditions,
such as file not found, out of space, etc., either
using subclasses of IOError or mapping error codes
to a set of platform-independent ones.

--
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] Fuzziness in io module specs

2009-09-19 Thread Steven D'Aprano 
On Sat, 19 Sep 2009 06:08:23 am 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? 

Well, why not? The POSIX standard wasn't derived from the physical laws 
of the universe, somebody -- or more likely, some committee -- made 
them up. It's not like we are forced to accept MRAB's suggestions, but 
surely he's allowed to make them?

> 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().

Standard or not, it has a seriously misleading name. Truncate means "to 
cut off", and is a standard English word and mathematical term. In 
English and mathematics, truncating something can NEVER lead it to 
increase in size, the object being truncated can only decrease or 
remain the same size.

Using "truncate" to mean "increase in size" makes about as much sense as 
having a list method called "remove" used to insert items. I can't 
imagine what the committee who approved this were thinking.

Java's FileChannel object uses truncate to only shrink a file, never 
increase it. To increase it, you have to explicitly write to the file.

http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/FileChannel.html#truncate(long)

In any case, some platforms don't allow the file pointer to exceed the 
size of the file, so it's not clear that the POSIX standard is 
appropriate for Python.



-- 
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] POSIX [Fuzziness in io module specs]

2009-09-19 Thread Greg Ewing 

Nick Coghlan wrote:


For example, a file not existing, a file being locked by another
process, and the user not having write permissions to the file are
problems that demand very different responses from the user.


You can display an error-specific message without having
to inspect the error code, e.g.

  try:
something_with_file(path)
  except EnvironmentError, e:
report_error("Couldn't do that with %s: %s" % (path, e))

This is a pattern I use a lot, and it seems to work
pretty well.

--
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] Fuzziness in io module specs

2009-09-19 Thread Greg Ewing 

Steven D'Aprano wrote:

Using "truncate" to mean "increase in size" makes about as much sense as 
having a list method called "remove" used to insert items. I can't 
imagine what the committee who approved this were thinking.


I expect the reason is historical. Some time back in the
early days of Unix, someone wanted a way of chopping back
files, so they added a truncate() system call. Then someone
else noticed that it would happily accept an argument greater
than the existing length, and it seemed like that could
be useful behaviour, so they documented it and left it that way.

Then the POSIX committee came along and incorporated it into
the standard so as to be compatible with existing practice.

--
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