Hey, why not? They do basically the same thing, except instancemethod
allows only a single argument. Why not allow class and instance
methods to be wrapped with a partial instead of their own type? We can
rip out 300 lines of C code supporting instance method, at least. The
only thorn is the im_class attribute, but few seem to even use it (few
meaning just Twisted, according to Google Code Search). Anyway, I
figure we don't really need it anyway because if some of the proposals
for a way to reliably get the current function, class, or module go
through, perhaps we'll have a reference to the class from the function
itself. What does anyone think?
Read my blog! I depend on your acceptance of my opinion! I am interesting!
I often wish you could bind to arguments in a partial out of order,
skipping some positionals. The solution I came up with is a singleton
object located as an attribute of the partial function itself and used
def foo(a, b):
return a / b
pf = partial(foo, partial.skip, 2)
assert pf(1.0) == 0.5
Read my blog! I depend on your acceptance of my opinion! I am interesting!
(Not exactly an idea post, but I don't want to bother python-dev or
python-3000 with this.)
PEP 246 was rejected a year or so ago, and Guido's rejection note
stated "Something much better is about to happen; it's too early to
say exactly what, but it's not going to resemble the proposal in this
PEP." Does anyone know if anything has gone on with this concept
since then? It seems like it has a lot of really interesting
potential, although I do see why PEP 246's specific proposal was
rejected. It's just the "Something much better is about to happen"
that got me curious -- is it happening yet? :)
(Please note that several groups were Cc'd. For now, please limit
followups to python-3000. This would *probably* be backported to 2.6,
but that wouldn't be decided until the implementation strategy was
Title: Access to Module/Class/Function Currently Being Defined (this)
Author: Jim J. Jewett <jimjjewett(a)gmail.com>
Type: Standards Track
It is common to need a reference to the current module, class,
or function, but there is currently no entirely correct way to
do this. This PEP proposes adding the keywords __module__,
__class__, and __function__.
Many modules export various functions, classes, and other objects,
but will perform additional activities (such as running unit tests)
when run as a script. The current idiom is to test whether the
module's name has been set to magic value.
if __name__ == "__main__": ...
More complicated introspection requires a module to (attempt to)
import itself. If importing the expected name actually produces
a different module, there is no good workaround.
Proposal: Add a __module__ keyword which refers to the module
currently being defined (executed). (But see open issues.)
if __module__ is sys.main: ... # assuming PEP 3020, Cannon
Class methods are passed the current instance; from this they can
determine self.__class__ (or cls, for classmethods). Unfortunately,
this reference is to the object's actual class, which may be a
subclass of the defining class. The current workaround is to repeat
the name of the class, and assume that the name will not be rebound.
super(C, self).meth() # Hope C is never rebound.
super(C, self).meth() # ?!? issubclass(D,C), so it "works"
Proposal: Add a __class__ keyword which refers to the class currently
being defined (executed). (But see open issues.)
Note that super calls may be further simplified by PEP 30XX, Jewett.
The __class__ (or __this_class__) attribute came up in attempts to
simplify the explanation and/or implementation of that PEP, but was
separated out as an independent decision.
Note that __class__ (or __this_class__) is not quite the same as the
__thisclass__ property on bound super objects. The existing
super.__thisclass__ property refers to the class from which the Method
Resolution Order search begins. In the above class D, it would refer to
(the current reference of name) C.
Functions (including methods) often want access to themselves,
usually for a private storage location. While there are several
workarounds, all have their drawbacks.
def counter(_total=): # _total shouldn't really appear in the
_total += 1 # signature at all; the list wrapping and
return _total #  unwrapping obscure the code
counter.total += 1 # Assume name counter is never rebound
class _wrap(object): # class exists only to provide storage
self.__total += 1
accum=_wrap().f # set module attribute to a bound method
Proposal: Add a __function__ keyword which refers to the function
(or method) currently being defined (executed). (But see open issues.)
__function__.total += 1 # Always refers to this function obj
While a user could be using these names already, __anything__ names
are explicitly reserved to the interpreter. It is therefore acceptable
to introduce special meaning to these names within a single feature
Ideally, these names would be keywords treated specially by the bytecode
Guido has suggested  using a cell variable filled in by the metaclass.
Michele Simionato has provided a prototype using bytecode hacks .
- Are __module__, __class__, and __function__ the right names?
In particular, should the names include the word "this", either as
__this_module__, __this_class__, and __this_function__, (format
discussed on the python-3000 and python-ideas lists) or as
__thismodule__, __thisclass__, and __thisfunction__ (inspired by,
but conflicting with, current usage of super.__thisclass__).
- Are all three keywords needed, or should this enhancement be limited
to a subset of the objects? Should methods be treated separately from
 Fixing super anyone? Guido van Rossum
 Descriptor/Decorator challenge, Michele Simionato
This document has been placed in the public domain.
Steven Elliott wrote:
> What I have in mind may be close to what you are suggesting above.
My idea is somewhat more uniform and general than that.
For the module dict, you use a special mapping type that
allows selected items to be accessed by an index as well
as a name. The set of such names is determined when the
module's code is compiled -- it's simply the names used
in that module to refer to globals or builtins.
The first time a given builtin is referenced in the module,
it will be unbound in the module dict, so it is looked up
in the usual way and then written into the module dict,
so it can subsequently be retrieved by index.
The advantages of this scheme over yours are that it speeds
access to module-level names as well as builtins, and it
doesn't require the compiler to have knowledge of a
predefined set of names.
It does entail a slight semantic change, as changes made
to a builtin won't be seen by a module that has already
used that builtin for the first time. But from what Guido
has said before, it seems he is willing to accept a change
like that if it will help.
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | Carpe post meridiem! |
Christchurch, New Zealand | (I'm not a morning person.) |
On 4/16/07, Jim Jewett <jimjjewett(a)gmail.com> wrote:
> On 4/13/07, Greg Ewing <greg.ewing(a)canterbury.ac.nz> wrote:
> > Josiah Carlson wrote:
> > >>Does anyone have a use case where they *need*
> > >>the indentation to be preserved?
> > > Not personally. I think that telling people to
> > > use textwrap.dedent() is sufficient.
> > But it seems crazy to make people do this all
> > the time, when there's no reason not to do
> > it automatically in the first place.
> The textwrap methods (including a proposed dedent) might make useful
> string methods. Short of that
> (1) Where does this preservation actually hurt?
> def f(self, arg1):
> """My DocString ...
> And I continue here -- which really is what I want.
> I use docstrings online -- and I typically do want them indented like the
> (2) Should literals (or at least strings, or at least docstrings) be
> decoratable? Anywhere but a docstring, you could just call the
> function, but ... I suppose it serves the same meta-value is the
> proposed i(nternational) or t(emplate) strings.
> def f(...):
> """ ...
If docstrings is the problem you can always use a function decorator for it:
func.__doc__ = dedent(func.__doc__)
Long and indented docstring.
> Python-ideas mailing list
I heard the call for the P3K PEP April deadline, so I thought I better get
this sent off!
When I was first exposed to Python, I was delighted that I could do the
>>> "Hello" ' world'
This turned to confusion when I tried;
>>> domain = " world"
>>> "hello" domain
Syntax Error ... Invalid Syntax
My proposal for Python3K is to allow string-concatenation via juxtaposition
between string-literals, string-variables and expressions that evaluate to
Juxtaposition has some precedence in Python (the example above) and also in
the awk programming language.
If anyone agrees that this is a good idea, then I'd be happy to write up a
PEP explaining why I think that implicit string concatenation is better than
overloading the plus operator (which this proposal wouldn't deprecate) and
more elegant than template strings or string interpolation.
Sometimes I think it would be great if it were possible to have standard
Python command line options that would allow
- initialize and configure the logging module
- specify requirements for pkg_resources (for eggs installed with --multi-version
All this would avoid having to change logging options or requirements in the
script, or having to implement a command line parser for this stuff in every script.
The idea is to call python in this way:
python --require foo==dev --logging level=DEBUG myscript.py
I have not been able to implement something like this in sitecustomize.py,
because this module is executed when sys.argv is not yet available.
Another possible way to implement this would probably be to set environment vars
and parse those in sitecustomize.py, you would have to call
env option1=foo option2=bar python script.py
then; unfortuately windows does not have an 'env' utility.
Does this sound like a useful idea?
I proposed an (admittedly more controversial) version of this a few
months back at the py3k list and the reaction was unexpectedly (IMO)
negative or indifferent, so I'm wondering if things have changed a bit
The proposal is to make the the builtin iter() return an object with
an API that consists of (most) functions currently at itertools. In
addition to saving one "from itertools import chain,islice,..." line
in every other module I write these days, an extra bonus of the OO
interface is that islice can be replaced with slice syntax and chain
with '+' (and/or perhaps the "pipe" character '|'). As a (deliberately
involved) example, consider this:
# A composite iterator over two files specified as follows:
# - each yielded line is right stripped.
# - the first 3 lines of the first file are yielded.
# - the first line of the second file is skipped and its next 4 lines
# - empty lines (after the right stripping) are filtered out.
# - the remaining lines are enumerated.
f1,f2 = [iter(open(f)).map(str.rstrip) for f in 'foo.txt','bar.txt']
for i,line in (f1[:3] + f2[1:5]).filter(None).enumerate():
The equivalent itertools version is left as an exercise to the reader.
This is actually backwards compatible and could even go in 2.x if
accepted, but I'm focusing on py3K here.
PS: FYI, a proof of concept implementation is posted as a recipe at:
Has anyone seen this article?
Are its criticisms of Python's regex algorithm accurate? If so, might
it be possible to revise Python's `re` module to use this sort of
algorithm? I noticed it says that this approach doesn't work if the
pattern contains backreferences, but maybe the module could at least
sort of self-optimize by switching to this method when no backrefs