trying to come up with a more concise description of the rich
comparision machinery for pyref.infogami.com, I stumbled upon
an oddity that I cannot really explain:
in the attached example below, why is the rich comparision
machinery doing *four* attempts to use __eq__ in the old-
class case?
/F
PEP: 3101
Title: Advanced String Formatting
Version: $Revision$
Last-Modified: $Date$
Author: Talin talin at acm.org
Status: Draft
Type: Standards
Content-Type: text/plain
Created: 16-Apr-2006
Python-Version: 3.0
Post-History:
Abstract
This PEP proposes a new system for built-in string
Brett Cannon wrote:
ElementTree
---
- Web page
http://effbot.org/zone/element-index.htm
- Standard library name
xml.etree
- Contact person
Fredrik Lundh
- Synchronisation history
* 1.2.6 (2.5)
xml.etree contains components from both ElementTree and
and
Terry Reedy wrote:
Now, suppose you wanted to have 'key' be a keyword-only argument.
Why? Why not let the user type the additional argument(s) without the
parameter name?
Are you asking why that feature (keyword-only arguments) is desirable?
That's the whole point of the PEP. Or are
On 4/30/06, Steven Bethard [EMAIL PROTECTED] wrote:
On 4/29/06, Talin [EMAIL PROTECTED] wrote:This PEP proposes a change to the way that function arguments areassigned to named parameter slots.In particular, it enables the
declaration of keyword-only arguments: arguments that can onlybe supplied
Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/29/06, Josiah Carlson [EMAIL PROTECTED] wrote:
I understand the underlying implementation of str.join can be a bit
convoluted (with the auto-promotion to unicode and all), but I don't
suppose there is any chance to get str.join to support
Josiah Carlson wrote:
Specifically in the case of bytes.join(), the current common use-case of
literal.join(...) would become something similar to
bytes(literal).join(...), unless bytes objects got a syntax... Or
maybe I'm missing something?
I think what you are missing is that algorithms
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.
Georg
___
Python-Dev mailing list
Hi Fredrik,
On Sun, Apr 30, 2006 at 08:13:40AM +0200, Fredrik Lundh wrote:
trying to come up with a more concise description of the rich
comparision machinery for pyref.infogami.com,
That's quite optimistic. It's a known dark area.
I stumbled upon an oddity that I cannot really explain:
Armin Rigo wrote:
Hi Fredrik,
On Sun, Apr 30, 2006 at 08:13:40AM +0200, Fredrik Lundh wrote:
trying to come up with a more concise description of the rich
comparision machinery for pyref.infogami.com,
That's quite optimistic. It's a known dark area.
I stumbled upon an
Terry Reedy wrote:
Talin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Now, suppose you wanted to have 'key' be a keyword-only argument.
Why? Why not let the user type the additional argument(s) without the
parameter name?
Because for some functions (e.g. min()/max()) you
First of all, I recommend that you post this to comp.lang.python. This
is the kind of PEP where wide community involvement is essential to
success; be prepared for massive revision. (My point about massive
revision would be true regardless of how much consensus has been reached
on python-dev --
A few things from the pre-alpha2 context management terminology review have
had a chance to run around in the back of my head for a while now, and I'd
like to return to a topic Paul Moore brought up during that discussion.
Paul had a feeling there should be two generator decorators in
Collin Winters has done the work necessary to rename PEP 309's functional
module to functools and posted the details to SF [1].
I'd like to take that patch, tweak it so the C module is built as _functools
rather than functools, and then add a functools.py consisting of:
from _functools import
Does anyone know if PyThreadState_SetAsyncExc stops a thread while its
inside a native extension ?
I'm trying to stop a testing script that boils down to this:
while True:
print aaa
native_extension_call()
print bbb
Using PyThreadState_SetAsyncExc the module doesn't stop but if I
Hello,
Python language reference 3.3.6 deprecates __getslice__. I think it's
okay that UserList.py has it, but sre_parse shouldn't use it, no?
__getslice__ is not implemented in IronPython and this breaks usage of
_sre.py, a pure-Python implementation of _sre, on IronPython:
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 of the misfeature whereby
the iteration
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 of the misfeature
Nick Coghlan wrote:
Some details that are up for discussion:
- which of a function's special attributes should be copied/updated?
- should the __decorates__ and __decorator__ attributes be added?
If people are happy with this idea, I can make sure it happens before alpha
3.
What
On 4/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Specifically in the case of bytes.join(), the current common use-case of
literal.join(...) would become something similar to
bytes(literal).join(...), unless bytes objects got a syntax... Or
maybe I'm missing
Nick Coghlan wrote:
Collin Winters has done the work necessary to rename PEP 309's functional
module to functools and posted the details to SF [1].
I'd like to take that patch, tweak it so the C module is built as _functools
rather than functools, and then add a functools.py consisting of:
On 4/28/06, Sanghyeon Seo [EMAIL PROTECTED] wrote:
Hello,
Python language reference 3.3.6 deprecates __getslice__. I think it's
okay that UserList.py has it, but sre_parse shouldn't use it, no?
Well, as long as the deprecated code isn't removed, there's no reason
why other library code
On Fri, Apr 28, 2006, Gabriel Becedillas wrote:
Does anyone know if PyThreadState_SetAsyncExc stops a thread while its
inside a native extension ?
Please take this question to comp.lang.python; python-dev is for
discussion about changes to the Python interpreter/language, not for
questions
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:
On 4/30/06, Georg Brandl [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Collin Winters has done the work necessary to rename PEP 309's functional
module to functools and posted the details to SF [1].
I'd like to take that patch, tweak it so the C module is built as _functools
rather than
On 4/30/06, Nick Coghlan [EMAIL PROTECTED] wrote:
A few things from the pre-alpha2 context management terminology review have
had a chance to run around in the back of my head for a while now, and I'd
like to return to a topic Paul Moore brought up during that discussion.
I believe the context
Guido van Rossum wrote:
On 4/30/06, Georg Brandl [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Collin Winters has done the work necessary to rename PEP 309's functional
module to functools and posted the details to SF [1].
I'd like to take that patch, tweak it so the C module is built as
Guido van Rossum wrote:
I believe the context API design has gotten totally out of hand.
I have a counter-proposal: let's drop __context__.
Heh. I was about to pull out the if the implementation is hard to
explain, it's a bad idea (and bad ideas shouldn't go into 2.X) rule
last week in
Rudy Rudolph wrote:
2) pass-by-reference:
def f(wrappedParam):
wrappedParam[0] += 5 # ugh
return this is my result
# call it
x = 2
result = f([x])
# also ugly, but x is now 7
This example is broken; here's what you get when you run it:
def
Some thoughts from a lurker, largely concerning syntax; discount as
you wish.
First:
Keyword-only arguments are not required to have a default value.
Since Python requires that all arguments be bound to a value,
and since the only way to bind a value to a keyword-only argument
Zachary Pincus wrote:
Some thoughts from a lurker, largely concerning syntax; discount as
you wish.
First:
Keyword-only arguments are not required to have a default value.
Since Python requires that all arguments be bound to a value,
and since the only way to bind a value
I'm not sure about introducing a special syntax for accessing
dictionary entries, array elements and/or object attributes *within a
string formatter*... much less an overloaded one that differs from
how these elements are accessed in regular python.
Compound names are a sequence of
For most built-in types, the conversion specifiers will be the
same or similar to the existing conversion specifiers used with
the '%' operator. Thus, instead of '%02.2x, you will say
'{0:2.2x}'.
Don't you mean, {0:02.2x}?
Bill
Zachary Pincus wrote:
I'm not sure about introducing a special syntax for accessing
dictionary entries, array elements and/or object attributes *within a
string formatter*... much less an overloaded one that differs from
how these elements are accessed in regular python.
Yes, I also
Talin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Abstract
This PEP proposes a change to the way that function arguments are
assigned to named parameter slots. In particular, it enables the
declaration of keyword-only arguments: arguments that can only
be
Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Specifically in the case of bytes.join(), the current common use-case of
literal.join(...) would become something similar to
bytes(literal).join(...), unless bytes objects got a syntax... Or
maybe I'm missing something?
I
Josiah Carlson wrote:
I think what you are missing is that algorithms that currently operate
on byte strings should be reformulated to operate on character strings,
not reformulated to operate on bytes objects.
By character strings can I assume you mean unicode strings which
contain data,
Aahz wrote:
First of all, I recommend that you post this to comp.lang.python. This
is the kind of PEP where wide community involvement is essential to
success; be prepared for massive revision.
Actually, *all* PEPs should be posted to c.l.p at some point; the PEP
author is responsible for
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'
Jeff Epler wrote:
However, on this system, I couldn't recreate the problem you reported
with either the using _tkinter directly instructions, or using this
C test program:
#include tcl.h
#include tk.h
int main(void) {
Tcl_Interp *trp;
unsetenv(DISPLAY);
trp =
Hi all!
I've implemented recvmsg and sendmsg for the socket module in my private
Python tree for communication between two forked processes, which are
essentially wrappers for proper handling of SCM_RIGHTS and SCM_CREDENTIALS
Unix-Domain-Socket messages (which are the two types of messages
Thomas Wouters thomas at python.org writes:
Pfft, implementation is easy. I have the impression Talin wants to
implement it himself, but even if he doesn't, I'm sure I'll have a
free week somewhere in the next year and a half in which I can
implement it :) It's not that hard a problem, it just
Zachary Pincus zpincus at stanford.edu writes:
That seems a bit odd, as my natural expectation wouldn't be to see
kw1 ands kw2 as required, no-default keyword args, but as misplaced
positional args.
Perhaps this might be a little better?
def foo(*args, kw1=, kw2=):
I'm rather not
Zachary Pincus wrote:
I'm not sure about introducing a special syntax for accessing
dictionary entries, array elements and/or object attributes *within a
string formatter*... much less an overloaded one that differs from how
these elements are accessed in regular python.
On 4/30/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/30/06, Georg Brandl [EMAIL PROTECTED] wrote:
Nick Coghlan wrote:
Collin Winters has done the work necessary to rename PEP 309's functional
module to functools and posted the details to SF [1].
I'd like to take that patch,
On 4/30/06, Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/30/06, Nick Coghlan [EMAIL PROTECTED] wrote:
A few things from the pre-alpha2 context management terminology review have
had a chance to run around in the back of my head for a while now, and I'd
like to return to a topic Paul Moore
Talin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Compound names are a sequence of simple names seperated by
separated
The string and unicode classes will have a class method called
'cformat' that does all the actual work of formatting; The
format() method is
Martin v. Löwis [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
Now, suppose you wanted to have 'key' be a keyword-only argument.
Why? Why not let the user type the additional argument(s) without the
parameter name?
Are you asking why that feature
Nick Coghlan [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Terry Reedy wrote:
Talin [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Now, suppose you wanted to have 'key' be a keyword-only argument.
Why? Why not let the user type the additional argument(s)
Martin v. Löwis [EMAIL PROTECTED] wrote in message
Are you asking why that feature (keyword-only arguments) is desirable?
Joe Smith asked essentially the same question in a different way:
However, I'm not sure what the use case is for keyword only arguments on
functions that do *not* accept a
Guido van Rossum wrote:
On 4/30/06, Nick Coghlan [EMAIL PROTECTED] wrote:
A few things from the pre-alpha2 context management terminology review
have
had a chance to run around in the back of my head for a while now, and
I'd
like to return to a topic Paul Moore brought up during that
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, keyword-only args
after a fixed number number of positional args, implemented
[I'm cutting straight to the chase here]
On 4/30/06, Nick Coghlan [EMAIL PROTECTED] wrote:
The downside of this over the __context__ method is that it is neither nesting
nor thread-safe.
This argument is bogus.
We currently have two types of objects involved in with-statements:
those whose
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,
Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
I think what you are missing is that algorithms that currently operate
on byte strings should be reformulated to operate on character strings,
not reformulated to operate on bytes objects.
By character strings can I
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 such data into character strings: you need
an encoding
Terry Reedy wrote:
Are you asking why that feature (keyword-only arguments) is desirable?
That's the whole point of the PEP. Or are you asking why the user
shouldn't be allowed to pass keyword-only arguments by omitting the
keyword? Because they wouldn't be keyword-only arguments then,
Terry Reedy wrote:
Now, suppose you wanted to have 'key' be a keyword-only argument.
Why? Why not let the user type the additional argument(s) without the
parameter name?
Like Martin, you clipped most of the essential context of my question:
Talin's second proposal.
I clipped it
59 matches
Mail list logo
