Mailman 3 October 2005 - Python-Dev

Re: [Python-Dev] Proposed changes to PEP 343
by Nick Coghlan Oct. 12, 2005

Oct. 12, 2005

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 >>... >>Py> type(g) >><type 'function'> >>Py> type(g()) >><type 'generator'> >> >>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- > iterator." > > 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. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

1 0

Re: [Python-Dev] Proposed changes to PEP 343
by Jason Orendorff Oct. 12, 2005

Oct. 12, 2005

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 > PEP") 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 __exit__() methods. 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 context." -j

3 2

Fwd: defaultproperty
by Calvin Spealman Oct. 12, 2005

Oct. 12, 2005

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? > > Cheers, > Nick. 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?

6 5

Re: [Python-Dev] Python-Dev Digest, Vol 27, Issue 44
by john.m.camara＠comcast.net Oct. 11, 2005

Oct. 11, 2005

> 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 > Message-ID: > <1f7befae0510110651o504958det5d2409b3f724070e(a)mail.gmail.com> > 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[0] == "" 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.

1 0

PEP 3000 and exec
by Christos Georgiou Oct. 11, 2005

Oct. 11, 2005

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.

7 8

C.E.R. Thoughts
by jamesr Oct. 11, 2005

Oct. 11, 2005

Congragulations heartily given. I missed the ternary op in c... Way to go! clean and easy and now i can do: if ((sys.argv[1] =='debug') if len(sys.argv) > 1 else False): pass and check variables IF AND ONLY if they exist, in a single line! but y'all knew that..

6 5

PEP 3000 and exec
by Sokolov Yura Oct. 11, 2005

Oct. 11, 2005

Agree. >>>i=1 >>>def a(): i=2 def b(): print i return b >>>a()() 2 >>>def a(): i=2 def b(): exec "print i" return b >>>a()() 1

1 0

Re: [Python-Dev] Extending tuple unpacking
by Delaney, Timothy (Tim) Oct. 10, 2005

Oct. 10, 2005

Delaney, Timothy (Tim) wrote: > args = input.split() > > try: > cmd = arg.pop() ^^^ args ... > except IndexError: > cmd = '' Can't even get it right myself - does that prove a point? <wink> Tim Delaney

1 0

Extending tuple unpacking
by Gustavo Niemeyer Oct. 10, 2005

Oct. 10, 2005

Not sure if this has been proposed before, but one thing I occasionally miss regarding tuple unpack is being able to do: first, second, *rest = something Also in for loops: for first, second, *rest in iterator: pass This seems to match the current meaning for starred variables in other contexts. What do you think? -- Gustavo Niemeyer http://niemeyer.net

6 7

C API doc fix
by Robey Pointer Oct. 10, 2005

Oct. 10, 2005

Yesterday I ran into a bug in the C API docs. The top of this page: http://docs.python.org/api/unicodeObjects.html says: Py_UNICODE 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. robey

5 8