Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes: > This is exactly what I'm getting at: I can see the potential > use for resource management (which is what started out the > whole idea IIRC), but fail to see why you'd want to use it > for anything more complicated than that. I, as a concrete example, want to be able to write: with output_to_file(f): print stuff function_that_prints_stuff() and have the printed things end up in the file-like object f (in a single-threaded program, foom :) This is only a resource by a tortured defintion. > Note that hiding things away in smart objects like what you call > "context managers" will not make programs easier to understand, > unless the specific task that such a "context manager" is simple > enough to grasp by just looking at its definition in the with > statement... but then you'd not call it a "context manager". Of course, but there's no single term to describe all these simple things, and we need a single term to describe the objects designed to be used in the with statement for documentation purposes. Consensus on python-dev has settled on 'context manager', but personally I don't much care what it is so long as it isn't actively misleading (which I contend applies to 'resource manager'), it's just something people can look up in the index. > Let's keep things simple and Python nice. Are you arguing against PEP 343 as a whole, here? Cheers, mwh -- CLiki pages can be edited by anybody at any time. Imagine the most fearsomely comprehensive legal disclaimer you have ever seen, and double it-- http://ww.telent.net/cliki/index ___ 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] 'With' context documentation draft (was Re: Terminology for PEP 343
Raymond Hettinger wrote:
> {MAL]
>
>>This is exactly what I'm getting at: I can see the potential
>>use for resource management (which is what started out the
>>whole idea IIRC), but fail to see why you'd want to use it
>>for anything more complicated than that.
>
>
> Substitute "different" for "complicated".
>
> 'with' is not application specific, it is incredibly general. All it
> does is abstract recurring uses of try/finally.
>
> Naming it after a specific class of applications would be a mistake.
Exactly. Which is why "context manager" is IMHO the wrong description.
Calling it "block object" or "with object" or even "try-finally object"
would be more in line with the PEP without causing associations which
might lead to misunderstandings.
Please remember that you have to explain all these things to new
Python users. Over the last few years there have been tons of
new additions to the language - while some will probably disagree,
the learning curve for novices has gotten a lot steeper compared
to the pre-2.0 days when there was much resistance to adding new
features.
Nowadays, for a new programmer to get up and running
with the language and to start working on existing code, you have
to teach them about generators, iterators, decorators, the with
statement - since programs are starting to use these features
actively. More and more program logic gets hidden by the way of
introducing new objects and protocols.
If you then start using terms in the documentation that cause
wrong associations, you make life harder for new programmers.
Anyway, I think I've made my point.
Cheers,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jul 15 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] Adding the 'path' module (was Re: Some RFE for review)
Martin v. Löwis wrote:
> Guido van Rossum wrote:
>
>>Ah, sigh. I didn't know that os.listdir() behaves differently when the
>>argument is Unicode. Does os.listdir(".") really behave differently
>>than os.listdir(u".")? Bah! I don't think that's a very good design
>>(although I see where it comes from). Promoting only those entries
>>that need it seems the right solution
>
>
> Unfortunately, this solution is hard to implement (I don't know whether
> it is implementable at all correctly; atleast on Windows, I see no
> way to implement it efficiently).
>
> Here are a number of problems/questions:
> - On Windows, should listdir use the narrow or the wide API? Obviously
> the wide API, since it is not Python which returns the question marks,
> but the Windows API.
Right.
> - But then, the wide API gives all results as Unicode. If you want to
> promote only those entries that need it, it really means that you
> only want to "demote" those that don't need it. But how can you tell
> whether an entry needs it? There is no API to find out.
> You could declare that anything with characters >128 needs it,
> but that would be an incompatible change: If a character >128 in
> the system code page is in a file name, listdir currently returns
> it in the system code page. It then would return a Unicode string.
> Applications relying on the olde behaviour would break.
We will need a Python C API that returns:
* a string if the Unicode value is representable in the
default encoding (usually ASCII)
* Unicode if it is not
The file system encoding should be hidden in the OS
layer (e.g. posixmodule). Python should only return
strings with the default encoding and Unicode
otherwise.
See my suggestion to Neil about making the transition to
this new strategy less painful.
> - On Unix, all file names come out as byte strings. Again, how do
> you know which ones to promote, and using what encoding? Python
> currently guesses an encoding, but that may or may not be the one
> intended for the file name.
This is a tough one: AFAIK the file system encoding in Unix
was never really specified, in fact most file systems just
stored the names as-is without any encoding information attached
to it.
Things are moving into the direction of using UTF-8 for
filenames, though.
To solve this issue, various applications have come up with
ways around the problem, e.g. GTK uses the following strategy
to find the encoding (in the given order and adjustable using
an environment variable):
1. locale based encoding, if given (UTF-8 on most modern Unixes)
2. UTF-8
3. Latin-1
4. CP1252 (Windows Latin-1 version)
Perhaps we should add similar support to Python ?
We should probably use a file system encoding default
of Latin-1 on Unix if no other information can be found.
That way we will assure that things don't change on
Unix unless explicitly setup by the user (Latin-1 is
round-trip safe when converting it to Unicode and back).
os.listdir() would then continue to return plain strings
and file() will open them just it does now.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jul 15 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] 'With' context documentation draft (was Re: Terminology for PEP 343
M.-A. Lemburg wrote:
> This is exactly what I'm getting at: I can see the potential
> use for resource management (which is what started out the
> whole idea IIRC), but fail to see why you'd want to use it
> for anything more complicated than that.
The other suggested uses (redirecting stdout, logging exceptions, inserting
fences in markup, switching decimal context) aren't really more complicated.
They're just different cases of 'paired code' - code which consists of
'standard setup code', 'the unique bit', 'standard cleanup code'.
The longest example context manager in PEP 343 is only 11 lines long. Even the
wrapper to turn a generator into a context manager weighs in at only 23 lines.
> Once you start talking about contexts (which usually refers
> to a combination of environment, state and location) you
> have to explain things like nesting, scopes, combination
> of different contexts, their interaction with each other,
> etc. etc.
Except that context managers combine contexts in a very simple way - each one
is almost entirely independent of both its surroundings and its contents. Each
context manager takes a specific action to set the context up, and a specific
action to tear it down again afterwards. Its behaviour is dependent only on
the arguments that are passed to its constructor, and exceptions raised by its
contents.
The only way to make a context manager depend on its position in the code
(rather than the passed in arguments) is to use sys._getframe, and using that
is always considered an evil hack :)
> Note that hiding things away in smart objects like what
> you call "context managers" will not make programs easier
> to understand, unless the specific task that such a "context
> manager" is simple enough to grasp by just looking at its
> definition in the with statement... but then you'd not call
> it a "context manager".
Each one on its own may not be called a context manager, but we still need a
collective term that covers all of the simple (but different) cases of common
setup and cleanup code that we would like to factor out.
We tried 'resource managers' (which was too specific to one particular use
case), 'block managers' (a bit too close to the related-but-very-different
Ruby blocks) and 'suite managers' (which wasn't too bad, but not very
intuitive) along the way, but 'context managers' was the first one that really
seemed to adequately summarise the nature of the protocol - allowing a
programmer to factor out arbitrary setup and cleanup code that would otherwise
have to be reproduced inline everywhere they needed it.
> BTW, the same argument applies to decorators. Programs don't
> get easier to read or understand if you overload a function
> with lots and lots of hidden magic...
No argument here, but notice that the generic term 'decorator' tells you
nothing about what any *specific* decorator does. The obviousness needs to be
in the name of the decorator (such as 'classmethod'). The situation is the
same for context managers - to make the code easy to read, the method or
variable used to denote the context manager in the with statement must be well
named.
> @put_all_the_smart_stuff_here
> def program(context):
> return "42"
>
> Of course, you *could* do all these things and Python is
> not preventing you from doing so, but will life get easier ?
> I doubt it.
But what about:
for item in put_all_the_smart_stuff_here():
item.value = 42
The other guiding light in the terminology discussion was the existing concept
of iterables and iterators. Those can do just about anything you want, and
frequently hide a great deal of complexity. However, if they're well named,
then it is possible to read a for loop that uses them without batting an eyelid.
If the reader decides they need to know the details, they look up the
documentation of the iterator, just as they'd look up the details of a
decorator they didn't recognise. Once they've looked up the definition once,
instead of having to recognise a particular usage pattern in the code ("Oh,
that's doing 'X' again"), the reader simply has to recognise the name ("Oh,
that's the decorator/iterator/context manager that does 'X'")
> Let's keep things simple and Python nice.
Indeed - but I see being able to factor out common code as both simple *and*
nice, which is why I like the ideas of functions, iterators, decorators and
context managers :)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
M.-A. Lemburg wrote: > If you then start using terms in the documentation that cause > wrong associations, you make life harder for new programmers. I agree that every new construct and protocol makes life that much harder for anyone learning Python, but the bit I'm having trouble grasping is why you think associating 'with' statements with the term 'context' is *wrong*. The point of using that term in the documentation was to give people something to grab hold of that defines what the protocol is *for*, rather than dropping something completely abstract like "the 'with' protocol" on them. What does a 'with object' do? Nothing obvious, and this poses a major problem when trying to write the associated documentation. For instance, what's the justification for the use of __enter__ and __exit__ as the method names? OTOH, what does a 'context manager' do? It sets up and tears down a particular context as a section of code is entered and exited. Simple, succint, accurate, and provides a rationale for the method names used in the protocol. There's clearly something that bothers you about this though, and I'd like to understand what it is. Does the term 'context' carry additional, more specific, connotations for you that I'm simply not taking into account? Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
Nick Coghlan asked Marc-Andre Lemburg: > There's clearly something that bothers you about this though, and I'd like to > understand what it is. Does the term 'context' carry additional, more > specific, connotations for you that I'm simply not taking into account? To me, a context is much larger than a single object. That said, I can't think of any better words. It *might* be worth noting that context managers don't have to control the entire context -- they will often affect only one small facet, and it is OK to nest them if you want to control more than that. -jJ ___ 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] 'With' context documentation draft (was Re: Terminology for PEP 343
Michael Hudson wrote: > "M.-A. Lemburg" <[EMAIL PROTECTED]> writes: > > >>This is exactly what I'm getting at: I can see the potential >>use for resource management (which is what started out the >>whole idea IIRC), but fail to see why you'd want to use it >>for anything more complicated than that. > > > I, as a concrete example, want to be able to write: > > with output_to_file(f): > print stuff > function_that_prints_stuff() > > and have the printed things end up in the file-like object f (in a > single-threaded program, foom :) I would like it to be that easy also. However, it seems to me that using a context manager within try-except blocks will be a very common practice. try: with some_context() as var: except: else: The context manager will handle it's own cleanup, but we will still (in most cases) need to react to the raised exception somehow (and someplace) even if it's with a pass. It makes me think that the 'with' would be better expressed as a variation of a try statement. And the documentation for the 'with' statement would then be grouped and explained along with the try statements. Possibly: try with some_context() as VAR: except: # optional except-else? else: or just: trywith some_context() as VAR: # May cause an exception # that needs to be caught. I guess my point is: Since it's an encapsulated try-finally with a definite chance of generating an exception, Having a stronger association to 'try' in both the syntax and the documentation may be good. Cheers, Ron ___ 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] 'With' context documentation draft (was Re: Terminology for PEP 343
On 7/15/05, Ron Adam <[EMAIL PROTECTED]> wrote: [several new syntax proposals] Please stop proposing new syntax. The PEP was accepted after quite enough back-and-forth; there's no point opening this up yet again. -- --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] 'With' context documentation draft (was Re: Terminology for PEP 343
Guido van Rossum wrote: > On 7/15/05, Ron Adam <[EMAIL PROTECTED]> wrote: > [several new syntax proposals] > > Please stop proposing new syntax. The PEP was accepted after quite > enough back-and-forth; there's no point opening this up yet again. My apologies Guido. Subtracting the inappropriate syntax suggestions leaves the following hopefully on-topic documentation suggestions. It may be good to have a stronger association to "try" in the documentation by: 1. Suggesting to the programmer that in many situations a with can be thought of as 'try with'. 2. Reminding or clarify that a with will handle the object or context cleanup, but the programmer *may still* need to catch exceptions that are generated within the block with a "try-except" at some point. 3. The "with" documentation could possibly be grouped with or after the "try" documentation as it may be easier to understand in that context. Regards, Ron ___ 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] 'With' context documentation draft (was Re: Terminology for PEP 343
Ron Adam wrote: > 3. The "with" documentation could possibly be grouped with or after > the "try" documentation as it may be easier to understand in that context. I was looking for an appropriate place in the tutorial to put a couple of usage examples - a new subsection immediately after the introduction of try/finally (8.7, IIRC) seemed to make the most sense. However, I figured that bit could wait until I had a chance to play with an actual implementation. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 'With' context documentation draft (was Re: Terminology for PEP 343
> "Jim" == Jim Jewett <[EMAIL PROTECTED]> writes: Jim> Nick Coghlan asked Marc-Andre Lemburg: >> There's clearly something that bothers you about this though, >> and I'd like to understand what it is. Does the term 'context' >> carry additional, more specific, connotations for you that I'm >> simply not taking into account? Jim> To me, a context is much larger than a single object. To me, "*the* context" can be as small as exactly the subset of the environment that you need to manage to ensure correct behavior of the object(s) being managed. Eg, in quoting in email "preserving context" does not require quoting the whole message referenced in most cases. You only need to quote enough to ensure that the author's intention is conveyed to your readers. However, a "context manager" need not manage the whole context of the calling module, only those parts the encapsulated code might damage or misinterpret. Continuing with the email quoting example, if I then go on to quote a different part of the same email you did, I don't (in general) have to preserve the context that you did, only that of the part that I quote. I don't know that that should be convincing to those who have other associations for the word "context", but maybe it's a useful mnemonic and analogy for tutorial writers. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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
