Thomas Wouters wrote:
It seems that, on my platform at least, Tk_Init() doesn't like being
called twice even when the first call resulted in an error. That's Tcl
and Tk 8.4.12. Tkapp_Init() (which is the Tkinter part that calls
Tk_Init()) does its best to guard against calling Tk_Init() twice
Results: 2.86% for 1 arg (len), 11.8% for 2 args (min), and 1.6% for pybench.
./python.exe -m timeit 'for x in xrange(1): len([])'
./python.exe -m timeit 'for x in xrange(1): min(1,2)'
One part of it is a little dangerous though.
http://python.org/sf/1479611
The general idea is to
Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
I mean unicode strings, period. I can't imagine what unicode strings
which do not contain data could be.
Binary data as opposed to text. Input to a array.fromstring(),
struct.unpack(), etc.
You can't/shouldn't put
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
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 yourself,
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 your
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
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 elimination
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
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__
and
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
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
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 just one context
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
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 context guard
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 modification
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 just
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
In
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):
pass
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 want
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
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 released,
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
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
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 number of
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 should
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, 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 mind
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 and
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.
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
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
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 keywords?
This
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, the
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 following
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 whoever wrote
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 second,
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
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
release.
I
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 the text that I
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
think
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 current
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
already
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
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 spelled
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 one.
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
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
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?
It would be
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 later
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
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
options
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,
Perhaps I do.
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
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 unaware
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
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
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.
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 the
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 late
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
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 a
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:
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
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
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 compressed
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__
[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 a
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 think it's
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 of all the
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
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
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 around)
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 'string
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
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
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 repr (rather
[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 everything
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
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
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/comparisons.html
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 , =, , =, , !=, ==:
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 data are.
Ok. I think
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 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
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,
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
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
Tim
[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 to
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 call
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
on a per-need
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 of right now the PEP
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 #1479181: split
94 matches
Mail list logo
