> > [Guido, on {for,while}/else]
>
> How would a PEP to *remove* this feature fare today?
-1.
It took me a while (actually a *long* while) to start using else
clauses in loops, but I've learned to love them. Although there
aren't that many use cases, they make the code more readable (and
writabl
On 7/7/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> What is still unspecified (or at least not explicitely mentioned) in
> the PEP is the lifetime of VAR in:
>
> with EXPR as VAR:
> BLOCK
It is specified well enough IMO -- you're supposed to take the
translation into basi
Phillip J. Eby wrote:
> At 02:48 PM 7/7/2005 -0400, Tim Peters wrote:
>>I also suspect that if they weren't in the language already, a PEP to
>>introduce them would fail, because
>>
>>still_looking = True
>>some loop:
>>if found it:
>>still_looking = False
>>
Ron Adam <[EMAIL PROTECTED]> wrote:
> 1. With an if, if you think in terms of flow testing you get the same
> results as if you look at it in in terms of value testing. Either the
> if-block will execute or the else-block will, but never any part of
> one and then the other. A binary solution
Thus wrote Brett Cannon:
How about:
> #. Report the bug on SourceForge_
Make sure your bug hasn't been reported many times already.
> Create a new tracker item, filling out the ``Category`` and ``Group``
> fields. Do not set the ``Assigned To`` or ``Priority`` fields. Upload
>
Guido van Rossum wrote:
> On 7/7/05, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
>>What is still unspecified (or at least not explicitely mentioned) in
>>the PEP is the lifetime of VAR in:
>>
>> with EXPR as VAR:
>> BLOCK
>
> It is specified well enough IMO -- you're supposed
Walter Dörwald <[EMAIL PROTECTED]> writes:
> Am 07.07.2005 um 20:00 schrieb Guido van Rossum:
>
+1 on @contextmanager
>>
>> +1.
>>
>> [__enter__, __exit__]
>>
> These names should be changed to __beginwith__ and __endwith__.
>
>>
>> -1. The PEP has had an extensive review period and
Michael Hudson wrote:
> Walter Dörwald <[EMAIL PROTECTED]> writes:
> [...]
>>I.e. will VAR still exist after the end of the block with its value
>>the return value of __enter__() or will it revert to the previous
>>value (if any)?
>
> Eh, no. Where would you store the old value?
I don't know, w
Walter Dörwald <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> Walter Dörwald <[EMAIL PROTECTED]> writes:
>> [...]
>>>I.e. will VAR still exist after the end of the block with its value
>>>the return value of __enter__() or will it revert to the previous
>>>value (if any)?
>>
>> Eh, no.
Ron Adam <[EMAIL PROTECTED]> writes:
> Guido van Rossum wrote:
>
>> I even wonder if else-clauses on for/while were a good idea. (The one
>> on try is definitely a good idea since the use case is quite frequent
>> and only clumsily handled otherwise; the use cases for else on
>> for/while are less
Thomas Heller:
> OTOH, I once had a bug report from a py2exe user who complained that the
> program didn't start when installed in a path with japanese characters
> on it. I tried this out, the bug existed (and still exists), but I was
> astonished how many programs behaved the same: On a PC with
Brett> #. Gather important information
Brett> Info such as Python version, operating system version, etc.;
Brett> anything that might have influenced the code that lead to the
Brett> bug.
I'd change this to something more explicit:
# Gather important information
Phillip J. Eby wrote:
> I suggest changing this to something like this:
>
> class tag(object):
> def __init__(self,name):
> self.name = name
> def __enter__(self):
> print "<%s>" % name
> def __exit__(self):
> print "" % name
>
>
Neil Hodgson <[EMAIL PROTECTED]> writes:
> Thomas Heller:
>
>> OTOH, I once had a bug report from a py2exe user who complained that the
>> program didn't start when installed in a path with japanese characters
>> on it. I tried this out, the bug existed (and still exists), but I was
>> astonished
[Christoph, please keep the python-dev list in the loop here, at least
until they get annoyed and decide we're off-topic. I think this is
crucial to the way they package and deliver Python]
Christoph Ludwig <[EMAIL PROTECTED]> writes:
> On Thu, Jul 07, 2005 at 06:27:46PM -0400, David Abrahams w
[EMAIL PROTECTED] wrote:
>... if Py3k ever happens, I'd hope that it would be the *one* Python
> to use -- too many incompatibilities would probably mean *two*
> Pythons fighting each other).
A caduceus to heal software problems?
http://www.pantheon.org/articles/c/caduceus.html
--Scott Dav
On Friday 08 July 2005 04:54, Guido van Rossum wrote:
> How would a PEP to *remove* this feature fare today?
I'd very much prefer that we kept them. I find it a useful
way to group the behaviour of the looping - this bit is
the normal loop, and this bit at the end is when the loop
fails/is exhaust
Michael Hudson wrote:
> Ron Adam <[EMAIL PROTECTED]> writes:
>
>
>>Guido van Rossum wrote:
>>
>>
>>>I even wonder if else-clauses on for/while were a good idea. (The one
>>>on try is definitely a good idea since the use case is quite frequent
>>>and only clumsily handled otherwise; the use cases
"Walter Dörwald" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>x = blist()
>x(1)
>with blist(x) as x:
>x(2)
>with blist(x) as x:
> x(3)
>x(4)
>x(5)
>This would create the list:
>[1, [2, [3], 4], 5]
>With the current version of PEP 343, we would either have to us
Thomas Lotze wrote:
> Ron Adam <[EMAIL PROTECTED]> wrote:
>>3. In a while loop, it's a value test, where the else block gets
>>executed if the while condition evaluates as false, the while block
>>may or may not execute. You still need a flag to test for that.
>
>
> You're effectively arguing
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Phillip J. Eby wrote:
>> I suggest changing this to something like this:
>>
>> class tag(object):
>> def __init__(self,name):
>> self.name = name
>> def __enter__(self):
>> pri
Hi,
I compiled a list of some possible new context managers that could be
added to the stdlib. Introducing a new feature should IMO also show
usage of it in the distribution itself. That wasn't done with
decorators (a decorators module is compiled at the moment, if I'm right),
but with context man
On 7/8/05, Reinhold Birkenfeld <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I compiled a list of some possible new context managers that could be
> added to the stdlib. Introducing a new feature should IMO also show
> usage of it in the distribution itself. That wasn't done with
> decorators (a decorators
> In order to lower the barrier for reporting bugs, writing patches, and
> handling CVS commits, I am writing up checklists for each and I will
> put them up on python.org.
-0 on the checklists. I don't think existing "barriers" are high at
all. The entries may be variously regarded as codifying
At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>with sys.trace
Note that it's currently not possible to inspect the trace/profile hooks
from Python code, only from C, so that might be, um, interesting to implement.
>* pprint: with pprint.printer (used for print)
Interesting; I'm
On Jul 8, 2005, at 4:46 PM, Brett Cannon wrote:
> I think having basic context managers in a stdlib module that we know
> for a fact that will be handy is a good idea. We should keep the list
> short and poignant, but we should have something for people to work
> off of. The ones I like below for
On Fri, 2005-07-08 at 16:24, Reinhold Birkenfeld wrote:
> I compiled a list of some possible new context managers that could be
> added to the stdlib.
I agree with Brett and Phillip that a few well-chosen context managers
would make sense in the stdlib both for convenience and for example
purpose
Phillip J. Eby wrote:
> At 10:24 PM 7/8/2005 +0200, Reinhold Birkenfeld wrote:
>>with sys.trace
>
> Note that it's currently not possible to inspect the trace/profile hooks
> from Python code, only from C, so that might be, um, interesting to implement.
That was beyond my short view... i
> > I compiled a list of some possible new context managers that could
be
> > added to the stdlib. Introducing a new feature should IMO also show
> > usage of it in the distribution itself. That wasn't done with
> > decorators (a decorators module is compiled at the moment, if I'm
> right),
> > but
James Y Knight writes:
> It is a really bad idea to codify the practice of modifying non-
> threadlocal global state like sys.std[in|out|err] and current
> directory with a context manager.
Barry Warsaw responds:
> Thinking about the types of code I write over and over again, I think I
> disagree
Raymond Hettinger wrote:
>> > I compiled a list of some possible new context managers that could
> be
>> > added to the stdlib. Introducing a new feature should IMO also show
>> > usage of it in the distribution itself. That wasn't done with
>> > decorators (a decorators module is compiled at the m
Nick Coghlan wrote:
> OK, here's some draft documentation using Phillip's context
> terminology. I think it works very well.
>
> """
> With Statements and Context Management
>
> A frequent need in programming is to ensure a particular action is
> taken after a specific section of code has been e
David Abrahams wrote:
> Unless, of course, I'm missing something. So if I am missing
> something, what is it?
You are missing something, and I can only repeat myself. Some systems
require main() to be compiled as C++, or else constructors may not work
(and perhaps other things fail as well). The
David Abrahams wrote:
>>When I looked into this problem I saw that configure in fact builds a test
>>executable that included an object file compiled with g++. If the link step
>>with gcc succeeds then LINKCC is set as above, otherwise CXX is
>>used. Obviously, on my system this test was successful
Ummm... What's a "context manager"?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
David Abrahams wrote:
>>If there is some library with such objects that happens to get
>>wrapped and dynamically linked into a Python interpreter
>
>
> Whoa there. How would that ever happen under ordinary circumstances?
> Doesn't Python's makefile control what gets linked to Python?
Not entir
M.-A. Lemburg wrote:
> May I suggest that you use a different name than "context" for
> this ?!
>
> The term "context" is way to broad for the application scopes
> that you have in mind here (like e.g. managing a resource
> in a multi-threaded application).
It's actually the broadness of the term
Terry Reedy wrote:
> Would this also work as a decorated generator?
> (If I have understood correctly, something like..)
>
> @contextmanager
> def tag(name)
>print "<%s>" % name
>yield None
>print "" % name
>
> If so, I suggest putting in both versions to make the correspo
Michael Chermside wrote:
> I agree with Barry. Not only should they be in the stdlib, but they
> should have very clear warnings in their docstrings and other documentation
> that state that they are ONLY safe to use in single-threaded programs.
>
> This achieves two things: it makes them availabl
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>> Unless, of course, I'm missing something. So if I am missing
>> something, what is it?
>
> You are missing something, and I can only repeat myself. Some systems
> require main() to be compiled as C++, or else constructors ma
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>>>When I looked into this problem I saw that configure in fact builds a test
>>>executable that included an object file compiled with g++. If the link step
>>>with gcc succeeds then LINKCC is set as above, otherwise CXX is
>>>u
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams wrote:
>>>If there is some library with such objects that happens to get
>>>wrapped and dynamically linked into a Python interpreter
>>
>>
>> Whoa there. How would that ever happen under ordinary circumstances?
>> Doesn't Python's
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> In order to lower the barrier for reporting bugs, writing patches, and
>> handling CVS commits, I am writing up checklists for each and I will
>> put them up on python.org.
>
> -0 on the checklists.
I am more enth
Thomas Heller:
> But adding u'\u5b66\u6821\u30c7\u30fc' to sys.path won't allow to import
> this file as module. Internally Python\import.c converts everything to
> strings. I started to refactor import.c to work with PyStringObjects
> instead of char buffers as a first step - PyUnicodeObjects c
Guido van Rossum wrote:
> I sometimes think it was
> a mistake to introduce elif just to save typing "else if".
>
> The problem with the elwhile/elfor/eltry idea
> is that you're just as likely to need e.g.
> a "try" in the else clause of a while-loop as another while,
Here's an idea for Pytho
45 matches
Mail list logo
