[Tim]
> ...
>> test_subprocess failing on all the Windows buildbots
[Neal]
> I tried to fix that breakage.
You succeeded! Thanks.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
On 5/1/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> > Author: neal.norwitz
> > Date: Tue May 2 06:43:14 2006
> > New Revision: 45850
> >
> > Modified:
> >python/trunk/Doc/lib/libfuncs.tex
> >python/trunk/Lib/test/test_subprocess.py
> >python/trunk/Misc/NEWS
> >python/trunk/Objects/f
Delaney, Timothy (Tim) wrote:
> So would this also be a SyntaxError?
>
> for x in stuff:
> x = somethingelse
That would be something to be debated. I don't
really mind much one way or the other.
--
Greg
___
Python-Dev mailing list
Python-D
> Author: neal.norwitz
> Date: Tue May 2 06:43:14 2006
> New Revision: 45850
>
> Modified:
>python/trunk/Doc/lib/libfuncs.tex
>python/trunk/Lib/test/test_subprocess.py
>python/trunk/Misc/NEWS
>python/trunk/Objects/fileobject.c
>python/trunk/Python/bltinmodule.c
> Log:
> SF #147
On Mon, May 01, 2006, Brett Cannon wrote:
> On 5/1/06, Aahz <[EMAIL PROTECTED]> wrote:
>>On Mon, May 01, 2006, Brett Cannon wrote:
>>>
>>> But there are two things that I can't quite decide upon.
>>>
>>> One is whether a signature object should be automatically created
>>> for every function. As o
On 5/1/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Mon, May 01, 2006, Brett Cannon wrote:
> >
> > But there are two things that I can't quite decide upon.
> >
> > One is whether a signature object should be automatically created
> > for every function. As of right now the PEP I am drafting has it
> >
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You weren't asking for a reason, you were asking for an example:
No wonder we weren't connecting very well. You somehow have it backwards.
'Why' means "for what reason". But to continue with examples:
my way to
[John J Lee]
> When opening patches on the SF tracker for bugs that affect Python 2.5,
> but may be candidates for backporting (to 2.4 ATM), should I leave "Group"
> as "None", or set it to "Python 2.5" to indicate it affects 2.5?
>
> If it's known to be a candidate for backporting, should I set it
Greg Ewing wrote:
>for x in stuff:
> for x in otherstuff:
>dosomethingelse(x)
>
> would be a SyntaxError because the inner loop
> is trying to use x while it's still in use by the
> outer loop.
So would this also be a SyntaxError?
for x in stuff:
x = somethingelse
When opening patches on the SF tracker for bugs that affect Python 2.5,
but may be candidates for backporting (to 2.4 ATM), should I leave "Group"
as "None", or set it to "Python 2.5" to indicate it affects 2.5?
If it's known to be a candidate for backporting, should I set it to
"Python 2.4" to
Guido van Rossum wrote:
> They're all the same priority.
yet another description that is obvious only if you already know what
it says, in other words:
Operators in the same box have the same precedence. /.../
Operators in the same box group left to right (except for com-
parisons, i
Martin v. Löwis wrote:
> Ok. I think I would use base64, of possibly compressed content. It's
> more compact than your representation, as it only uses 1.3 characters
> per byte, instead of the up-to-four bytes that the img2py uses.
only if you're shipping your code as PY files. in PYC format (Z
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> This discussion seems to have gotten a bit out of hand. I believe it
> belongs on the python-3000 list.
I accidentally jumped the gun on hitting 'send' on my most recent reply,
I'll repost it in the Py3k list and expect further discussion to proceed
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> >>> Certainly that is the case. But how would you propose embedded bytes
> >>> data be represented? (I talk more extensively about this particular
> >>> issue later).
> >> Can't answer: I don't know what "embedded bytes dat
They're all the same priority.
On 5/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> one last one for tonight; the operator precedence summary says that
> "in" and "not in" has lower precedence than "is" and "is not", which
> has lower precedence than "<, <=, >, >=, <>, !=, ==":
>
> http://doc
one last one for tonight; the operator precedence summary says that
"in" and "not in" has lower precedence than "is" and "is not", which
has lower precedence than "<, <=, >, >=, <>, !=, ==":
http://docs.python.org/ref/summary.html
but the comparisions chapter
http://docs.python.org/ref/c
On Monday 01 May 2006 16:57, Tim Peters wrote:
> +1. A real need for this is explained in ZODB's ZODB/util.py's
> WeakSet class, which contains a WeakValueDictionary:
...
> As that implementation suggests, though, I'm not sure there's real
> payback for the extra time taken in the patch's `val
Backticks certainly are deprecated -- Py3k won't have them (nor will
they become available for other syntax; they are undesirable
characters due to font issues and the tendency of word processing
tools to generate backticks in certain cases where you type forward
ticks).
So it would be a good idea
[Fred L. Drake, Jr.]
> I'd like to commit this for Python 2.5:
>
> http://www.python.org/sf/1479988
>
> The WeakKeyDictionary and WeakValueDictionary don't
> provide any API to get just the weakrefs out, instead
> of the usual mapping API. This can be desirable when
> you want to get a list of ever
Fredrik Lundh wrote:
> for some reason, the language reference uses the term "string con-
> version" for the backtick form of "repr":
>
> http://docs.python.org/ref/string-conversions.html
>
> any suggestions for a better term ? should backticks be deprecated,
> and documented in terms of re
This is a potentially long discussion so I'm putting it in a separate thread.
When finding one file relative to another, it's difficult to read
multiple ".parent" attributes stacked together. Worse, if you have
the wrong number, you end up at the wrong directory level, potentially
causing destruc
This discussion seems to have gotten a bit out of hand. I believe it
belongs on the python-3000 list.
As a quick commentary, I see good points made by both sides. My
personal view is that we should *definitely* not introduce a third
type, and that *most* text-based activities should be done in the
Fredrik Lundh wrote:
> for some reason, the language reference uses the term "string con-
> version" for the backtick form of "repr":
>
The language reference also says that trailing commas for expressions
work with backticks. This is incorrect. I think this is necessary to
allow nested 'strin
for some reason, the language reference uses the term "string con-
version" for the backtick form of "repr":
http://docs.python.org/ref/string-conversions.html
any suggestions for a better term ? should backticks be deprecated,
and documented in terms of repr (rather than the other way aroun
I just read over the changes to the proposed Path class since the
discussion last summer. A big thanks to Bjorn Lindqvist for writing a
PEP, Jason Orendorff for the original path.py and his suggestions on
how the Path class should be different, and the writers of the
Python-Dev Summary for bringin
I'd like to commit this for Python 2.5:
http://www.python.org/sf/1479988
The WeakKeyDictionary and WeakValueDictionary don't
provide any API to get just the weakrefs out, instead
of the usual mapping API. This can be desirable when
you want to get a list of everything without creating
new referen
Terry Reedy wrote:
> >> which reminds me of the following little absurdity gem from the language
> >> reference:
>
> > I am not sure of what you see as absurdity,
>
> Perhaps I do. Were you referring to what I wrote in the last paragraph of
> my response to Guido?
I don't know; I've lost track o
Tim Peters wrote:
> > (Or are the two goals -- completeness and readability --
> > incompossible, unable to be met at the same time by one document?)
>
> No, but it's not easy, and it's not necessarily succinct. For an
> existence proof, see Guy Steele's "Common Lisp the Language". I
> don't th
[A.M. Kuchling]
> ...
> (Or are the two goals -- completeness and readability --
> incompossible, unable to be met at the same time by one document?)
No, but it's not easy, and it's not necessarily succinct. For an
existence proof, see Guy Steele's "Common Lisp the Language". I
don't think it's
On Mon, May 01, 2006, Brett Cannon wrote:
>
> But there are two things that I can't quite decide upon.
>
> One is whether a signature object should be automatically created
> for every function. As of right now the PEP I am drafting has it
> on a per-need basis and have it assigned to __signature_
Josiah Carlson wrote:
>>> Certainly that is the case. But how would you propose embedded bytes
>>> data be represented? (I talk more extensively about this particular
>>> issue later).
>> Can't answer: I don't know what "embedded bytes data" are.
Ok. I think I would use base64, of possibly compre
Fredrik Lundh wrote:
> the language reference says:
>
> continue may only occur syntactically nested in a for or while loop,
> but not nested in a function or class definition or finally statement
> within that loop. /.../
>
> It may occur within an except or else clause. The rest
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 forever.
it's perfectly p
A.M. Kuchling wrote:
> I find this work very exciting. Time hasn't been kind to the
> reference guide -- as language features were added to 2.x, not
> everything has been applied to the RefGuide, and users will probably
> have been forced to read a mixture of the RefGuide and various PEPs.
or as
Guido van Rossum wrote:
> Strange. I thought this was supposed to be fixed? (But I can confirm
> that it isn't.)
Perhaps you were confusing it with this HISTORY entry?
- A 'continue' statement can now appear in a try block within the body
of a loop. It is still not possible to use continue in
Before I get into my reply, I'm going to start out by defining a new
term:
operationX - the operation of interpreting information differently than
how it is presented, generally by constructing a data structure based on
the input information.
eg; programming language source file -> parse tree
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 forever.
It's never too la
A.M. Kuchling wrote:
> On Sat, Apr 29, 2006 at 08:54:00PM +0200, Fredrik Lundh wrote:
>
>> http://pyref.infogami.com/
>>
>
> I find this work very exciting. Time hasn't been kind to the
> reference guide -- as language features were added to 2.x, not
> everything has been applied to th
Brett Cannon wrote:
> The second question is whether it is worth providing a function that
> will either figure out if a tuple and dict representing arguments
> would work in calling the function. Some have even suggested a
> function that returns the actual bindings if the call were to occur.
>
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 for
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 forever.
--Guido
On 5/1/06, A.M. Kuchling <[EMAIL PROTECT
On 5/1/06, John Keyes <[EMAIL PROTECTED]> wrote:
> > No. Late binding of sys.argv is very important. There are plenty of
> > uses where sys.argv is dynamically modified.
>
> Can you explain this some more? If it all happens in the same
> function call so how can it be late binding?
You seem to be
Strange. I thought this was supposed to be fixed? (But I can confirm
that it isn't.)
BTW there's another bug in the compiler: it doesn't diagnose this
inside "while 0".
--Guido
On 5/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> the language reference says:
>
> continue may only occur synt
the language reference says:
continue may only occur syntactically nested in a for or while loop,
but not nested in a function or class definition or finally statement
within that loop. /.../
It may occur within an except or else clause. The restriction on occurring
in the try
"Terry Reedy" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> "Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> which reminds me of the following little absurdity gem from the language
>> reference:
> I am not sure of what you see as absurdity,
Pe
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> A function/method could have one argument that is obviously needed and
> a whole slew of options that few people care about. For most people,
> the signature they know is foo(arg). It would be nice if all the
> opti
I've also opened a bug for supporting __getslice__ in IronPython.
Do you want to help develop Dynamic languages on CLR?
(http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTE
On Tue, May 02, 2006, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> the context expression in the with statement produces a context
>> manager with __enter__ and __exit__ methods which set up and tear
>> down a managed context for the body of the with statement. This is
>> very similar to your late
On 5/1/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 5/1/06, John Keyes <[EMAIL PROTECTED]> 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?
> >
>
On Sat, Apr 29, 2006 at 08:54:00PM +0200, Fredrik Lundh wrote:
> http://pyref.infogami.com/
I find this work very exciting. Time hasn't been kind to the
reference guide -- as language features were added to 2.x, not
everything has been applied to the RefGuide, and users will probably
have bee
Edward Loper wrote:
> >> And again, why would you *make* me, the user-programmer, type
> >>
> >> make_person(name=namex, age=agex, phone=phonex, location = locationx)
> >> #instead of
> >> make_person(namex,agex,phonex,locationx)
> >> ?
> >
> > because a good API designer needs to consider more th
Signature objects (which has been lightly discussed on python-3000,
but I realize should be retargeted to 2.6 since there is no
incompatibility problems) are the idea of having an object that
represents the parameters of a function for easy introspection. But
there are two things that I can't quit
Terry Reedy wrote:
> This is not a reason for subproposal two, but a special case, as you
> yourself note below, and hence does say why you want to have such.
>
>> def make_person(*, name, age, phone, location):
>>pass
You weren't asking for a reason, you were asking for an example:
this is
"Fredrik Lundh" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> which reminds me of the following little absurdity gem from the language
> reference:
>
>The following identifiers are used as keywords of the language, and
>cannot be used as ordinary identifiers. They must be
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
On 5/1/06, John Keyes <[EMAIL PROTECTED]> 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
> a
Fredrik Lundh wrote:
>> And again, why would you *make* me, the user-programmer, type
>>
>> make_person(name=namex, age=agex, phone=phonex, location = locationx)
>> #instead of
>> make_person(namex,agex,phonex,locationx)
>> ?
>
> because a good API designer needs to consider more than just the cur
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 (IMO) by passing a dummy argv[0]. I don't
thi
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
> I clipped it because I couldn't understand your question: "Why" what?
> (the second question only gives "Why not") I then assumed that the
> question must have applied to the text that immediately preceded the
> question - hence that's th
Terry Reedy wrote:
> And again, why would you *make* me, the user-programmer, type
>
> make_person(name=namex, age=agex, phone=phonex, location = locationx)
> #instead of
> make_person(namex,agex,phonex,locationx)
> ?
because a good API designer needs to consider more than just the current
releas
On Mon, May 01, 2006, Edward Loper wrote:
>
> But is it necessary to syntactically *enforce* that the arguments be
> used as keywords? I.e., why not just document that the arguments should
> be used as keyword arguments, and leave it at that. If users insist on
> using them positionally, then
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Terry Reedy wrote:
>> There are two subproposals: first, keyword-only args after a variable
>> number of positional args, which requires allowing keyword parameter
>> specifications after the *args parameter, and se
On 5/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> btw, talking about idioms used in the language reference, can any of the
> native speakers on this list explain if "A is a nicer way of spelling B" means
> that "A is preferred over B", "B is preferred over A", "A and B are the same
> word and w
Martin v. Löwis wrote:
> > I.e., why not just document that the arguments should
> > be used as keyword arguments, and leave it at that.
>
> Because they wouldn't be keyword-only arguments, then.
which reminds me of the following little absurdity gem from the language
reference:
The followin
On 5/1/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> While I agree that item #1 is a non-starter, it seems to me that in the
> case where the compiler statically knows a name is being bound in the
> module's globals, and there is a *non-argument* local variable being bound
> in a function body, t
Edward Loper wrote:
> Martin v. Löwis wrote:
>> One reason I see is to have keyword-only functions, i.e. with no
>> positional arguments at all:
>>
>> def make_person(*, name, age, phone, location):
>> pass
>
> But is it necessary to syntactically *enforce* that the arguments be
> used as keyw
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 app
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 thi
On Sun, Apr 30, 2006, Ben Wing wrote:
>
> recently i've been writing code that generates a python program from a
> source file containing intermixed python code and non-python constructs,
> which get converted into python.
Please take this to comp.lang.python (this is not in-and-of-itself
inappr
Please take this to the py3k list.
It's still open which methods to add; it'll depend on the needs we
discover while using bytes to write the I/O library.
I don't believe we should add everything we can; rather, I'd like to
keep the API small until we have a clear need for a particular method.
Fo
Is there a question or a request in here somewhere? If not, c.l.py.ann
would be more appropriate.
If you want that code integrated into core Python, read python.org/dev
and prepare a patch for SF!
--Guido
On 4/30/06, Heiko Wundram <[EMAIL PROTECTED]> wrote:
> Hi all!
>
> I've implemented recvmsg
On 4/30/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I expect that at some point people will want to tweak what gets copied
> > by _update_wrapper() -- e.g. some attributes may need to be
> > deep-copied, or personalized, or skipped, etc.
>
> What exactly do you have in
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?
On 4/30/06, John Keyes <[EMAIL PROTECTED]> wrote:
> Hi,
>
> main() in unittest has an optional parameter called argv. If it is not
> present in the invocation, it defaults to None.
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
> situation.
> [3] the current 'UnboundLocal' exception s
On 5/1/06, Edward Loper <[EMAIL PROTECTED]> wrote:
> > There are two subproposals: first, keyword-only args after a variable
> > number of positional args, which requires allowing keyword parameter
> > specifications after the *args parameter, and second, keyword-only args
> > after a fixed number
On 5/1/06, James Y Knight <[EMAIL PROTECTED]> wrote:
> Don't forget that the majority of users will never have heard any of
> these discussions nor have used 2.5a1 or 2.5a2. Choose the best term
> for them, not for the readers of python-dev.
I couldn't agree more! (Another thought, occasionally us
On May 1, 2006, at 8:15 AM, Nick Coghlan wrote:
> 1. PEP 343, 2.5 alpha 1, 2.5 alpha 2 and the discussions here have
> no doubt
> seriously confused the meaning of the term 'context manager' for a
> lot of
> people (you can certainly put me down as one such person). Anyone
> not already
> c
Fred L. Drake, Jr. wrote:
> On Sunday 30 April 2006 22:50, Edward Loper wrote:
> > I see two possible reasons:
>
> Another use case, observed in the wild:
>
>- An library function is written to take an arbitrary number of
> positional arguments using *args syntax. The library is releas
On Sunday 30 April 2006 22:50, Edward Loper wrote:
> I see two possible reasons:
Another use case, observed in the wild:
- An library function is written to take an arbitrary number of
positional arguments using *args syntax. The library is released,
presumably creating dependencie
On 4/30/06, Edward Loper <[EMAIL PROTECTED]> wrote
(referring to keyword-only arguments):
> I see two possible reasons:
>
>- A function's author believes that calls to the function will be
> easier to read if certain parameters are passed by name, rather
> than positionally; and they
Nick Coghlan wrote:
> I've called that the "context entry value" in a few places (I don't think any
> of them were in the actual documentation though).
that doesn't really give me the right associations (I want something
that makes it clear that this is an "emphemeral" object).
> A sample modifi
Edward Loper wrote:
> > One reason I see is to have keyword-only functions, i.e. with no
> > positional arguments at all:
> >
> > def make_person(*, name, age, phone, location):
> > pass
> >
> > which also works for methods:
> >
> > def make_person(self, *, name, age, phone, location):
> >
Martin v. Löwis wrote:
> One reason I see is to have keyword-only functions, i.e. with no
> positional arguments at all:
>
> def make_person(*, name, age, phone, location):
> pass
>
> which also works for methods:
>
> def make_person(self, *, name, age, phone, location):
> pass
>
On Sun, Apr 30, 2006 at 10:47:07PM -0500, Ben Wing wrote:
> foo = 1
>
> def set_foo():
> foo = 2
PyLint gives a warning here "local foo shadows global variable".
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
Programmers don't die, they ju
Fredrik Lundh wrote:
> a distinct term for "whatever the __enter__ method returns" (i.e.
> the thing assigned to the target list) would still be nice.
I've called that the "context entry value" in a few places (I don't think any
of them were in the actual documentation though).
A sample modifica
Greg Ewing wrote:
> Nick Coghlan wrote:
>> the context expression in the with statement produces a context
>> manager with __enter__ and __exit__ methods which set up and tear down
>> a managed context for the body of the with statement. This is very
>> similar to your later suggestion of contex
Thanks Martin!
Jeff
___
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
Nick Coghlan wrote:
> Greg Ewing wrote:
>> Also a thought on terminology. Even though it seems I
>> may have been the person who thought it up originally,
>> I'm not sure I like the term "manager". It seems rather
>> wooly, and it's not clear whether a "context manager"
>> is supposed to manage jus
Nick Coghlan wrote:
> the context expression in the with
> statement produces a context manager with __enter__ and __exit__ methods
> which set up and tear down a managed context for the body of the with
> statement. This is very similar to your later suggestion of context
> guard and guarded c
Greg Ewing wrote:
> Also a thought on terminology. Even though it seems I
> may have been the person who thought it up originally,
> I'm not sure I like the term "manager". It seems rather
> wooly, and it's not clear whether a "context manager"
> is supposed to manage just one context or multiple
>
Greg Ewing wrote:
> I've been thinking about the terms "guarded context"
> and "context guard". We could say that the with-statement
> executes its body in a guarded context (an abstract
> notion, not a concrete object). To do this, it creates
> a context guard (a concrete object) with __enter__
>
recently i've been writing code that generates a python program from a
source file containing intermixed python code and non-python constructs,
which get converted into python.
similar things have been done in many other languages -- consider, for
example, the way php is embedded into web pages
Nick Coghlan wrote:
> Ben Wing wrote:
>
>> apologies if this has been brought up on python-dev already.
>>
>> a suggestion i have, perhaps for python 3.0 since it may break some
>> code (but imo it could go into 2.6 or 2.7 because the likely breakage
>> would be very small, see below), is the
Guido van Rossum wrote:
> I believe the context API design has gotten totally out of hand.
My thoughts exactly!
> I have a counter-proposal: let's drop __context__... would it
> really be such a big deal to let the user make an explicit call to
> some appropriately named method?
Another possibi
Phillip J. Eby wrote:
> 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.
Terry Reedy wrote:
> "Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
>> Because for some functions (e.g. min()/max()) you want to use *args, but
>> support some additional keyword arguments to tweak a few aspects of the
>> operation (like providing a "key=x" option).
>
> This and the rest of
Nick Coghlan wrote:
> However, the scoping of for loop
> variables won't change, as the current behaviour is essential for search
> loops
> that use a break statement to terminate the loop when the item is found.
It occurs to me that there's a middle ground here:
leave the loop variable scope
Terry Reedy wrote:
> My "Why?" was and is exactly a request for that further discussion.
>
> Again: if a function has a fixed number n of params, why say that the first
> k can be passed by position, while the remaining n-k *must* be passed by
> name?
have you designed API:s for others than yours
Josiah Carlson wrote:
> Certainly that is the case. But how would you propose embedded bytes
> data be represented? (I talk more extensively about this particular
> issue later).
Can't answer: I don't know what "embedded bytes data" are.
> Um...struct.unpack() already works on unicode...
> >
Guido van Rossum wrote:
> Things should be as simple as possible but no simpler. It's pretty
> clear to me that dropping __context__ approaches this ideal. I'm sorry
> I didn't push back harder when __context__ was first proposed -- in
> retrospect, the first 5 months of PEP 343's life, before __c
1 - 100 of 102 matches
Mail list logo
