Jason Orendorff wrote:
> On 10/12/05, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
>>Strictly speaking this fits in with the existing confusion of "generator
>>factory" and "generator":
>>Py> def g():
>>... yield None
>>Most people would call "g" a generator, even though its really just a factory
>>function that returns generator objects.
> Not the same. A precise term exists for "g": it's a generator function.
> PEP 255 explicitly talks about this:
> "...Note that when
> the intent is clear from context, the unqualified name "generator" may
> be used to refer either to a generator-function or a generator-
> What would the corresponding paragraph be for PEP 343?
"...Note that when the intent is clear from context, the unqualified name
'context manager' may be used to refer either to a 'context manager
function' or to an actual 'context manager object'. This distinction is
primarily relevant for generator-based context managers, and is similar
to that between a normal generator-function and a generator-iterator."
Basically, a context manager object is an object with __enter__ and __exit__
methods, while the __with__ method itself is a context manager function.
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
On 10/7/05, Fredrik Lundh <fredrik(a)pythonware.com> wrote:
> the whole concept might be perfectly fine on the "this construct corre-
> sponds to this code" level, but if you immediately end up with things that
> are not what they seem, and names that don't mean what the say, either
> the design or the description of it needs work.
> ("yes, I know you can use this class to manage the context, but it's not
> really a context manager, because it's that method that's a manager, not
> the class itself. yes, all the information that belongs to the context are
> managed by the class, but that doesn't make... oh, shut up and read the
Good points... Maybe it is the description that needs work.
Here is a description of iterators, to illustrate the parallels:
An object that has an __iter__ method is iterable. It can plug
into the Python 'for' statement. obj.__iter__() returns an
iterator. An iterator is a single-use, forward-only view of a
sequence. 'for' calls __iter__() and uses the resulting
iterator's next() method.
(This is just as complicated as PEP343+changes, but not as
mindboggling, because the terminology is better. Also because
we're used to iterators.)
Now contexts, per PEP 343 with Nick's proposed changes:
An object that has a __with__ method is a context. It can plug
into the Python 'with' statement. obj.__with__() returns a
context manager. A context manager is a single-use object that
manages a single visit into a context. 'with' calls __with__()
and uses the resulting context manager's __enter__() and
A contextmanager is a function that returns a new context manager.
Okay, that last bit is weird. But note that PEP 343 has this oddness
even without the proposed changes. Perhaps either "context manager"
or contextmanager should be renamed, regardless of whether Nick's
changes are accepted.
With the changes, context managers will be (conceptually) single-use.
So maybe a different term might be appropriate. Perhaps "ticket".
"A ticket is a single-use object that manages a single visit into a
Sorry, Nick. GMail, for some reason, doesn't follow the reply-to
properly for python-dev. Forwarding to list now...
On 10/9/05, Nick Coghlan <ncoghlan(a)gmail.com> wrote:
> Jim Fulton wrote:
> > Based on the discussion, I think I'd go with defaultproperty.
> > Questions:
> > - Should this be in builtins, alongside property, or in
> > a library module? (Oleg suggested propertytools.)
> > - Do we need a short PEP?
> The much-discussed never-created decorators module, perhaps?
Never created for a reason? lumping things together for having the
similar usage semantics, but unrelated purposes, might be something to
avoid and maybe that's why it hasn't happened yet for decorators. If
ever there was a makethreadsafe decorator, it should go in the thread
module, etc. I mean, come on, its like making a module just to store a
bunch of unrelated types just to lump them together because they're
types. Who wants that?
> Date: Tue, 11 Oct 2005 09:51:06 -0400
> From: Tim Peters
> Subject: Re: [Python-Dev] PythonCore\CurrentVersion
> To: Martin v. L?wis
> Cc: python-dev(a)python.org
> Content-Type: text/plain; charset=ISO-8859-1
> [Tim Peters]
> >>> never before this year -- maybe sys.path _used_ to contain the current
> >>> directory on Linux?).
> [Fred L. Drake, Jr.]
> >> It's been a long time since this was the case on Unix of any variety; I
> >> *think* this changed to the current state back before 2.0.
> [Martin v. L?wis]
> > Please check again:
> > [GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import sys
> > >>> sys.path
> > ['', '/usr/lib/python23.zip', '/usr/lib/python2.3',
> > '/usr/lib/python2.3/plat-linux2', '/usr/lib/python2.3/lib-tk',
> > '/usr/lib/python2.3/lib-dynload',
> > '/usr/local/lib/python2.3/site-packages',
> > '/usr/lib/python2.3/site-packages',
> > '/usr/lib/python2.3/site-packages/Numeric',
> > '/usr/lib/python2.3/site-packages/gtk-2.0', '/usr/lib/site-python']
> > We still have the empty string in sys.path, and it still
> > denotes the current directory.
> Well, that's in interactive mode, and I see sys.path == "" on both
> Windows and Linux then. I don't see "" in sys.path on either box in
> batch mode, although I do see the absolutized path to the current
> directory in sys.path in batch mode on Windows but not on Linux -- but
> Mark Hammond says he doesn't see (any form of) the current directory
> in sys.path in batch mode on Windows.
> It's a bit confusing ;-)
Been bit by this in the past. On windows, it's a relative path in interactive mode and absolute path in non-interactive mode.
This might be minor-- but I didn't see anyone mentioning it so far. If
`exec` functionality is to be provided, then I think it still should be a
keyword for the parser to know; currently bytecode generation is affected if
`exec` is present. Even if that changes for Python 3k (we don't know yet),
the paragraph for exec should be annotated with a note about this issue.
Congragulations heartily given. I missed the ternary op in c... Way to
go! clean and easy and now i can do:
if ((sys.argv =='debug') if len(sys.argv) > 1 else False):
and check variables IF AND ONLY if they exist, in a single line!
but y'all knew that..
Delaney, Timothy (Tim) wrote:
> args = input.split()
> cmd = arg.pop()
^^^ args ...
> except IndexError:
> cmd = ''
Can't even get it right myself - does that prove a point? <wink>
Not sure if this has been proposed before, but one thing
I occasionally miss regarding tuple unpack is being able
first, second, *rest = something
Also in for loops:
for first, second, *rest in iterator:
This seems to match the current meaning for starred
variables in other contexts.
What do you think?
Yesterday I ran into a bug in the C API docs. The top of this page:
This type represents a 16-bit unsigned storage type which is
used by Python internally as basis for holding Unicode ordinals. On
platforms where wchar_t is available and also has 16-bits, Py_UNICODE
is a typedef alias for wchar_t to enhance native platform
compatibility. On all other platforms, Py_UNICODE is a typedef alias
for unsigned short.
This is incorrect on some platforms: on Debian, Py_UNICODE turns out
to be 32 bits.
I'm not sure what the correct quote should be: Does python use
wchar_t whenever it's available (16 bits or not)?
I solved my problem by realizing that I was going about things
entirely wrong, and that I should use the python codecs from C and
not worry about what Py_UNICODE contains. However, I think we should
fix the docs to avoid confusing others... or maybe it would be better
to document what's in Py_UNICODE and suggest always using the codec
methods? I don't have a strong opinion either way.