At 01:19 PM 4/24/2006 -0700, Aahz wrote:
What is EXPRESSION, then? Not the value it returns, but EXPRESSION
itself -- does it have a name? What about the kinds of things we use
for EXPRESSION?
I read EXPRESSION returns a value as simply meaning that value =
EXPRESSION, i.e. that the result of
At 04:48 AM 4/25/2006 +1000, Nick Coghlan wrote:
Wanting to have two names for the same function tells me there's a problem
with the terminology, not that we should actually have two names for the same
function :)
It is purely an implementation detail of @contextmanager that it can be
used to
At 09:35 PM 4/24/2006 +0100, Paul Moore wrote:
The current, alpha 2, documentation insists that objects with
__enter__ and __exit__ methods must also define __context__ in such a
way that it returns self.
I don't understand why that is necessary.
I can understand that it is convenient, in cases
At 01:33 PM 4/23/2006 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
At 09:25 AM 4/22/2006 -0700, Aahz wrote:
EXPRESSION returns a value that the with statement uses to create a
context (a special kind of namespace). The context is used to
execute the BLOCK. The block might end
At 01:34 PM 4/22/2006 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
fit the new definition. So we settled on calling them context managers
instead.
...
method. Instead, the new term
At 01:34 PM 4/22/2006 +1000, Nick Coghlan wrote:
Then why didn't you speak up when the discussion was summarised in PEP 343
for
Guido's approval? I said it explicitly:
...
That may have been what you personally thought, but it's not what the PEP
said.
By the way, Greg Ewing coined the term
At 12:22 AM 4/22/2006 -0400, Terry Reedy wrote:
Why can't you remove the heuristic and screen-scrape info-search code
from the easy_install client and run one spider that would check
new/revised PyPI entries, search for missing info, insert it into PyPI when
found (and mark the entry eggified), or
At 12:34 PM 4/22/2006 +0200, Fredrik Lundh wrote:
Guido van Rossum wrote:
Leaving aside the Perl vs. Py thing, opinions on CPAN seem to be
diverse -- yes, I've heard people say that this is something that
Python sorely lacks; but I've also heard from more than one person
that CPAN sucks
At 09:05 AM 4/22/2006 -0700, Aahz wrote:
I've been following the with/context discussion, not that closely, but
reading all the posts. I also have to write docs on this for Python for
Dummies, which I think is going to be the first book out after 2.5. So
far, my take is that I want the block of
At 12:34 PM 4/22/2006 +0200, Fredrik Lundh wrote:
Ian Bicking wrote:
For instance, if you really want to be confident about how your libraries
are layed out, this script is the most reliable way:
http://peak.telecommunity.com/dist/virtual-python.py
note the use of this script is the most
At 09:25 AM 4/22/2006 -0700, Aahz wrote:
EXPRESSION returns a value that the with statement uses to create a
context (a special kind of namespace). The context is used to
execute the BLOCK. The block might end normally, get terminated by
a break or return, or raise an
At 05:41 PM 4/22/2006 +1000, Nick Coghlan wrote:
Phillip J. Eby wrote:
At 12:22 AM 4/22/2006 -0400, Terry Reedy wrote:
Why can't you remove the heuristic and screen-scrape info-search code
from the easy_install client and run one spider that would check
new/revised PyPI entries, search for missing
At 08:12 PM 4/22/2006 -0400, Terry Reedy wrote:
If my premises above are mistaken, then the suggestions should be modified
or discarded. However, I don't see how they conflict at all with a
consumer rating system.
My point was simply that providing rapid, visible feedback to authors
results in
At 01:19 PM 4/23/2006 +1000, Anthony Baxter wrote:
On Sunday 23 April 2006 11:43, Nick Coghlan wrote:
Maybe we need something that's the equivalent of alien (rpm - dpkg
converter), so that given an egg, one can easily get a native
installer for that egg.
An 'eggconvert' that used the
At 06:26 PM 4/21/2006 +0200, Thomas Wouters wrote:
On 4/21/06, guido.van.rossum
mailto:python-3000-checkins@python.orgpython-3000-checkins@python.org
wrote:
The hardest part was fixing two mutual recursive imports;
somehow changing import foo into from . import foo where
foo and bar import each
At 10:51 AM 4/21/2006 -0400, A.M. Kuchling wrote:
On Fri, Apr 21, 2006 at 07:31:35PM +1000, Nick Coghlan wrote:
fit the new definition. So we settled on calling them context managers
instead.
...
method. Instead, the new term manageable context (or simply context)
was introduced to mean
At 12:51 PM 4/21/2006 -0400, Jim Jewett wrote:
Phillip J. Eby wrote:
Such packages may have customized their installation process
by extending the distutils, *without* overriding get_outputs(). Since few
people actually use the --record option for anything important, nobody
notices when
I just noticed that the 2.5 What's New references PEP 243 in relation to
the distutils' upload command, but in fact the upload command implements
a different mechanism entirely. About the only thing the PEP and
implementation have in common is that they do a POST to python.org/pypi and
have a
At 06:43 PM 4/21/2006 +0200, Martin v. Löwis wrote:
They might need to be available outside Python. Two use cases:
1. The application embeds an sqlite database. Even though it
knows how to get at the data, it can't use it, because the
sqlite3 library won't accept
This is for the folks who wanted to get their feet wet with the setuptools
codebase...
Setuptools has 4 convenience commands that can be trivially ported to the
distutils, and 3 of those shouldn't require anything more than copying the
code, translating the docs from reST to LaTeX, and
At 10:59 PM 4/20/2006 +0200, Martin v. Löwis wrote:
Bob Ippolito wrote:
They DO NOT compete any more than source packages do. eggs are packages
plus metadata, nothing more. What eggs do and what rpm/msi/deb does are
orthogonal. It's entirely reasonable that in the future rpm/msi/deb
At 11:26 PM 4/20/2006 +0200, Martin v. Löwis wrote:
Greg Ewing wrote:
The resources name is actually quite a common meme;
I believe it goes back to the original Macintosh, which
was the first and only computer in the world to have files
with something called a resource fork. The resource
At 11:49 PM 4/20/2006 +0100, Paul Moore wrote:
It's possible that (1) can be solved by making *all* distutils
installs create egg metadata.
This is already planned to be addressed in Python 2.5, via the
install_egg_info added to the distutils. The implementation is already in
the trunk, but
At 11:53 PM 4/20/2006 +0200, M.-A. Lemburg wrote:
Only after endless discussions, Phillip added some weird
--long-option-name-that-no-one-can-remember to the setuptools
install command that restores the standard distutils behavior
which should be the default anyway.
And later, I also made it the
At 12:32 AM 4/21/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
What I'm opposed to in making setuptools install things the distutils way
by default is that there is no easy path to clean upgrade or installation
in the absence of a system packaging tool like RPM or deb or
what-have
At 07:33 PM 4/20/2006 -0400, Barry Warsaw wrote:
The only thing I'll add (other than put me in the just make it work and
tell me what to do camp ;) is that I really want a simple way to say
do not install into the system Python, put everything over here and I
will fiddle with my environment to
At 11:08 PM 4/20/2006 -0400, Barry Warsaw wrote:
Question out of total ignorance: say I get a 3rd party package that has
a standard distutils setup.py but knows nothing of setuptools. Say I
install my own copy of setuptools (or have Python 2.5). Can that 3rd
party package still be installed the
At 01:18 AM 4/21/2006 +0200, Baptiste Carvello wrote:
So instead, they ask the setuptool users to use
python -c import setuptools; execfile('setup.py') install
That's just too bad, and much more confusing than setup.py install_egg !
Actually, the setuptools users just run easy_install matplotlib,
At 01:33 AM 4/19/2006 -0400, Barry Warsaw wrote:
On Wed, 2006-04-19 at 14:57 +1000, Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile, either.
Agreed. If
At 08:11 AM 4/19/2006 +0200, Giovanni Bajo wrote:
Then, about new commands. Why should I need to do import distutils2 to do,
eg, setup.py develop? This doesn't break backward compatibility.
The develop command uses the egg_info command. egg_info uses the
setuptools enhanced MANIFEST scheme.
At 08:22 AM 4/19/2006 +0200, Walter Dörwald wrote:
Anthony Baxter wrote:
I'm not sure how people would prefer this be handled. I don't think we
need to have a PEP for it - I don't see PEPs for ctypes, elementtree,
pysqlite or cProfile, either.
If I'm not calling shared libraries from
At 08:38 AM 4/19/2006 +0200, Fredrik Lundh wrote:
I'm -1 on adding tools to the core that changes the structure of an installed
Python system, without a full PEP process. If nobody can point to (or
produce)
a technical document that, in full detail, describes the mechanisms *used* by
setuptools,
At 09:08 AM 4/19/2006 +0200, Fredrik Lundh wrote:
I've skimmed
the PEAK documentation, and all I find is bullet-point feature lists and
endless lists of configuration options. It's like reading Microsoft
documentation.
And I've read your email about the documentation, and all I find is
At 09:11 AM 4/19/2006 +0200, Walter Dörwald wrote:
With setuptools this doesn't work, because the package is distributed
over multiple egg-directories. AFAICR setuptools has a solution for this,
but only if the package __init__.py is empty (because setuptools
generates it). But I'd like to
At 11:10 PM 4/19/2006 +1000, Nick Coghlan wrote:
Ah, all is explained by svn blame, with a little help from svn log.
When Phillip went through to make the terminology consistent he actually
swapped the meanings of context (which meant 'has a __context__ method' in
the original PEP)
At least AMK
At 11:41 PM 4/19/2006 +1000, Nick Coghlan wrote:
Given that naming though, I think contextlib.contextmanager should be renamed
to contextlib.context.
The name is actually correct under this terminology
arrangement. @contextmanager *returns* a context manager. It happens to
also be a context,
At 07:46 PM 4/19/2006 +0200, Martin v. Löwis wrote:
Greg Ewing wrote:
I started refactoring some of the ugliness out of the internals of
distutils last year, but was completely stymied by the demand that no
existing setup.py scripts be broken.
Instead of trying to fix distutils, maybe it
At 08:33 PM 4/19/2006 +0200, Ronald Oussoren wrote:
Have you considered such a merger? It's rather odd to include a
package in
the stdlib that monkeypatches another part of the stdlib.
I assumed that it would be more controversial to merge setuptools into
distutils, than to provide it as an
At 08:45 PM 4/19/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be hot-fixing the standard
Python distribution ?
Because
At 04:15 PM 4/19/2006 -0400, A.M. Kuchling wrote:
At least some of these changes to Distutils seem unobjectionable for
inclusion.
For example, the changes to Command just allow keyword arguments on
two methods and adds a class attribute; they seem unlikely to break
any existing users of the
At 11:36 PM 4/19/2006 +0200, Fredrik Lundh wrote:
Phillip J. Eby wrote:
a technical document that, in full detail, describes the mechanisms
*used* by
setuptools, including what files it creates, what the files contain, how
they are used during import, how non-setuptools code can
At 10:39 AM 4/20/2006 +1000, Anthony Baxter wrote:
On Thursday 20 April 2006 03:46, Martin v. Löwis wrote:
It is *precisely* my concern that this happens. For whatever
reason, writing packaging-and-deployment software is totally
unsexy. This is why setuptools is a one-man show, and this is
At 10:08 PM 4/19/2006 -0500, Michael Urman wrote:
On 4/19/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
People blame setuptools when pydoc doesn't work on packages in zip
files. Rather than refer to some theoretical argument why it's not my
fault and I shouldn't be the one to fix it, I prefer
At 10:55 AM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip.eby wrote:
Author: phillip.eby
Date: Tue Apr 18 02:59:55 2006
New Revision: 45510
Modified:
python/trunk/Lib/pkgutil.py
python/trunk/Lib/pydoc.py
Log:
Second phase of refactoring for runpy, pkgutil, pydoc, and
At 10:04 AM 4/18/2006 -0400, A.M. Kuchling wrote:
PEP 343 says:
This PEP proposes that the protocol used by the with statement be
known as the context management protocol, and that objects that
implement that protocol be known as context managers. The term
context then
Now that setuptools is in the trunk, I need to also add its manuals and the
source for its .exe files. These currently live only in the sandbox.
First, the C source, used to create the 'gui.exe' and 'cli.exe' launchers
that setuptools uses to create script wrappers on Windows. The source
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be hot-fixing the standard
Python distribution ?
Because setuptools installs things in zip files, and older versions of
pydoc don't work for packages zip files.
If you want to provide a hot fix for Python 2.3
At 04:18 PM 4/18/2006 -0400, A.M. Kuchling wrote:
On Tue, Apr 18, 2006 at 08:55:18PM +0200, phillip.eby wrote:
Modified:
peps/trunk/pep-0343.txt
+context manager then encompasses all objects with a __context__()
+method that returns a context object. (This means that all
At 09:02 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
At 07:15 PM 4/18/2006 +0200, M.-A. Lemburg wrote:
Why should a 3rd party extension be hot-fixing the standard
Python distribution ?
Because setuptools installs things in zip files, and older versions of
pydoc don't
At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
who decided that setuptools should be added to 2.5, btw?
Guido proposed it on Python-dev when the 2.5 schedule was first being
discussed. I discussed it with him off-list, to ensure that it could be
done in a way that wouldn't interfere with
At 12:49 AM 4/19/2006 +0200, Martin v. Löwis wrote:
Fredrik Lundh wrote:
it's still listed under possible additions in the release PEP, and
there don't
seem to be a PEP or any other easily located document that explains exactly
how it works, what's required from library developers, how it
At 07:08 PM 4/18/2006 -0400, Fred L. Drake, Jr. wrote:
Saw that; hopefully I'll have a chance to look at it soon. I wonder,
generally, if it should be merged into the distutils documentation. Those
documents happen to be distutils-centric now, because that's what's been
provided. Their titles
At 02:12 AM 4/19/2006 +0200, Giovanni Bajo wrote:
But, why can't setuptools be gradually merged into distutils, instead of being
kept as a separate package? Let's take a real example: setuptools' sdist is
much enhanced, has integration with CVS/SVN, uses MANIFEST in a way that it
really works,
At 02:57 PM 4/19/2006 +1000, Anthony Baxter wrote:
Sure, it's possible that some people with extremely complicated
distutils scripts may find they need to update them.
...if and *only* if they want setuptools' features, or their users do.
Sorry to seize on this point out of context, Anthony. I
At 10:14 PM 4/18/2006 -0700, Neal Norwitz wrote:
On 4/18/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:55 PM 4/18/2006 +0200, Fredrik Lundh wrote:
who decided that setuptools should be added to 2.5, btw?
Guido proposed it on Python-dev when the 2.5 schedule was first being
discussed
I've been fiddling a bit with test_generators this morning, and have found
that a stripped down version of the fibonacci test only leaks if the
generator has a reference to a *copied* tee object. It doesn't matter
whether the copied tee object is the second result from tee(), or if you
just
At 12:53 PM 4/17/2006 -0400, Phillip J. Eby wrote:
By the way, the above cycle will leak even if the generator is never
iterated even once; it's quite simple to set up. I'm testing this using
-R:: on test_generators, and hacking on the _fib function and friends.
Follow-up note: it's possible
At 03:49 PM 4/14/2006 -0400, Tim Peters wrote:
That eventually
pointed to an off-by-one error in the new PyGen_NeedsFinalizing(),
where reading up trash made it very likely that old generators
containing an active loop would falsely claim they need finalization.
Alas, fix that, and Python
At 11:51 PM 4/14/2006 +0200, Thomas Wouters wrote:
On 4/14/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
At 03:49 PM 4/14/2006 -0400, Tim Peters wrote:
That eventually
pointed to an off-by-one error in the new PyGen_NeedsFinalizing(),
where reading up trash made
At 06:26 PM 4/14/2006 -0400, Phillip J. Eby wrote:
If you replace the fun_tests in test_generators with this, and remove all
the other tests (e.g. pep_tests, tut_tests, etc.) you can still get it to
crash. The code above is much shorter, but has the disadvantage that I
don't really know what it's
At 01:11 AM 4/15/2006 +0200, Thomas Wouters wrote:
On 4/15/06, Thomas Wouters mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
(I first thought the problem was caused by gen_dealloc doing
'Py_DECREF(gen-gen_frame)' instead of 'frame = gen-gen_frame;
gen-gen_frame = NULL; Py_DECREF(frame)', but
At 12:05 PM 4/13/2006 -0600, Steven Bethard wrote:
On 4/13/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Steven Bethard wrote:
I know 2.5's not out yet, but since I now have a PEP number, I'm going
to go ahead and post this for discussion. Currently, the target
version is Python 2.6.
At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
Sorry, I'm not clear on exactly what you're suggesting. Are you
suggesting I try to implement the make-statement using context
managers? Or that I use a context manager to address Martin's
problem?
Yes. :) Both. Or neither. What I'm
At 02:21 PM 4/13/2006 -0600, Steven Bethard wrote:
On 4/13/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 01:51 PM 4/13/2006 -0600, Steven Bethard wrote:
Sorry, I'm not clear on exactly what you're suggesting. Are you
suggesting I try to implement the make-statement using context
managers
Okay, so I've spent a bit more time thinking this through, and I think I
have a plan that can work, and deals with all the weird little corner
issues, including overlapping code with pkg_resources (a new module that's
to-be-added by setuptools).
My basic idea is as follows:
1. Move the
I'd like to create a branch for maintaining the setuptools 0.6 line through
its beta and final release, while new work proceeds on the trunk for
integration with Python 2.5 and beginning the 0.7 line. Is there any
special procedure I should follow, or can I just make a 'setuptools-0.6'
branch
At 08:39 PM 4/12/2006 +1000, Nick Coghlan wrote:
In this particular case, it would be a Python module imp.py that
included the line from _imp import * (where _imp is the current C-only
module with a different name).
I don't think that's going to work, since importing won't work until _imp
At 09:14 PM 4/12/2006 -0400, Tim Peters wrote:
The 2.4 backport of this patch should be reverted, since it changes
visible behavior (for example, all the 2.4 branch buildbot runs also
fail now).
Fine by me if we change the failing tests on the trunk to pass (noting
that should have been done
I just noticed that two stdlib modules (runpy and test.test_importhooks)
contain reimplementations of the base PEP 302 algorithm, or loaders
wrapping the standard (pre-302) import machinery.
Meanwhile, the 'imp' module exports an undocumented IMP_HOOK constant
(since Python 2.3), that is used
Here's my plan for implementing PEP 302 support (``__loader__``
sensitivity) for the above modules:
* Change all of the ``linecache`` API functions (except ``clearcache()``)
to add an optional ``module_globals`` argument, which they will use to
obtain the ``__name__`` and ``__loader__`` in the
I seem to recall some Python-dev discussion about this particular behavior,
but can't find it in Google. Is this test currently known to be
failing? If so, why, and what's the plan for it?
___
Python-Dev mailing list
Python-Dev@python.org
Is anybody else getting this?
Python 2.5a1 (trunk:45237, Apr 10 2006, 15:25:33)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type help, copyright, credits or license for more information.
import pdb
def x():
... if 'a' in 'b':
... pass
...
pdb.run(x())
At 09:47 PM 4/10/2006 +0200, Thomas Wouters wrote:
On 4/10/06, Phillip J. Eby
mailto:[EMAIL PROTECTED][EMAIL PROTECTED] wrote:
Is anybody else getting this?
stdin(2)x()
(Pdb) s
Segmentation fault
I'm not able to reproduce this in 32bit or 64bit mode (debian unstable.)
Does 'make distclean
At 02:47 PM 4/8/2006 -0700, Brett Cannon wrote:
Do people think we need to document the version that has
been imported into Python and when that was done as well?
Definitely. Better yet, in 2.5 I'd like to have the version information
embedded in a PKG-INFO file that gets installed with
At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
It would be good if we could have separate setup.py files for external
libraries, not only because of the ability to get PKG-INFO installed, but
also because then OS vendors that split those externals out into separate
At 09:35 AM 4/10/2006 +1000, Andrew Bennetts wrote:
On Sun, Apr 09, 2006 at 02:48:47PM -0400, Phillip J. Eby wrote:
At 07:56 PM 4/9/2006 +0200, Martin v. Löwis wrote:
[...]
-1. These aren't external libraries; they are part of Python.
They *were* external libraries. Also, many OS vendors
At 03:29 PM 4/5/2006, Delaney, Timothy (Tim) wrote:
Anthony Baxter wrote:
On behalf of the Python development team and the Python
community, I'm happy to announce the first alpha release
of Python 2.5.
I noticed in PEP 356 Open Issues StopIteration should propagate from
context managers
At 08:14 AM 3/31/2006, Tim Peters wrote:
[Phillip J. Eby]
...
As Tim suggested, it'd be better to have the code be generator-specific, at
least for now. That had actually been my original plan, to make it
generator-specific, but I was afraid of breaking encapsulation in the
garbage
At 04:47 AM 3/31/2006 -0800, Michael Chermside wrote:
In the discussion over class decorators, Jim Jewett writes:
I have often started with a function, and ended up replacing it with a
callable object so that I could save state without resorting to
defalt args or worse.
I would prefer to
At 12:14 PM 3/31/2006 -0500, Tim Peters wrote:
[Phillip J. Eby]
...
As Tim suggested, it'd be better to have the code be generator-specific, at
least for now. That had actually been my original plan, to make it
generator-specific, but I was afraid of breaking encapsulation
At 10:44 AM 3/29/2006 +0200, Gerhard Häring wrote:
Creating latex docs sounds like I could do it, too.
FYI, there's a reST-PythonDoc converter somebody wrote:
http://www.rexx.com/~dkuhlman/rstpythonlatex_intro.html
I'm planning to try it for porting the setuptools docs. I'm sure that
editing
At 11:36 AM 3/29/2006 -0800, Guido van Rossum wrote:
On 3/28/06, Anthony Baxter [EMAIL PROTECTED] wrote:
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no, but only because things like ElementTree didn't,
either. Does it need a BDFL pronouncement? I'd say
At 04:00 PM 3/29/2006 -0600, [EMAIL PROTECTED] wrote:
Is it not possible to distribute an empty db package which is then populated
with various database eggs (or other similar installation things)?
I don't think I understand your question.
If you are asking whether it's possible to have
At 10:42 AM 3/30/2006 +1200, Greg Ewing wrote:
Fred L. Drake, Jr. wrote:
class Foo:
Documentation is good.
@class implements(IFoo)
That's an interesting idea. It could be applied to
functions, too:
def myfunc(myargs):
Documentation is hoopy
@def
At 11:07 AM 3/29/2006 -0800, Guido van Rossum wrote:
On 3/28/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
If we're using Zope 3 as an example, I personally find that:
class Foo:
Docstring here, blah blah blah
implements(IFoo)
is easier to read than
At 08:00 PM 3/29/2006 -0500, Jack Diederich wrote:
A function decorator takes a function as an argument and returns something
(probably a function and maybe even the very same function).
So would class decorators.
This is exactly what class decorators should do or we should call them
something
At 03:09 PM 3/30/2006 +1200, Greg Ewing wrote:
Well, here's how my use case would look if I had
class decorators:
@IOClass
class MyClass:
...
Does that count? My decorator wouldn't need any
arguments, because it looks inside the class for
all the information it needs. [1]
That's
At 03:21 PM 3/30/2006 +1200, Greg Ewing wrote:
Fred L. Drake, Jr. wrote:
On Wednesday 29 March 2006 21:55, Greg Ewing wrote:
import db where db.stdlib == True and db.language == SQL \
and db.interface == DBAPI2.0
While we're at it, we could spell import select. :-)
Getting
At 11:09 PM 3/29/2006 -0500, Jack Diederich wrote:
I think we both want class decorators as a more fine grained substitute
for __metaclass__ (fine grained as in declared per-class-instance instead
of this-class-and-all-its-children). I can think of three ways class
decorators are used:
1)
At 10:01 AM 3/28/2006 -0800, Guido van Rossum wrote:
OK, I'm convinced (mostly by the awful hackery that Phillip so proudly
exposed :-).
Just as a historical note, here's where you previously rejected the same
hackery as an argument for supporting class decorators:
At 11:04 AM 3/28/2006 -0800, Guido van Rossum wrote:
That's fine. But there's also the C#/Java POV.
Can someone point me to examples of C# class attributes and Java
annotations that they'd like to use with this mechanism? I would indeed
like to see how those use cases compare with mine.
At 09:22 PM 3/28/2006 +0200, Georg Brandl wrote:
Hi,
since I found myself writing if __name__ == '__main__'
often these days, I wondered whether PEP 299 could be pronounced
upon. I'm not proposing putting it into 2.5, but it should be
relatively small a change.
A couple of issues that the PEP
At 04:22 PM 3/28/2006 -0500, Jean-Paul Calderone wrote:
On Tue, 28 Mar 2006 15:48:36 -0500, Barry Warsaw [EMAIL PROTECTED] wrote:
On Wed, 2006-03-29 at 01:51 +1100, Anthony Baxter wrote:
I'm happy to work with Gerhard to make this happen. Does it need a
PEP? I'd say no,
Agreed. pysqlite
At 06:13 PM 3/28/2006 -0500, Tim Peters wrote:
2. Because of the obscure gimmicks that try to cater to using old
binary extension modules across new Python releases without
recompiling, there's no guarantee that the tp_del slot even exists,
and therefore we don't try to access
At 02:55 PM 3/29/2006 +1200, Greg Ewing wrote:
Phillip J. Eby wrote:
http://mail.python.org/pipermail/python-dev/2004-March/043462.html
Or more precisely, the subsequent discussion and examples convinced me
that
putting class decorators on top of the class was bad for readability, vs
At 11:35 PM 3/28/2006 -0500, Fred L. Drake, Jr. wrote:
For Zope 3, we have decorators that work with the component architecture (I'm
sure Phillip is familiar with these). They're used with functions to
indicate that the function adapts a particular kind of object, or that it
implements or
Any thoughts on where documentation for the new contextlib module should
go in the library reference?
Some candidates:
* Program Frameworks (???)
* Development Tools (??)
* Python Runtime Services (?)
* Python Language Services (??)
* Miscellaneous Services (??)
A similar issue exists for
At 07:20 PM 3/27/2006 +, Mike Krell wrote:
Greg Ewing greg.ewing at canterbury.ac.nz writes:
I've just been playing around with metaclasses, and
I think I've stumbled across a reason for having
class decorators as an alternative to metaclasses
for some purposes.
There has also been
At 08:02 PM 3/27/2006 -0800, Guido van Rossum wrote:
Just curious (and lazy): what magic is the implementation using that
makes this work without a custom metaclass?
It registers a function as the __metaclass__ by poking it into the f_locals
of the frame that's defining the class. This function
I was just updating an experimental context library for the latest PEP 343
protocol, and I ran into a rather messy situation with the recently added
error-suppression feature, when used in combination with @contextmanager,
that caused some of my tests to fail.
Basically, the problem is this.
401 - 500 of 848 matches
Mail list logo
