At 03:49 PM 6/24/2006 -0700, Raymond Hettinger wrote:
Cases values must be ints, strings, or tuples of ints or strings.
-1. There is no reason to restrict the types in this fashion. Even if you
were trying to ensure marshallability, you could still include unicode and
longs. However, there
At 05:30 PM 6/24/2006 -0700, Raymond Hettinger wrote:
[Phillip Eby]
I would like to be able to use switches on types, enumerations, and the
like.
Be careful about wanting everything and getting nothing.
My proposal is the simplest thing that gets the job done for key use cases
found
in real
At 07:51 PM 6/23/2006 +0200, M.-A. Lemburg wrote:
Furthermore, the compiler could do other optimizations on the
const declared names, such as optimizing away global lookups
and turning them into code object constants lookups.
Technically, they'd have to become LOAD_DEREF on cells set up by the
At 01:08 PM 6/22/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote:
Maybe the real answer is to have a const declaration, not necessarily
the
way that Fredrik suggested, but a way to pre-declare constants e.g.:
const FOO = 27
And then require case expressions to be either
At 09:37 AM 6/22/2006 -0700, Guido van Rossum wrote:
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
This hypothetical const would be a *statement*,
executed like any other statement. It binds a name to a value -- and
produces an error if the value changes. The compiler doesn't need
necessary.
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:37 AM 6/22/2006 -0700, Guido van Rossum wrote:
On 6/22/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
This hypothetical const would be a *statement*,
executed like any other statement. It binds a name to a value
At 12:24 PM 6/22/2006 -0700, Guido van Rossum wrote:
OK, I think I see how this works. You pre-compute the expression at
def-time, squirrel it away in a hidden field on the function object,
and assign it to a local each time the statement is executed.
More precisely, I'd say that the computation
At 12:54 PM 6/22/2006 -0700, Guido van Rossum wrote:
Summarizing our disagreement, I think you feel that
freeze-on-first-use is most easily explained and understood while I
feel that freeze-at-def-time is more robust. I'm not sure how to get
past this point except by stating that you haven't
At 03:38 AM 6/21/2006 -0500, Ka-Ping Yee wrote:
On Wed, 21 Jun 2006, Phillip J. Eby wrote:
Well, EIBTI and all that:
switch x:
case == 1: foo(x)
case in S: bar(x)
It even lines up nicely. :)
Hmm, this is rather nice. I can imagine possible use cases
At 09:16 AM 6/21/2006 -0700, Guido van Rossum wrote:
After thinking about it a bit I think that if it's not immediately
contained in a function, it should be implemented as alternative
syntax for an if/elif chain.
That worries me a little. Suppose I write a one-off script like this:
for line in
At 06:41 PM 6/21/2006 +0200, Fredrik Lundh wrote:
Guido van Rossum wrote:
(Note how I've switched to the switch-for-efficiency camp, since it
seems better to have clear semantics and a clear reason for the syntax
to be different from if/elif chains.)
if you're now in the efficiency camp,
At 09:55 AM 6/21/2006 -0700, Guido van Rossum wrote:
BTW a switch in a class should be treated the same as a global switch.
But what about a switch in a class in a function?
Okay, now my head hurts. :)
A switch in a class doesn't need to be treated the same as a global switch,
because
At 10:27 AM 6/21/2006 -0700, Guido van Rossum wrote:
On 6/21/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:55 AM 6/21/2006 -0700, Guido van Rossum wrote:
BTW a switch in a class should be treated the same as a global switch.
But what about a switch in a class in a function?
Okay, now
At 12:26 PM 6/21/2006 +1200, Greg Ewing wrote:
Guido van Rossum wrote:
But it would be easy enough to define a dict-filling function that
updates only new values.
Or evaluate the case expressions in reverse order.
-1; stepping through the code in a debugger is going to be weird enough,
At 10:14 PM 6/20/2006 -0700, Guido van Rossum wrote:
Hm, so this still doesn't help if you write
case S: ...
(where S is an immutable set or sequence) when you meant
case in S: ...
so I'm not sure if it's worth the subtleties.
Well, EIBTI and all that:
switch x:
case ==
At 12:28 AM 6/19/2006 -0700, Josiah Carlson wrote:
Phillip J. Eby [EMAIL PROTECTED] wrote:
At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
The non-fast version couldn't actually work if it referenced any names,
given current Python semantics for arbitrary name binding replacements
At 12:10 AM 6/20/2006 +1000, Nick Coghlan wrote:
Caching on first use would be the easiest to explain I think. Something like:
if jump_dict is NULL:
jump_dict = {FIRST_CASE : JUMP_TARGET_1,
SECOND_CASE : JUMP_TARGET_2,
THIRD_CASE :
At 09:27 AM 6/19/2006 -0700, Raymond Hettinger wrote:
Guido van Rossum wrote:
Um, is this dogma? Wouldn't a switch statement also be a welcome
addition to the readability? I haven't had the time to follow this
thread (still catching up on my Google 50%) but I'm not sure I agree
with the idea that
At 11:23 AM 6/18/2006 -0700, Guido van Rossum wrote:
I'm not in favor of abusing this to generate a computed goto, and I
don't see a need for that -- if we decide to add that (either as
syntax or as an automatic optimization) I see no problem adding a new
bytecode.
Me either -- I suggest simply
At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote:
On 6/18/06, Nick Coghlan [EMAIL PROTECTED] wrote:
The 'bug fix' solution would be:
1. Change main.c and PySys_SetPath so that '' is NOT prepended to
sys.path
when the -m switch is used
2. Change runpy.run_module to add a
At 02:03 PM 6/18/2006 -0700, Guido van Rossum wrote:
On 6/18/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 11:18 AM 6/18/2006 -0700, Guido van Rossum wrote:
On 6/18/06, Nick Coghlan [EMAIL PROTECTED] wrote:
The 'bug fix' solution would be:
1. Change main.c and PySys_SetPath so
At 06:56 PM 6/18/2006 -0700, Josiah Carlson wrote:
The non-fast version couldn't actually work if it referenced any names,
given current Python semantics for arbitrary name binding replacements.
Actually, one could consider case expressions to be computed at function
definition time, the way
At 01:18 PM 6/17/2006 +0200, Armin Rigo wrote:
Psyco cheats here and emulates a behavior where there is
always exactly one object instead (which can be a tuple), so if a
END_FINALLY sees values not put there in the official way it will just
crash. PyPy works similarily but always expect three
At 01:29 AM 6/17/2006 +1000, Nick Coghlan wrote:
Kristján V. Jónsson wrote:
A cursory glance at import.c shows that the import mechanism is fairly
complicated, and riddled with char *path thingies, and manual string
arithmetic. Do you have any suggestions on a clean way to unicodify the
For folks contemplating what opcodes might need to be added to implement a
switch statement, it turns out that there is a clever way (i.e. a
filthy hack) to implement computed jumps in Python bytecode, using
WHY_CONTINUE and END_FINALLY.
I discovered this rather by accident, while working on
At 11:45 PM 6/15/2006 +0100, Nicko van Someren wrote:
On 15 Jun 2006, at 11:37, Nick Coghlan wrote:
...
The lack of a switch statement doesn't really bother me personally,
since I
tend to just write my state machine type code so that it works off a
dictionary that I define elsewhere,
At 11:26 AM 6/14/2006 -0700, Josiah Carlson wrote:
Ok, so here's a bit of a benchmark for you.
def helper(x,y):
return y
def fcn1(x):
_helper = helper
y = x+1
for i in xrange(x):
y = _helper(x,y)
def fcn2(x):
y = x+1
At 01:00 PM 6/14/2006 -0700, Josiah Carlson wrote:
That claim isn't necessarily supported by your benchmark, which includes
the time to *define* the nested function 10 times, but calls it only 45
times! Try comparing fcn1(1000) and fcn2(1000) - I suspect the results
will be somewhat
At 12:44 AM 6/12/2006 +0200, Fredrik Lundh wrote:
the compiler can of course figure that out also for if/elif/else state-
ments, by inspecting the AST. the only advantage for switch/case is
user syntax...
Not quite true - you'd have to restrict the switch expression in some way,
so you don't
As requested in PEP 360, please inform me of any issues you find so they
can be corrected in the standalone package and merged back to the trunk.
I just wasted time cutting an 0.1.1 release of the standalone wsgiref
package only to find that it doesn't correspond to any particular point in
the
At 07:24 PM 6/11/2006 -0500, Ka-Ping Yee wrote:
Thomas Heller wrote:
I don't know if this is the uuidgen you're talking about, but
on linux there is libuuid:
Thanks!
Okay, that's in there now. Have a look at http://zesty.ca/python/uuid.py .
Phillip J. Eby wrote:
By the way, I'd love
At 03:22 PM 6/10/2006 -0400, Tim Peters wrote:
This may be because compare_generic_iter() uses `assert` statements,
and those vanish under -O. If so, a test shouldn't normally use
`assert`. On rare occasions it's appropriate, like test_struct's:
if x 0:
expected
At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote:
IOW I think PEP 360 is an unfortunate historic accident, and we would
be better off without it. I propose that we don't add to it going
forward, and that we try to get rid of it as we can.
4 of the 6 modules in PEP 360 were added to Python in
At 09:43 AM 6/12/2006 -0700, Guido van Rossum wrote:
On 6/12/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:04 AM 6/12/2006 -0700, Guido van Rossum wrote:
IOW I think PEP 360 is an unfortunate historic accident, and we would
be better off without it. I propose that we don't add to it going
At 10:42 AM 6/12/2006 -0700, Guido van Rossum wrote:
Sure, but this doesn't require the draconian I-and-I-only own the
code approach that you have.
If there were only one version and directory tree to maintain to do both
the Python trunk and the external version, I wouldn't mind other people
At 03:29 PM 6/12/2006 -0400, Tim Peters wrote:
That's all ordinary everyday maintenance, and, e.g., there is no
mechanism to exempt anything in a checkout tree from reindent.py or
PyChecker complaints.
In addition, not shown above is that I changed test_wsgiref.py to stop
a test failure under -O.
[posting back to python-dev in case others also perceived my original
message as impolite]
At 01:25 PM 6/12/2006 -0700, Guido van Rossum wrote:
Oh, and the tone of your email was *not* polite. Messages starting
with I wasted an hour of my time are not polite pretty much by
definition.
Actually,
A01:01 PM 6/12/2006 -0700, Guido van Rossum wrote:
I think I pretty much did already -- going forward, I'd like to see
that contributing something to the stdlib means that from then on
maintenance is done using the same policies and guidelines as the rest
of the stdlib (which are pretty
At 03:42 PM 6/12/2006 -0400, Edward C. Jones wrote:
Guido van Rossum wrote:
developers contributing code without wanting
to give up control are the problem.
That hits the nail on the head.
Actually it's both irrelevant and insulting.
I just want changes made by the Python core developers
At 12:28 AM 6/13/2006 +0200, Martin v. Löwis wrote:
If you remember that this is the procedure: sure. However, if the
maintainer of a package thinks (and says) somebody edited my code,
this should not happen again, then I really think the code is better
not part of the Python distribution.
The
At 12:56 AM 6/13/2006 +0200, Martin v. Löwis wrote:
Fredrik Lundh wrote:
I just want changes made by the Python core developers to be reflected in
the external releases.
and presumably, the reason for that isn't that you care about your ego,
but that you care about your users.
For that,
At 12:09 AM 6/13/2006 +0100, Steve Holden wrote:
Phillip J. Eby wrote:
Anyway, will anyone who was offended by the original message please
pretend
that it was delightfully witty and written by Tim instead? Thanks. ;)
I wonder what the hell's up with Tim. He's been really crabby lately
At 01:36 AM 6/13/2006 +0200, Martin v. Löwis wrote:
From that, I can only conclude that you requested that people should
not make changes again without contacting you or the Web-SIG.
Indeed I was -- back when I was under the mistaken impression that PEP 360
actually meant what it appeared to
At 02:00 AM 6/13/2006 +0200, Giovanni Bajo wrote:
IMO, the better way is exactly this you depicted: move the official
development
tree into this Externals/ dir *within* Python's repository. Off that, you can
have your own branch for experimental work, from which extract your own
releases, and
At 01:49 AM 6/13/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
This should definitely be explained to authors who are donating
libraries to the stdlib, because from my perspective it seemed to me
that I was graciously volunteering to be responsible for *all* the work
related
At 11:16 AM 6/10/2006 -0500, Ka-Ping Yee wrote:
On Sat, 10 Jun 2006, Thomas Heller wrote:
[some nice ctypes code]
Done. Works like a charm. Thanks for providing the code!
On Sat, 10 Jun 2006, Phillip J. Eby wrote:
Also, for Python 2.5, these imports could probably be replaced
At 02:56 PM 6/7/2006 -0400, Joe Gregorio wrote:
Phillip,
1. It's not really clear from the abstract 'what' this library
provides. You might want
to consider moving the text from 1.1 up to the same level as the abstract.
Done.
2. In section 1.1 you might want to consider dropping the
The checked-in code substantially matches the public 0.1 release of
wsgiref. There are some minor changes to the docs and the test module, but
these have also been made in the SVN trunk of wsgiref's home repository, so
that future releases don't diverge too much. The plan is to continue to
At 08:38 AM 6/7/2006 -0400, A.M. Kuchling wrote:
On Tue, Jun 06, 2006 at 06:49:45PM -0400, Phillip J. Eby wrote:
Source: http://svn.eby-sarna.com/svnroot/wsgiref/docs
Minor correction: svn://svn.eby-sarna.com/svnroot/wsgiref/docs
(at least, http didn't work for me).
Oops... I meant:
http
At 10:13 AM 6/6/2006 -0400, Jim Jewett wrote:
On 6/5/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
I notice you've completely avoided the question of whether this should be
being done at all.
As far as I can tell, this PEP hasn't actually been discussed. Please
don't waste time changing modules
At 08:08 AM 6/5/2006 -0400, A.M. Kuchling wrote:
I had the start of an outline in sandbox/wsgiref-docs, but am not
working on them at the moment because no one is willing to say if the
list of documented classes is complete (or includes too much).
Huh? This is the first I've heard of it.
I was
At 09:27 PM 6/4/2006 -0400, Jim Jewett wrote:
Jackilyn is adding logging to several stdlib modules for the Google
Summer of Code (PEP 337), and asked me to review her first few
changes.
That PEP doesn't appear to have been approved, and I don't recall any
discussion on Python-Dev. I also
At 09:26 AM 6/1/2006 +, Michele Simionato wrote:
Terry Reedy tjreedy at udel.edu writes:
To me, another obvious way is isinstance(object, gentype) where
gentype = type(i for i in []) # for instance
which should also be in types module.
No, that check would match generator objects, not
At 09:53 PM 5/31/2006 +0200, Collin Winter wrote:
Hi Phillip,
Do you have any opinion on this patch (http://python.org/sf/1473257),
which is assigned to you?
I didn't know it was assigned to me. I guess SF doesn't send any
notifications, and neither did Georg, so your email is the very first
At 08:56 PM 5/30/2006 +0200, Alexander Bernauer wrote:
Hi
I found two bugs in example 4 of the PEP 318 [1]. People on #python
pointed me to this list. So here is my report. Additionally I appended
an afaics correct implementation for this task.
[1] http://www.python.org/dev/peps/pep-0318/
Bug
wrote:
This explains what to do, and which license to use:
http://www.python.org/psf/contrib/
--Guido
On 5/22/06, Ian Bicking [EMAIL PROTECTED] wrote:
Phillip J. Eby wrote:
At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote:
I'd like to include paste.lint with that as well (as wsgiref.lint
At 11:20 PM 5/4/2006 +0200, Fredrik Lundh wrote:
fwiw, I just tested
http://pyref.infogami.com/with
on a live audience, and most people seemed to grok the context
guard concept quite quickly.
note sure about the context entry value term, though. anyone
has a better idea ?
guarded value?
At 07:32 AM 5/1/2006 -0700, Guido van Rossum wrote:
On 4/30/06, Ben Wing [EMAIL PROTECTED] wrote:
[1] ideally, change this behavior, either for 2.6 or 3.0. maybe have a
`local' keyword if you really want a new scope.
[2] until this change, python should always print a warning in this
At 08:29 PM 5/1/2006 +1000, Nick Coghlan wrote:
'localcontext' would probably work as at least an interim name for such a
function.
with decimal.localcontext() as ctx:
# use the new context here
And the as ctx should be unnecessary for most use cases, if localcontext
has an
At 06:11 PM 5/1/2006 +0100, John Keyes wrote:
On 5/1/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Wouldn't this be an incompatible change? That would make it a no-no.
Providing a dummy argv[0] isn't so hard is it?
It would be incompatible with existing code, but that code is
already broken
At 11:37 AM 5/1/2006 -0700, Guido van Rossum wrote:
Agreed. Is it too late to also attempt to bring Doc/ref/*.tex
completely up to date and remove confusing language from it? Ideally
that's the authoritative Language Reference -- admittedly it's been
horribly out of date but needn't stay so
At 08:22 AM 4/30/2006 -0700, Guido van Rossum wrote:
Still, I expect that having a bunch of string-ish methods on bytes
arrays would be convenient for certain types of data handling. Of
course, only those methods that don't care about character types would
be added, but that's a long list:
At 09:53 AM 4/30/2006 -0700, Guido van Rossum wrote:
I have a counter-proposal: let's drop __context__. Nearly all use
cases have __context__ return self. In the remaining cases, would it
really be such a big deal to let the user make an explicit call to
some appropriately named method? The only
At 12:13 PM 4/30/2006 +0200, Georg Brandl wrote:
Recently, the inspect module was updated to conform with PEP 302.
Now this is broken:
import inspect
inspect.stack()
The traceback shows clearly what's going on. However, I don't know how
to resolve the problem.
The problem as that 'string'
At 08:08 PM 4/30/2006 -0700, Guido van Rossum wrote:
If you object against the extra typing, we'll first laugh at you
(proposals that *only* shave a few characters of a common idiom aren't
all that popular in these parts), and then suggest that you can spell
foo.some_method() as foo().
Okay,
At 07:38 AM 4/28/2006 -0700, Guido van Rossum wrote:
On 4/28/06, A.M. Kuchling [EMAIL PROTECTED] wrote:
- wsgiref to the standard library
(Owner: Phillip Eby)
I still hope this can go in; it will help web framework authors do the
right thing long term.
I doubt I'll have time to
At 11:54 AM 4/28/2006 -0400, A.M. Kuchling wrote:
On Fri, Apr 28, 2006 at 11:02:07AM -0400, Phillip J. Eby wrote:
I doubt I'll have time to write documentation for it before alpha 3. If
it's okay for the docs to wait for one of the beta releases -- or better
yet, if someone could volunteer
(Thank you, by the way, for actually reading some of the documentation
before writing this post, and for asking questions instead of jumping to
conclusions.)
At 06:43 PM 4/28/2006 +0200, M.-A. Lemburg wrote:
I've now found this section in the documentation which seems to
have the reason:
At 11:03 AM 4/28/2006 -0700, Guido van Rossum wrote:
(I'm asking Phillip to post the URL for the current
source; searching for it produces multiple repositories.)
Source browsing: http://svn.eby-sarna.com/wsgiref/
Anonymous SVN: svn://svn.eby-sarna.com/svnroot/wsgiref
At 02:32 PM 4/28/2006 -0500, Ian Bicking wrote:
Guido van Rossum wrote:
PEP 333 specifies WSGI, the Python Web Server Gateway Interface v1.0;
it's written by Phillip Eby who put a lot of effort in it to make it
acceptable to very diverse web frameworks. The PEP has been well
received by
At 01:19 PM 4/28/2006 -0700, Guido van Rossum wrote:
It still looks like an application of WSGI, not part of a reference
implementation. Multiple apps looks like an advanced topic to me; more
something that the infrastructure (Apache server or whatever) ought to
take care of.
I'm fine with a
At 04:04 PM 4/28/2006 -0500, Ian Bicking wrote:
I don't see why not to use prefix matching. It is more consistent with
the handling of the default application ('', instead of a method that
needs to be overridden), and more general, and the algorithm is only
barely more complex and not what I'd
At 05:47 PM 4/28/2006 -0500, Ian Bicking wrote:
It will still be only a couple lines less than prefix matching.
That's beside the point. Prefix matching is inherently a more complex
concept, and more likely to be confusing, without introducing much in the
way of new features. If I want to
At 04:34 PM 4/28/2006 -0700, Titus Brown wrote:
Hi, Phillip,
I'm getting this error when I run the tests, with both Python 2.3 and
2.4:
==
FAIL: testHeaderFormats (wsgiref.tests.test_handlers.HandlerTests)
At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:
Gustavo Carneiro [EMAIL PROTECTED] writes:
Now the problem. Suppose you have the source package python-foo-bar,
which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py. This
would make a module called foo.bar available.
At 06:47 PM 4/27/2006 +0200, M.-A. Lemburg wrote:
Just read that you are hijacking site.py for setuptools'
just works purposes.
hijacking isn't the word I'd use; wrapping is what it actually
does. The standard site.py is executed, there is just some pre- and
post-processing of sys.path.
At 11:38 AM 4/27/2006 -0700, Guido van Rossum wrote:
The change below was rolled back because it broke other stuff. But IMO
it is actually necessary to fix this,
Huh? The change you showed wasn't reverted AFAICT; it's still on the trunk.
otherwise those few exceptions
that don't derive from
At 09:54 PM 4/27/2006 +0200, M.-A. Lemburg wrote:
Note that I was talking about the .pth file being
writable, not the directory.
Please stop this vague, handwaving FUD. You have yet to explain how this
situation is supposed to arise. Is there some platform on which files with
a .pth extension
At 11:55 PM 4/25/2006 -0700, Neal Norwitz wrote:
S 243 Module Repository Upload Mechanism Reifschneider
This one needs to be withdrawn or updated - it totally doesn't match the
implementation in Python 2.5.
S 302 New Import Hooks JvR, Moore
At 10:16 AM 4/26/2006 -0700, Guido van Rossum wrote:
So I have a very simple proposal: keep the __init__.py requirement for
top-level pacakages, but drop it for subpackages.
Note that many tools exist which have grown to rely on the presence of
__init__ modules. Also, although your proposal
At 02:07 PM 4/26/2006 -0400, Phillip J. Eby wrote:
def find_module(self, fullname, path=None):
# Note: we ignore 'path' argument since it is only used via
meta_path
subname = fullname.split(.)[-1]
if os.path.isdir(os.path.join(self.path, subname
At 11:50 AM 4/26/2006 -0700, Guido van Rossum wrote:
I'm not sure what you mean by one directory read. You'd have to list
the entire directory, which may require reading more than one block if
the directory is large.
You have to do this to find an __init__.py too, don't you? Technically,
At 09:56 PM 4/26/2006 +0200, Martin v. Löwis wrote:
Phillip J. Eby wrote:
My counter-proposal: to be considered a package, a directory must contain
at least one module (which of course can be __init__). This allows the
is
it a package? question to be answered with only one directory read
At 04:33 PM 4/26/2006 -0400, Joe Smith wrote:
It seems to me that the right way to fix this is to simply make a small
change to the error message.
On a failed import, have the code check if there is a directory that would
have been the requested package if
it had contained an __init__ module. If
At 01:49 PM 4/26/2006 -0700, Guido van Rossum wrote:
OK, forget it. I'll face the pitchforks.
I'm disappointed though -- it sounds like we can never change anything
about Python any more because it will upset the oldtimers.
I know exactly how you feel. :)
But there's always Python 3.0, and if
At 01:10 AM 4/27/2006 +0200, Thomas Wouters wrote:
On 4/27/06, Guido van Rossum mailto:[EMAIL PROTECTED][EMAIL PROTECTED]
wrote:
I'd worry that it'll cause complaints when the warning is incorrect
and a certain directory is being skipped intentionally. E.g. the
string directory that someone had.
At 04:57 PM 4/26/2006 -0700, Guido van Rossum wrote:
On 4/26/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Possibly. Perhaps it would be useful to have `is_package(dirname)`,
`is_rootpackage(dirname)` and `is_subpackage(dirname)` functions
somewhere (pkgutils?).
YAGNI. Also note that
At 12:08 AM 4/26/2006 +1000, Nick Coghlan wrote:
Secondly, the documentation now shows an example
of a class with a close() method using contextlib.closing directly as its own
__context__() method.
Sadly, that would only work if closing() were a function. Classes don't
get turned into methods,
At 11:37 AM 4/25/2006 -0700, Guido van Rossum wrote:
But what's the use case? Have we actually got an example where it
makes sense to use the thing with __enter__ and __exit__ methods in
a with-statement, other than the (many) examples where the original
__context__ method returns self?
Objects
Please see
http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt for
source, or http://peak.telecommunity.com/DevCenter/EggFormats for an
HTML-formatted version.
Included are summary descriptions of the formats of all of the standard
metadata produced by setuptools, along
At 04:18 PM 4/25/2006 -0700, Guido van Rossum wrote:
But the question remains,
under what circumstances is it convenient to call __context__()
explicit, and pass the result to a with-statement?
Oh. I don't know of any; I previously asked the same question myself. I
just eventually answered
At 04:31 PM 4/25/2006 -0700, Aahz wrote:
Right -- I've already been chastised for that. Unless someone has a
better idea, I'm going to call it a wrapper.
Better idea: just delete the parenthetical about a namespace and leave the
rest of your text alone, at least until the dust settles. I
At 05:20 PM 4/25/2006 -0700, Guido van Rossum wrote:
I would augment #1 to clarify that if you have __enter__ and __exit__
you may not have __context__ at all; if you have all three,
__context__ must return self.
Well, requiring the __context__ allows us to ditch the otherwise complex
problem of
At 04:41 PM 4/25/2006 -0700, Brent Fulgham wrote:
Included are summary descriptions of the formats of all of the standard
metadata produced by setuptools, along with pointers to the existing
manuals that describe the syntax used for representing requirements, entry
points, etc. as text. The .egg,
At 08:09 PM 4/25/2006 -0700, Guido van Rossum wrote:
On 4/25/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 05:20 PM 4/25/2006 -0700, Guido van Rossum wrote:
I would augment #1 to clarify that if you have __enter__ and __exit__
you may not have __context__ at all; if you have all three
At 11:29 PM 4/25/2006 -0400, Phillip J. Eby wrote:
See, if @contextfactory functions return a thing *with* a __context__
method, how is that usable with with? It isn't, unless the thing also
happens to have __enter__/__exit__ methods. This was the hole in the
documentation that caused Nick
At 10:26 AM 4/24/2006 +0100, Paul Moore wrote:
OK. At this point, the discussion seems to have mutated from a
Phillip vs Nick debate to a Paul vs Nick debate.
I only stepped aside so that other people would chime in. I still don't
think the new terminology makes anything clearer, and would
At 04:48 AM 4/25/2006 +1000, Nick Coghlan wrote:
Using two names to describe three different things isn't intuitive for
anybody.
Um, what three things? I only count two:
1. Objects with __context__
2. Objects with __enter__ and __exit__
What's the third thing?
At 12:24 PM 4/24/2006 -0700, Aahz wrote:
On Mon, Apr 24, 2006, Phillip J. Eby wrote:
At 04:48 AM 4/25/2006 +1000, Nick Coghlan wrote:
Using two names to describe three different things isn't intuitive for
anybody.
Um, what three things? I only count two:
1. Objects with __context__
At 12:49 PM 4/24/2006 -0700, Aahz wrote:
On Mon, Apr 24, 2006, Phillip J. Eby wrote:
At 12:24 PM 4/24/2006 -0700, Aahz wrote:
On Mon, Apr 24, 2006, Phillip J. Eby wrote:
At 04:48 AM 4/25/2006 +1000, Nick Coghlan wrote:
Using two names to describe three different things isn't intuitive
301 - 400 of 848 matches
Mail list logo
