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() twi
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 cli
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,
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
"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
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, y
[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
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, implemente
> At 09:53 AM 4/30/2006 -0700, Guido van Rossum wrote:
> >I have a counter-proposal: let's drop __context__.
[...]
> > with mycontext.some_method(prec_incr=2):
> >
On 4/30/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> But what's an appropriate name for some_method?
Let's leave that up
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 durin
Hi,
main() in unittest has an optional parameter called argv. If it is not
present in the invocation, it defaults to None. Later in the function
a check is made to see if argv is None and if so sets it to sys.argv.
I think the default should be changed to sys.argv[1:] (i.e. the
command line argu
> ""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*
"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
""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 tha
"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() met
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
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 t
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".
>
>>
Zachary Pincus 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 sure
Thomas Wouters 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 requires
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 that
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
> #include
>
> int main(void) {
> Tcl_Interp *trp;
> unsetenv("DISPLAY");
> trp = Tcl_Cr
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
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 onl
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 c
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
> conta
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Specifically in the case of bytes.join(), the current common use-case of
> > .join(...) would become something similar to
> > bytes().join(...), unless bytes objects got a syntax... Or
> > maybe I'm missing something?
>
> I
"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
>
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 als
> 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
_
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
Guido van Rossum wrote:
> Well, yes, in most cases, but while attempting to write an I/O library
> I already had the urge to collect "chunks" I've read in a list and
> join them later, instead of concatenating repeatedly. I guess I should
> suppress this urge, and plan to optimize extending a bytes
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
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 argume
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:
>
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 resp
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 mod
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 con
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
> >
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: star
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 a
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 s
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
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
> > .join(...) would become something similar to
> > bytes().join(...), unless bytes objects got a syntax... Or
> > maybe I'm missing somethi
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.
Wh
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 w
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 vari
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:
http://ubique.ch/code
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
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 *
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 contextlib
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 -- P
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()/ma
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 stumble
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:
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 l
Josiah Carlson wrote:
> Specifically in the case of bytes.join(), the current common use-case of
> .join(...) would become something similar to
> bytes().join(...), unless bytes objects got a syntax... Or
> maybe I'm missing something?
I think what you are missing is that algorithms that currently
"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
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 are> assigned to named parameter slots. In particular, it enables the
> declaration of "keyword-only" arguments: argument
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 ar
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
61 matches
Mail list logo
