R. David Murray added the comment:
Nikolaus: while I agree that Raymond's comments were a bit strongly worded, it
doesn't read to me as if the thread you link to is on point for this issue.
The thread was focused on a *specific* question, that of calling close twice.
The question of what
Nikolaus Rath added the comment:
R. David Murray rep...@bugs.python.org writes:
R. David Murray added the comment:
Nikolaus: while I agree that Raymond's comments were a bit strongly
worded, it doesn't read to me as if the thread you link to is on point
for this issue. The thread was
R. David Murray added the comment:
Well, but we think it's pretty clear. The glossary entry says file object
interfaces are defined by the classes in the io module. As do the io module
docs. Perhaps the first sentence of the io docs could be modified to
strengthen that (but it already does
R. David Murray added the comment:
Re-reading my last paragraph, I see that I'm pretty much agreeing with you. So
the contention is more that we don't think your suggested patch is necessary.
Especially since, unlike your patch wording says, in fact most of the methods
*are* implemented in
Antoine Pitrou added the comment:
Rather than a note, there could be a separate section for guidelines when
implementing one's own IO classes. Assuming there's anything significant to put
in such a section, that is :-)
--
___
Python tracker
Nikolaus Rath added the comment:
On 06/17/2014 01:28 PM, R. David Murray wrote:
Well, but we think it's pretty clear.
This wasn't the impression that I had from the thread on python-devel,
but I'll accept your judgement on that. I'll be more restrained when
being asked for suggestions in the
R. David Murray added the comment:
I believe Antoine was suggesting that you suggest wording that would make it
clear (rather than implied) that close was idempotent, but This method has no
effect if the file is already closed seems pretty unambiguous to me, so I
don't really see anything to
Nick Coghlan added the comment:
I can add a third suggestion: a HOWTO guide on implementing and using
file-like objects. It's actually a somewhat complex topic with various
trade-offs involved, particularly in Python 3 where the differences between
binary and text IO are greater. It could also
Nikolaus Rath added the comment:
On 06/15/2014 06:26 PM, Raymond Hettinger wrote:
Before creating more tracker items, please take time to learn about how
Python's history,
[...]
It'd be nice if you would have at least followed the link to
R. David Murray added the comment:
I don't think that's true, though. file like pretty much means has the file
attributes that I actually use. That is, it is context dependent (duck
typing).
I'm also not sure I see the point in the change. It is inherent in the
definition of what ABCs
Nikolaus Rath added the comment:
On 06/15/2014 08:29 AM, R. David Murray wrote:
I don't think that's true, though. file like pretty much means has the
file attributes that I actually use. That is, it is context dependent (duck
typing).
Well, but when you pass your file-like object to
Nick Coghlan added the comment:
Asking the question Does it quack and walk *enough* like a duck for my
code to work and my tests to pass? is part of the nature of ducktyping.
ABCs are definitely a useful guide to expectations, but even there it's
possible to lie to the interpreter and have
Nikolaus Rath added the comment:
Maybe I'm missing some important point here, but I think that the documentation
ought to tell me how I have to design a file-like object such that it fulfills
all expectations of the standard library.
Yes, you can get away with less than that in many
Raymond Hettinger added the comment:
[R David Murray]
I don't think that's true, though. file like pretty much means
has the file attributes that I actually use.
That is, it is context dependent (duck typing).
That is pretty much on-target.
Also, the phrase file-like has been used very
New submission from Nikolaus Rath:
It is currently not perfectly clear what Python (and the standard library)
assumes about file-like objects (see e.g.
http://article.gmane.org/gmane.comp.python.devel/148199).
The attached doc patch tries to improve the current situation by stating
15 matches
Mail list logo
