Re: [Python-Dev] draft of externally maintained packages PEP
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 cElementTree. this is a bit more accurate: > - Synchronisation history > * ElementTree 1.2.6 (2.5) > * cElementTree 1.0.5 (2.5) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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 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, anymore. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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: arguments that can only> be supplied by keyword and which will never be automatically> filled in by a positional argument.+1. And I suggest this be re-targeted for Python 2.6. Now all weneed is someone to implement this. ;-)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 a lot of reading of the AST and function-call code (if you haven't read it already.) -- Thomas Wouters <[EMAIL PROTECTED]>Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] methods on the bytes object (was: Crazy idea for str.join)
"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 objects which
> > implement the buffer interface as one of the items in the sequence?
>
> In Py3k, buffers won't be compatible with strings -- buffers will be
> about bytes, while strings will be about characters. Given that future
> I don't think we should mess with the semantics in 2.x; one change in
> the near(ish) future is enough of a transition.
This brings up something I hadn't thought of previously. While unicode
will obviously keep its .join() method when it becomes str in 3.x, will
bytes objects get a .join() method? Checking the bytes PEP, very little
is described about the type other than it basically being an array of 8
bit integers. That's fine and all, but it kills many of the parsing
and modification use-cases that are performed on strings via the non
__xxx__ methods.
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?
Anyways, when the bytes type was first being discussed, I had hoped that
it would basically become array.array("B", ...) + non-unicode str.
Allowing for bytes to do everything that str was doing before, plus a
few new tricks (almost like an mmap...), minus those operations which
require immutability.
- Josiah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] methods on the bytes object
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 operate on byte strings should be reformulated to operate on character strings, not reformulated to operate on bytes objects. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Problem with inspect and PEP 302
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rich comparisions and old-style classes
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: I'm afraid the only way to understand this is to step through the C code. I'm sure there is a reason along the lines of "well, we tried this and that, now let's try this slightly different thing which might or might not result in the same methods being called again". I notice that you didn't try comparing an old-style instance with a new-style one :-) More pragmatically I'd suggest that you only describe the new-style behavior. Old-style classes have two levels of dispatching starting from the introduction of new-style classes in 2.2 and I'm sure that no docs apart from deep technical references should have to worry about that. A bientot, Armin. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] rich comparisions and old-style classes
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 oddity that I cannot really explain: >> > > I'm afraid the only way to understand this is to step through the C > code. I'm sure there is a reason along the lines of "well, we tried > this and that, now let's try this slightly different thing which might > or might not result in the same methods being called again". > > I notice that you didn't try comparing an old-style instance with a > new-style one :-) > > More pragmatically I'd suggest that you only describe the new-style > behavior. Old-style classes have two levels of dispatching starting > from the introduction of new-style classes in 2.2 and I'm sure that no > docs apart from deep technical references should have to worry about > that. > > I thought a good rule of thumb (especially for a tutorial) was : Either define ``__cmp__`` *or* define the rich comparison operators. Doing both is a recipe for confusion. Michael Foord > A bientot, > > Armin. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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 want to use *args, but support some additional keyword arguments to tweak a few aspects of the operation (like providing a "key=x" option). Currently, to support such options, you need to accept **kwds, then go poking around inside the dict manually. This PEP simply allows you to request that the interpreter do such poking around for you, rather than having to do it yourself at the start of the function. I used to be a fan of the idea, but I'm now tending towards a -0, as I'm starting to think that wanting keyword-only arguments for a signature is a sign that the first argument to the function should have been an iterable, rather than accepting *args. However, there are syntactic payoffs that currently favour using *args instead of accepting an iterable as the first argument to a function. I recently went into a lot more detail on that topic as part of the py3k discussion of set literals [1]. I'd like to turn that message into the core of a PEP eventually, but given the target would be Python 2.6 at the earliest, there are plenty of other things higher on my to-do list. Cheers, Nick. [1] http://mail.python.org/pipermail/python-3000/2006-April/001504.html -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101: Advanced String Formatting
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 -- PEPs often change radically once they're thrown into
the wild.)
On Sat, Apr 29, 2006, Talin wrote:
>
> Braces can be escaped using a backslash:
>
> "My name is {0} :-\{\}".format('Fred')
You should include somewhere reasoning for using "\{" and "\}" instead
of "{{" and "}}".
> Simple names are either names or numbers. If numbers, they must
> be valid decimal numbers; if names, they must be valid Python
> identifiers. A number is used to identify a positional argument,
> while a name is used to identify a keyword argument.
s/decimal numbers/decimal integers/ (or possibly "base-10 integers" for
absolute clarity)
> The parameters to the cformat function are:
>
> -- The format string (or unicode; the same function handles
> both.)
> -- A field format hook (see below)
> -- A tuple containing the positional arguments
> -- A dict containing the keyword arguments
>
> The cformat function will parse all of the fields in the format
> string, and return a new string (or unicode) with all of the
> fields replaced with their formatted values.
>
> For each field, the cformat function will attempt to call the
> field format hook with the following arguments:
>
> field_hook(value, conversion, buffer)
You need to explain further what a field format hook is and how one
specifies it.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"Argue for your limitations, and sure enough they're yours." --Richard Bach
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] More on contextlib - adding back a contextmanager decorator
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 -
one for __context__ methods and one for standalone generator functions.
However, contextfactory seemed to meet both needs, so we didn't follow the
question up for alpha 2.
The second link in this chain is the subsequent discussion with Guido about
making the context manager and managed context protocols orthogonal. With this
clearer separation of the two terms to happen in alpha 3, it becomes more
reasonable to have two different generator decorators, one for defining
managed contexts and one for defining context managers.
The final link is a use case for such a context manager decorator, in the form
of a couple of HTML tag example contexts in the contextlib documentation.
(contextlib.nested is also a good use case, where caching can be used to
ensure certain resources are always acquired in the same order, but the issue
is easier to demonstrate using the HTML tag examples)
Firstly, the class-based HTML tag context manager example:
class TagClass:
def __init__(self, name):
self.name = name
@contextfactory
def __context__(self):
print "<%s>" % self.name
yield self
print "" % self.name
>>> h1_cls = TagClass('h1')
>>> with h1_cls:
... print "Header A"
...
Header A
>>> with h1_cls:
... print "Header B"
...
Header B
Each with statement creates a new context object, so caching the tag object
itself works just as you would expect. Unfortunately, the same cannot be said
for the generator based version:
@contextfactory
def tag_gen(name):
print "<%s>" % name
yield
print "" % name
>>> h1_gen = tag_gen('h1')
>>> with h1_gen:
... print "Header A"
...
Header A
>>> with h1_gen:
... print "Header B"
...
Traceback (most recent call last):
...
RuntimeError: generator didn't yield
The managed contexts produced by the context factory aren't reusable, so
caching them doesn't work properly - they need to be created afresh for each
with statement.
Adding another decorator to define context managers, as Paul suggested, solves
this problem neatly. Here's a possible implementation:
def managerfactory(gen_func):
# Create a context manager factory from a generator function
context_factory = contextfactory(gen_func)
def wrapper(*args, **kwds):
class ContextManager(object):
def __context__(self):
return context_factory(*args, **kwds)
mgr = ContextManager()
mgr.__context__() # Throwaway context to check arguments
return mgr
# Having @functools.decorator would eliminate the next 4 lines
wrapper.__name__ = context_factory.__name__
wrapper.__module__ = context_factory.__module__
wrapper.__doc__ = context_factory.__doc__
wrapper.__dict__.update(context_factory.__dict__)
return wrapper
@managerfactory
def tag_gen2(name):
print "<%s>" % name
yield
print "" % name
>>> h1_gen2 = tag_gen2('h1')
>>> with h1_gen2:
... print "Header A"
...
Header A
>>> with h1_gen2:
... print "Header B"
...
Header B
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Adding functools.decorator
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 * # Pick up functools.partial def _update_wrapper(decorated, func, deco_func): # Support naive introspection decorated.__module__ = func.__module__ decorated.__name__ = func.__name__ decorated.__doc__ = func.__doc__ decorated.__dict__.update(func.__dict__) # Provide access to decorator and original function decorated.__decorator__ = deco_func decorated.__decorates__ = func def decorator(deco_func): """Wrap a function as an introspection friendly decorator function""" def wrapper(func): decorated = deco_func(func) if decorated is func: return func _update_wrapper(decorated, func, deco_func) return decorated # Manually make this decorator introspection friendly _update_wrapper(wrapper, deco_func, decorator) return wrapper After typing those four lines of boilerplate to support naive introspection out in full several times for contextlib related decorators, I can testify that doing it by hand gets old really fast :) 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. Cheers, Nick. [1] http://www.python.org/sf/1478788 -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyThreadState_SetAsyncExc and native extensions
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 add more print statements to increase the chance that PyThreadState_SetAsyncExc is called when the module is executing Python code, the module stops. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __getslice__ usage in sre_parse
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/_sre/ _sre.py is needed for me because IronPython's own regex implementation using underlying .NET implementation is not compatible enough for my applications. I will write a separate bug report for this. It should be a matter of removing __getslice__ and adding isinstance(index, slice) check in __getitem__. I would very much appreciate it if this is fixed before Python 2.5. Seo Sanghyeon ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] elimination of scope bleeding of iteration variables
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 variable used in for-loops, list comprehensions, etc. bleeds out into the surrounding scope. [i'm aware that there is a similar proposal for python 3.0 for list comprehensions specifically, but that's not enough.] i've been bitten by this problem more than once. most recently, i had a simple function like this: # Replace property named PROP with NEW in PROPLIST, a list of tuples. def property_name_replace(prop, new, proplist): for i in xrange(len(proplist)): if x[i][0] == prop: x[i] = (new, x[i][1]) the use of `x' in here is an error, as it should be `proplist'; i previously had a loop `for x in proplist', but ran into the problem that tuples can't be modified, and lists can't be modified except by index. despite this obviously bad code, however, it ran without any complaint from python -- which amazed me, when i finally tracked this problem down. turns out i had two offenders, both way down in the "main" code at the bottom of the file -- a for-loop with loop variable x, and a list comprehension [x for x in output_file_map] -- and suddenly `x' is a global variable. yuck. i suggest that the scope of list comprehension iteration variables be only the list comprehension itself (see python 3000), and the scope of for-loop iteration variables be only the for-loop (including any following `else' statement -- this way you can access it and store it in some other variable if you really want it). in practice, i seriously doubt this will break much code and probably could be introduced like the previous scope change: using `from __future__' in python 2.5 or 2.6, and by default in the next version. it should be possible, in most circumstances, to issue a warning about code that relies on the old behavior. ben ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] elimination of scope bleeding of iteration variables
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 whereby > the iteration variable used in for-loops, list comprehensions, etc. > bleeds out into the surrounding scope. > > [i'm aware that there is a similar proposal for python 3.0 for list > comprehensions specifically, but that's not enough.] List comprehensions will be fixed in Py3k. 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. Accordingly, there is plenty of code in the wild that *would* break if the for loop variables were constrained to the for loop, even if your own code wouldn't have such a problem. Outside pure scripts, significant control flow logic (like for loops) should be avoided at module level. You are typically much better off moving the logic inside a _main() function and invoking it at the end of the module. This avoids the 'accidental global' problem for all of the script-only variables, not only the ones that happen to be used as for loop variables. > # Replace property named PROP with NEW in PROPLIST, a list of tuples. > def property_name_replace(prop, new, proplist): > for i in xrange(len(proplist)): > if x[i][0] == prop: > x[i] = (new, x[i][1]) This wouldn't have helped with your name-change problem, but you've got a lot of unnecessary indexing going on there: def property_name_replace(prop, new, proplist): for i, (name, value) in enumerate(proplist): if name == prop: proplist[i] = (new, value) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding functools.decorator
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 about preserving decorated function's signature, like we do in TurboGears [1]? Cheers, Simon [1] http://trac.turbogears.org/turbogears/browser/trunk/turbogears/decorator.py ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] methods on the bytes object
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 something? > > 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. 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 arrays instead, along the lines of how we optimize lists. 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: startswith, endswith, index, rindex, find, rfind, split, rsplit, join, count, replace, translate. (I'm skipping center, ljust and rjust since they seem exclusive to text processing. Ditto for strip/lstrip/rstrip although an argument for those could probably be made, with mandatory 2nd arg.) Unhelpfully y'rs, -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding functools.decorator
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: I'm all for it. (You could integrate the C version of "decorator" from my SF patch, but I think Python-only is enough). > from _functools import * # Pick up functools.partial > > def _update_wrapper(decorated, func, deco_func): > # Support naive introspection > decorated.__module__ = func.__module__ > decorated.__name__ = func.__name__ > decorated.__doc__ = func.__doc__ > decorated.__dict__.update(func.__dict__) > # Provide access to decorator and original function > decorated.__decorator__ = deco_func > decorated.__decorates__ = func > > def decorator(deco_func): > """Wrap a function as an introspection friendly decorator function""" > def wrapper(func): > decorated = deco_func(func) > if decorated is func: > return func > _update_wrapper(decorated, func, deco_func) > return decorated > # Manually make this decorator introspection friendly > _update_wrapper(wrapper, deco_func, decorator) > return wrapper > > After typing those four lines of boilerplate to support naive introspection > out in full several times for contextlib related decorators, I can testify > that doing it by hand gets old really fast :) Agreed. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __getslice__ usage in sre_parse
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 shouldn't use it. So I disagree that technically there's a reason why sre_parse shouldn't use it. > __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/_sre/ > > _sre.py is needed for me because IronPython's own regex implementation > using underlying .NET implementation is not compatible enough for my > applications. I will write a separate bug report for this. > > It should be a matter of removing __getslice__ and adding > isinstance(index, slice) check in __getitem__. I would very much > appreciate it if this is fixed before Python 2.5. You can influence the fix yourself -- please write a patch (relative to Python 2.5a2 that was just released), submit it to Python's patch tracker on SourceForge (read python.org/dev first), and then sending an email here to alert the developers. This ought to be done well before the planned 2.5b1 release (see PEP 256 for the 2.5 release timeline). You should make sure that the patched Python 2.5 passes all unit tests before submitting your test. Good luck! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyThreadState_SetAsyncExc and native extensions
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 about using Python. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "Argue for your limitations, and sure enough they're yours." --Richard Bach ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] methods on the bytes object
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: startswith, endswith, index, rindex, >find, rfind, split, rsplit, join, count, replace, translate. I've often wished *lists* had startswith and endswith, and somewhat less often wished they had split or rsplit. Those seem like things that are generally applicable to sequences, not just strings or bytes. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding functools.decorator
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 functools, and then add a functools.py consisting of: > > I'm all for it. (You could integrate the C version of "decorator" from my SF > patch, but I think Python-only is enough). Stronger -- this should *not* be implemented in C. There's no performance need, and the C code is much harder to understand, check, and modify. 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. (Doesn't this already apply to __decorator__ and __decorates__? I can't prove to myself that these get set to the right things when several decorators are stacked on top of each other.) I'm curious if @decorator is the right name and the right API for this though? The name is overly wide (many things are decorators but should not be decorated with @decorator) and I wonder of a manual call to _update_wrapper() wouldn't be just as useful. (Perhaps with a simpler API -- I'm tempted to call YAGNI on the __decorator__ and __decorates__ attributes.) I think there are too many design options here to check this in without more discussion. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
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 API design has gotten totally out of hand. Regardless of the merits of the "with" approach to HTML generation (which I personally believe to be an abomination), I don't see why the standard library should support every possible use case with a custom-made decorator. Let the author of that tag library provide the decorator. 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 example that I know of where __context__ doesn't return self is the decimal module. So the decimal users would have to type with mycontext.some_method() as ctx:# ctx is a clone of mycontext ctx.prec += 2 The implementation of some_method() could be exactly what we currently have as the __context__ method on the decimal.Context object. Its return value is a decimal.WithStatementContext() instance, whose __enter__() method returns a clone of the original context object which is assigned to the variable in the with-statement (here 'ctx'). This even has an additional advantage -- some_method() could have keyword parameters to set the precision and various other context parameters, so we could write this: with mycontext.some_method(prec=mycontext.prec+2): Note that we can drop the variable too now (unless we have another need to reference it). An API tweak for certain attributes that are often incremented or decremented could reduce writing: with mycontext.some_method(prec_incr=2): -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding functools.decorator
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 >> > _functools >> > rather than functools, and then add a functools.py consisting of: >> >> I'm all for it. (You could integrate the C version of "decorator" from my SF >> patch, but I think Python-only is enough). > > Stronger -- this should *not* be implemented in C. There's no > performance need, and the C code is much harder to understand, check, > and modify. +1. > 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 there? If someone wants to achieve this, she can write his own version of @decorator. One thing that would be nice to copy is the signature, but for that, like demonstrated by Simon Belak, exec trickery is necessary, and I think that's one step too far. The basic wish is just to let introspective tools, and perhaps APIs that rely on function's __name__ and __doc__ work flawlessly with decorators applied, nothing more. > (Doesn't this already > apply to __decorator__ and __decorates__? I can't prove to myself that > these get set to the right things when several decorators are stacked > on top of each other.) I don't think they're necessary. > I'm curious if @decorator is the right name and the right API for this > though? The name is overly wide (many things are decorators but should > not be decorated with @decorator) and I wonder of a manual call to > _update_wrapper() wouldn't be just as useful. Still, _update_wrapper would need to be defined somewhere, and it would have to be called in the body of the decorator. > (Perhaps with a simpler > API -- I'm tempted to call YAGNI on the __decorator__ and > __decorates__ attributes.) > > I think there are too many design options here to check this in > without more discussion. So let the discussion begin! Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanagerdecorator
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 response to the endless nick-phillip-paul "today I put in my brain the other way" threads... ;-) (but the design isn't really that hard to explain; it's just that ever- one seems to be missing that there are three objects involved, not two...) But if you think we can get rid of the "with statement context object" [1], I'm all for it. "explicit is better than implicit" etc. +1. 1) http://docs.python.org/dev/ref/with.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] in-out parameters
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 f(wrappedParam): ... wrappedParam[0] += 5 ... return "this is my result" ... >>> # call it ... x = 2 >>> result = f([x]) >>> x 2 You probably intended something more like: >>> x = [2] >>> result = f(x) >>> x[0] 7 (As for the actual topic, I'm personally -0 for adding in-out parameters to python.) -Edward ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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
> is via keyword, such arguments are therefore 'required keyword'
> arguments. Such arguments must be supplied by the caller, and
> they must be supplied via keyword.
So what would this look like?
def foo(*args, kw1, kw2):
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. At least it makes it clear that kw1 and kw2 are
keyword arguments, and that they have no default values.
Though, I'm kind of neutral on the whole bit -- in my mind "keyword
args" and "default-value args" are pretty conflated and I can't think
of any compelling reasons why they shouldn't be. It's visually handy
when looking at some code to see keywords and be able to say "ok,
those are the optional args for changing the handling of the main
args". I'm not sure where the big win with required keyword args is.
For that matter, why not "default positional args"? I think everyone
will agree that seems a bit odd, but it isn't too much odder than
"required keyword args". (Not that I'm for the former! I'm just
pointing out that if the latter is OK, there's no huge reason why the
former wouldn't be, and that is in my mind a flaw.)
Second:
> def compare(a, b, *, key=None):
This syntax seems a bit odd to me, as well. I always "understood" the
*args syntax by analogy to globbing -- the asterisk means to "take
all the rest", in some sense in both a shell glob and *args.
In this syntax, the asterisk, though given a position in the comma-
separated list, doesn't mean "take the rest and put it in this
position." It means "stop taking things before this position", which
is a bit odd, in terms of items *in* an argument list.
I grant that it makes sense as a derivation from "*ignore"-type
solutions, but as a standalone syntax it feels off. How about
something like:
def compare(a, b; key=None):
The semicolon is sort of like a comma but more forceful; it ends a
phrase. This seems like a logical (and easily comprehended by
analogy) use here -- ending the "positional arguments" phrase.
Zach Pincus
Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine
On Apr 29, 2006, at 11:27 AM, Talin wrote:
> PEP: 3102
> Title: Keyword-Only Arguments
> Version: $Revision$
> Last-Modified: $Date$
> Author: Talin
> Status: Draft
> Type: Standards
> Content-Type: text/plain
> Created: 22-Apr-2006
> Python-Version: 3.0
> Post-History:
>
>
> 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 supplied by keyword and which will never be automatically
> filled in by a positional argument.
>
>
> Rationale
>
> The current Python function-calling paradigm allows arguments to
> be specified either by position or by keyword. An argument
> can be
> filled in either explicitly by name, or implicitly by position.
>
> There are often cases where it is desirable for a function to
> take
> a variable number of arguments. The Python language supports
> this
> using the 'varargs' syntax ('*name'), which specifies that any
> 'left over' arguments be passed into the varargs parameter as a
> tuple.
>
> One limitation on this is that currently, all of the regular
> argument slots must be filled before the vararg slot can be.
>
> This is not always desirable. One can easily envision a function
> which takes a variable number of arguments, but also takes one
> or more 'options' in the form of keyword arguments. Currently,
> the only way to do this is to define both a varargs argument,
> and a 'keywords' argument (**kwargs), and then manually extract
> the desired keywords from the dictionary.
>
>
> Specification
>
> Syntactically, the proposed changes are fairly simple. The first
> change is to allow regular arguments to appear after a varargs
> argument:
>
> def sortwords(*wordlist, case_sensitive=False):
> ...
>
> This function accepts any number of positional arguments, and it
> also accepts a keyword option called 'case_sensitive'. This
> option will never be filled in by a positional argument, but
> must be explicitly specified by name.
>
> Keyword-only arguments are not required to have a default value.
> Since Python requires that all arg
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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 to a keyword-only argument >> is via keyword, such arguments are therefore 'required keyword' >> arguments. Such arguments must be supplied by the caller, and >> they must be supplied via keyword. > > So what would this look like? >def foo(*args, kw1, kw2): > > 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. At least it makes it clear that kw1 and kw2 are > keyword arguments, and that they have no default values. Interesting, but perhaps a little too fancy. > Though, I'm kind of neutral on the whole bit -- in my mind "keyword > args" and "default-value args" are pretty conflated and I can't think > of any compelling reasons why they shouldn't be. It's visually handy > when looking at some code to see keywords and be able to say "ok, > those are the optional args for changing the handling of the main > args". I'm not sure where the big win with required keyword args is. Personally I think that required keyword args will not be the most used feature brought by this PEP. More important is that you can give a function as many positional args as you want, all sucked up by the *args, and still supply a "controlling" keyword arg. > For that matter, why not "default positional args"? I think everyone > will agree that seems a bit odd, but it isn't too much odder than > "required keyword args". (Not that I'm for the former! I'm just > pointing out that if the latter is OK, there's no huge reason why the > former wouldn't be, and that is in my mind a flaw.) > > Second: >> def compare(a, b, *, key=None): > This syntax seems a bit odd to me, as well. I always "understood" the > *args syntax by analogy to globbing -- the asterisk means to "take > all the rest", in some sense in both a shell glob and *args. > > In this syntax, the asterisk, though given a position in the comma- > separated list, doesn't mean "take the rest and put it in this > position." It means "stop taking things before this position", which > is a bit odd, in terms of items *in* an argument list. It continues to mean "take the rest", but because there is no name to put it into, it will raise an exception if a rest is present. For me, it seems consistent. > I grant that it makes sense as a derivation from "*ignore"-type > solutions, but as a standalone syntax it feels off. How about > something like: >def compare(a, b; key=None): > > The semicolon is sort of like a comma but more forceful; it ends a > phrase. This seems like a logical (and easily comprehended by > analogy) use here -- ending the "positional arguments" phrase. Guido already ruled it out because it's an "end of statement" marker and nothing else. Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] methods on the bytes object
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 arrays
> instead, along the lines of how we optimize lists.
That is certainly a frequent, although degenerated, use case of
string.join (i.e. with an empty separator). Instead of introducing
bytes.join, I think we should reconsider this:
py> sum(["ab","cd"],"")
Traceback (most recent call last):
File "", line 1, in
TypeError: sum() can't sum strings [use ''.join(seq) instead]
Why is it that sum requires numbers?
> 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: startswith, endswith, index, rindex,
> find, rfind, split, rsplit, join, count, replace, translate.
The problem I see with these is that people will use them for text-ish
operations, e.g.
data.startswith("text".encode("ascii"))
While that would be "correct", I see two problems:
a) people will complain that they have to use an explicit .encode
call, and demand that this should "just work", and
b) people will refuse to rewrite their algorithms for character
strings (which they likely should in most applications of,
say, .startswith), and then complain that the bytes type
is s limited, and they really want a full byte string
type back.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101: Advanced String Formatting
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 simple names seperated by
> periods:
>
> "My name is {0.name} :-\{\}".format(dict(name='Fred'))
>
> Compound names can be used to access specific dictionary entries,
> array elements, or object attributes. In the above example, the
> '{0.name}' field refers to the dictionary entry 'name' within
> positional argument 0.
Barring ambiguity about whether .name would mean the "name" attribute
or the "name" dictionary entry if both were defined, I'm not sure I
really see the point. How is:
d = {last:'foo', first:'bar'}
"My last name is {0.last}, my first name is {0.first}.".format(d)
really that big a win over:
d = {last:'foo', first:'bar'}
"My last name is {0}, my first name is {1}.".format(d['last'], d
['first'])
Plus, the in-string syntax is limited -- e.g. what if I want to call
a function on an attribute? Unless you want to re-implement all
python syntax within the formatters, someone will always be able to
level these sort of complaints. Better, IMO, to provide none of that
than a restricted subset of the language -- especially if the syntax
looks and works differently from real python.
Zach Pincus
Program in Biomedical Informatics and Department of Biochemistry
Stanford University School of Medicine
On Apr 29, 2006, at 11:24 AM, Talin wrote:
> PEP: 3101
> Title: Advanced String Formatting
> Version: $Revision$
> Last-Modified: $Date$
> Author: Talin
> 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 formatting
> operations, intended as a replacement for the existing '%' string
> formatting operator.
>
>
> Rationale
>
> Python currently provides two methods of string interpolation:
>
> - The '%' operator for strings. [1]
>
> - The string.Template module. [2]
>
> The scope of this PEP will be restricted to proposals for
> built-in
> string formatting operations (in other words, methods of the
> built-in string type).
>
> The '%' operator is primarily limited by the fact that it is a
> binary operator, and therefore can take at most two arguments.
> One of those arguments is already dedicated to the format string,
> leaving all other variables to be squeezed into the remaining
> argument. The current practice is to use either a dictionary
> or a
> tuple as the second argument, but as many people have commented
> [3], this lacks flexibility. The "all or nothing" approach
> (meaning that one must choose between only positional arguments,
> or only named arguments) is felt to be overly constraining.
>
> While there is some overlap between this proposal and
> string.Template, it is felt that each serves a distinct need,
> and that one does not obviate the other. In any case,
> string.Template will not be discussed here.
>
>
> Specification
>
> The specification will consist of 4 parts:
>
> - Specification of a set of methods to be added to the built-in
>string class.
>
> - Specification of a new syntax for format strings.
>
> - Specification of a new set of class methods to control the
>formatting and conversion of objects.
>
> - Specification of an API for user-defined formatting classes.
>
>
> String Methods
>
> The build-in string class will gain a new method, 'format',
> which takes takes an arbitrary number of positional and keyword
> arguments:
>
> "The story of {0}, {1}, and {c}".format(a, b, c=d)
>
> Within a format string, each positional argument is identified
> with a number, starting from zero, so in the above example,
> 'a' is
> argument 0 and 'b' is argument 1. Each keyword argument is
> identified by its keyword name, so in the above example, 'c' is
> used to refer to the third argument.
>
> The result of the format call is an object of the same type
> (string or unicode) as the format string.
>
>
> Format Strings
>
> Brace characters ('curly braces') are used to indicate a
> replacement field within the string:
>
> "My name is {0}".format('Fred')
>
> The result of this is the string:
>
> "My name is Fred"
>
> Braces can be escaped using a backslash:
>
> "My name is {0} :-\{\}".format('Fred')
>
> Which would produce:
>
> "My name is Fred :-{}"
>
> The element within the braces is called a 'field'. Fields
> consist
> of a name, which can either be simple or compound, and an
> optional
> 'conversion spec
Re: [Python-Dev] PEP 3101: Advanced String Formatting
> 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
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101: Advanced String Formatting
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 think that's a bad idea.
>> Compound names are a sequence of simple names seperated by
>> periods:
>>
>> "My name is {0.name} :-\{\}".format(dict(name='Fred'))
And these escapes are also a bad idea. As it is, the backslashes stay in the
string, but it is not obvious to newcomers whether \{ is a general string
escape. The "right" way to do it would be "\\{", but that's becoming rather
longly. Why not use something like "{{"?
>> Compound names can be used to access specific dictionary entries,
>> array elements, or object attributes. In the above example, the
>> '{0.name}' field refers to the dictionary entry 'name' within
>> positional argument 0.
>
> Barring ambiguity about whether .name would mean the "name" attribute
> or the "name" dictionary entry if both were defined, I'm not sure I
> really see the point. How is:
>d = {last:'foo', first:'bar'}
>"My last name is {0.last}, my first name is {0.first}.".format(d)
>
> really that big a win over:
>d = {last:'foo', first:'bar'}
>"My last name is {0}, my first name is {1}.".format(d['last'], d
> ['first'])
Or even:
d = {last:'foo', first:'bar'}
"My last name is {last}, my first name is {first}.".format(**d)
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
"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 supplied by keyword and which will never be automatically
> filled in by a positional argument.
>
>
> Rationale
>
> The current Python function-calling paradigm allows arguments to
> be specified either by position or by keyword. An argument can be
> filled in either explicitly by name, or implicitly by position.
>
> There are often cases where it is desirable for a function to take
> a variable number of arguments. The Python language supports this
> using the 'varargs' syntax ('*name'), which specifies that any
> 'left over' arguments be passed into the varargs parameter as a
> tuple.
>
> One limitation on this is that currently, all of the regular
> argument slots must be filled before the vararg slot can be.
>
> This is not always desirable. One can easily envision a function
> which takes a variable number of arguments, but also takes one
> or more 'options' in the form of keyword arguments. Currently,
> the only way to do this is to define both a varargs argument,
> and a 'keywords' argument (**kwargs), and then manually extract
> the desired keywords from the dictionary.
>
First of all, let me remark that The current python symantics almost
perfectly
match those of VB6. Sure there is a little bit of syntax differences, but
overall
they are approximately equivlent. This is actually a good thing
The one area thing that VB6 allows that python does not is optional
arguments
without a default value. However, what really happens is that the compiler
assigns a default
value, so it really is only a tiny difference.
The main proposal here adds an aditional feature, and thus will break th
matching of VB6,
but not in a negative way, as VB6 could benefit from the same extention. So
I would be +1.
However, I'm not sure what the use case is for keyword only arguments on
functions
that do *not* accept a variable number of arguments. Could you please
provide an example use case?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] methods on the bytes object
"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 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, and not some new "character string" type? I know I must have missed some conversation. I was under the impression that in Py3k: Python 1.x and 2.x str -> mutable bytes object Python 2.x unicode -> str I was also under the impression that str.encode(...) -> bytes, bytes.decode(...) -> str, and that there would be some magical argument to pass to the file or open open(fn, 'rb', magical_parameter).read() -> bytes. I mention this because I do binary data handling, some ''.join(...) for IO buffers as Guido mentioned (because it is the fastest string concatenation available in Python 2.x), and from this particular conversation, it seems as though Python 3.x is going to lose some expressiveness and power. - Josiah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] methods on the bytes object
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, and not some new "character string" type? I mean unicode strings, period. I can't imagine what "unicode strings which do not contain data" could be. > I know I must > have missed some conversation. I was under the impression that in Py3k: > > Python 1.x and 2.x str -> mutable bytes object No. Python 1.x and 2.x str -> str, Python 2.x unicode -> str In addition, a bytes type is added, so that Python 1.x and 2.x str -> bytes The problem is that the current string type is used both to represent bytes and characters. Current applications of str need to be studied, and converted appropriately, depending on whether they use "str-as-bytes" or "str-as-characters". The "default", in some sense of that word, is that str applications are assumed to operate on character strings; this is achieved by making string literals objects of the character string type. > I was also under the impression that str.encode(...) -> bytes, > bytes.decode(...) -> str Correct. > and that there would be some magical argument > to pass to the file or open open(fn, 'rb', magical_parameter).read() -> > bytes. I think the precise details of that are still unclear. But yes, the plan is to have two file modes: one that returns character strings (type 'str') and one that returns type 'bytes'. > I mention this because I do binary data handling, some ''.join(...) for > IO buffers as Guido mentioned (because it is the fastest string > concatenation available in Python 2.x), and from this particular > conversation, it seems as though Python 3.x is going to lose > some expressiveness and power. You certainly need a "concatenate list of bytes into a single bytes". Apparently, Guido assumes that this can be done through bytes().join(...); I personally feel that this is over-generalization: if the only practical application of .join is the empty bytes object as separator, I think the method should be omitted. Perhaps bytes(...) or bytes.join(...) could work? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101: Advanced String Formatting
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 collecting all feedback, and either updating the specification, or at least, summarizing the discussion and the open issues (so that the same argument isn't made over and over again). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
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 example that I know of where >__context__ doesn't return self is the decimal module. So the decimal >users would have to type > > with mycontext.some_method() as ctx:# ctx is a clone of mycontext > ctx.prec += 2 > > >The implementation of some_method() could be exactly what we currently >have as the __context__ method on the decimal.Context object. Its >return value is a decimal.WithStatementContext() instance, whose >__enter__() method returns a clone of the original context object >which is assigned to the variable in the with-statement (here 'ctx'). > >This even has an additional advantage -- some_method() could have >keyword parameters to set the precision and various other context >parameters, so we could write this: > > with mycontext.some_method(prec=mycontext.prec+2): > > >Note that we can drop the variable too now (unless we have another >need to reference it). An API tweak for certain attributes that are >often incremented or decremented could reduce writing: > > with mycontext.some_method(prec_incr=2): > But what's an appropriate name for some_method? Given that documentation is the sore spot that keeps us circling around this point, doesn't this just push the problem to finding a name to use in place of __context__? And not only for this use case, but for others? After all, for any library that has a notion of "the current X", it seems reasonable to want to be able to say "with some_X" to mean "use some_X as the current X for this block". And it thus seems to me that people will want to have something like: def using(obj): if hasattr(obj,'__context__'): obj = obj.__context__() return obj so they can do "with using(some_X)", because "with some_X.using()" or "with some_X.as_current()" is awkward. If you can solve the naming issue for these use cases (and I notice you punted on that issue by calling it "some_method"), then +1 on removing __context__. Otherwise, I'm -0; we're just fixing one documentation/explanation problem (that only people writing contexts will care about) by creating others (that will affect the people *using* contexts too). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Problem with inspect and PEP 302
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 '' and '' filenames were producing an infinite regress. I've checked in a fix. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter lockups.
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_CreateInterp();
> printf("%d\n", Tk_Init(trp));
> printf("%d\n", Tk_Init(trp));
> return 0;
> }
The problem only occurs when Tcl and Tk were compiled with
--enable-threads, and it occurs because Tk fails to unlock a mutex
in a few error cases. The patch below fixes the problem.
I'll report it to the Tcl people, and see whether I can work around
in _tkinter.
Regards,
Martin
diff -ur tk8.4.13/generic/tkWindow.c tk8.4.13.modified/generic/tkWindow.c
--- tk8.4.13/generic/tkWindow.c 2006-04-04 23:49:57.0 +0200
+++ tk8.4.13.modified/generic/tkWindow.c2006-04-30 21:41:37.0
+0200
@@ -3108,6 +3108,7 @@
Tcl_DStringFree(&class);
if (code != TCL_OK) {
+ Tcl_MutexUnlock(&windowMutex);
goto done;
}
Tcl_ResetResult(interp);
@@ -3124,6 +3125,7 @@
Tcl_SetVar(interp, "geometry", geometry, TCL_GLOBAL_ONLY);
code = Tcl_VarEval(interp, "wm geometry . ", geometry, (char *) NULL);
if (code != TCL_OK) {
+ Tcl_MutexUnlock(&windowMutex);
goto done;
}
geometry = NULL;
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] socket module recvmsg/sendmsg
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 are defined on Linux). The main reason I need these two primitives is that I require (more or less transparent) file/socket descriptor exchange between two forked processes, where one process accepts a socket, and delegates processing of the socket connection to another process of a set of processes; this is much like a ForkingTCPServer, but with the Handler-process prestarted. As connection to the Unix-Domain-Socket is openly available, the receiving process needs to check the identity of the first process; this is done using a getsockopt(SO_PEERCRED) call, which is also handled more specifically by my socket extension to return a socket._ucred-type structure, which wraps the pid/uid/gid-structure returned by the corresponding getsockopt call, and also the socket message (SCM_CREDENTIALS) which passes or sets this information for the remote process. I'd love to see these two socket message primitives (of which the first, SCM_RIGHTS, is available on pretty much any Unix derivative) included in a Python distribution at some point in time, and as I've not got the time to push for an inclusion in the tree (and even less time to work on other Python patches myself) at the moment, I thought that I might just post here so that someone interested might pick up the work I've done so far and check the implementation for bugs, and at some stage these two functions might actually find their way into the Python core. Anyway, my private Python tree (which has some other patches which aren't of general interest, I'd think) is available at: http://dev.modelnine.org/hg/python and I can, if anyone is interested, post a current diff of socketmodule.* against 2.4.3 to the Python bug tracker at sourceforge. I did that some time ago (about half a year) when socket-passing code wasn't completely functioning yet, but at least at that point there didn't seem much interest in the patch. The patch should apply pretty cleanly against the current HEAD too, at least it did the last time I checked. I'll add a small testsuite for both functions to my tree some time tomorrow. --- Heiko. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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 a lot of reading of the AST and function-call code (if you haven't read it already.) If someone wants to implement this, feel free - I have no particular feelings of "ownership" over this idea. If someone can do it better than I can, then that's the implementation that should be chosen. One suggestion I would have would be to implement the two parts of the PEP (keyword-only arguments vs. the 'naked star' syntax) as two separate patches; While there seems to be a relatively wide-spread support for the former, the latter is still somewhat controversial and will require further discussion. -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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. At least it makes it clear that kw1 and kw2 are > keyword arguments, and that they have no default values. > > Though, I'm kind of neutral on the whole bit -- in my mind "keyword > args" and "default-value args" are pretty conflated and I can't think > of any compelling reasons why they shouldn't be. It's visually handy > when looking at some code to see keywords and be able to say "ok, > those are the optional args for changing the handling of the main > args". I'm not sure where the big win with required keyword args is. I think a lot of people conflate the two, because of the similarity in syntax, however they aren't really the same thing. In a function definition, any argument can be a keyword argument, and the presence of '=' means 'default value', not 'keyword'. I have to admit that the primary reason for including required keyword arguments in the PEP is because they fall out naturally from the implementation. If we remove this from the PEP, then the implementation becomes more complicated - because now you really are assigning a meaning to '=' other than 'default value'. >From a user standpoint, I admit the benefits are small, but I don't see that it hurts either. The only use case that I can think of is when you have a function that has some required and some optional keyword arguments, and there is some confusion about the ordering of such arguments. By disallowing the arguments to be positional, you eliminate the possibility of having an argument be assigned to the incorrect parameter slot. > For that matter, why not "default positional args"? I think everyone > will agree that seems a bit odd, but it isn't too much odder than > "required keyword args". (Not that I'm for the former! I'm just > pointing out that if the latter is OK, there's no huge reason why the > former wouldn't be, and that is in my mind a flaw.) > > Second: > > def compare(a, b, *, key=None): > This syntax seems a bit odd to me, as well. I always "understood" the > *args syntax by analogy to globbing -- the asterisk means to "take > all the rest", in some sense in both a shell glob and *args. > > In this syntax, the asterisk, though given a position in the comma- > separated list, doesn't mean "take the rest and put it in this > position." It means "stop taking things before this position", which > is a bit odd, in terms of items *in* an argument list. > > I grant that it makes sense as a derivation from "*ignore"-type > solutions, but as a standalone syntax it feels off. How about > something like: >def compare(a, b; key=None): I wanted the semicolon as well, but was overruled. The current proposal is merely a summary of the output of the discussions so far. -- Talin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101: Advanced String Formatting
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".
>
>> Compound names are a sequence of simple names seperated by
>> periods:
>>
>> "My name is {0.name} :-\{\}".format(dict(name='Fred'))
>>
>> Compound names can be used to access specific dictionary entries,
>> array elements, or object attributes. In the above example, the
>> '{0.name}' field refers to the dictionary entry 'name' within
>> positional argument 0.
>
>
> Barring ambiguity about whether .name would mean the "name" attribute
> or the "name" dictionary entry if both were defined, I'm not sure I
> really see the point. How is:
> d = {last:'foo', first:'bar'}
> "My last name is {0.last}, my first name is {0.first}.".format(d)
>
> really that big a win over:
> d = {last:'foo', first:'bar'}
> "My last name is {0}, my first name is {1}.".format(d['last'], d
> ['first'])
At one point I had intended to abandon the compound-name syntax, until I
realized that it had one beneficial side-effect, which is that it offers
a way around the 'dict-copying' problem.
There are a lot of cases where you want to pass an entire dict as the
format args using the **kwargs syntax. One common use pattern is for
debugging code, where you want to print out a bunch of variables that
are in the local scope:
print "Source file: {file}, line: {line}, column: {col}"\
.format( **locals() )
The problem with this is one of efficiency - the interpreter handles **
by copying the entire dictionary and merging it with any keyword arguments.
Under most sitations this is fine; However if the dictionary is
particularly large, it might be a problem. So the intent of the
compound name syntax is to allow something very similar:
print "Source file: {0.file}, line: {0.line}, column: {0.col}"\
.format( locals() )
Now, its true that you could also do this by passing in the 3 parameters
as individual arguments; However, there have been some strong proponents
of being able to pass in a single dict, and rather than restating their
points I'll let them argue their own positions (so as not to
accidentally mis-state them.)
> Plus, the in-string syntax is limited -- e.g. what if I want to call a
> function on an attribute? Unless you want to re-implement all python
> syntax within the formatters, someone will always be able to level
> these sort of complaints. Better, IMO, to provide none of that than a
> restricted subset of the language -- especially if the syntax looks and
> works differently from real python.
The in-string syntax is limited deliberately for security reasons.
Allowing arbitrary executable code within a string is supported by a
number of other scripting languages, and we've seen a good number of
exploits as a result.
I chose to support only __getitem__ and __getattr__ because I felt that
they would be relatively safe; usually (but not always) those functions
are written in a way that has no side effects.
-- Talin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Adding functools.decorator
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, tweak it so the C module is built as > > > _functools > > > rather than functools, and then add a functools.py consisting of: > > > > I'm all for it. (You could integrate the C version of "decorator" from my SF > > patch, but I think Python-only is enough). > > Stronger -- this should *not* be implemented in C. There's no > performance need, and the C code is much harder to understand, check, > and modify. > > 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. (Doesn't this already > apply to __decorator__ and __decorates__? I can't prove to myself that > these get set to the right things when several decorators are stacked > on top of each other.) > > I'm curious if @decorator is the right name and the right API for this > though? The name is overly wide (many things are decorators but should > not be decorated with @decorator) and I wonder of a manual call to > _update_wrapper() wouldn't be just as useful. I am +0 on the manual call. Just seems like I would like to happen explicitly instead of through a decorator. > (Perhaps with a simpler > API -- I'm tempted to call YAGNI on the __decorator__ and > __decorates__ attributes.) > This should also be redundant once I get the signature PEP cleaned up (and probably email py3k or python-dev on the subject) since I plan to store a reference to the function the object represents. That would mean if update_wrapper() copies the signature object over then you have a reference to the original function that way. -Brett > I think there are too many design options here to check this in > without more discussion. > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
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 brought up during that discussion. > > I believe the context API design has gotten totally out of hand. > Regardless of the merits of the "with" approach to HTML generation > (which I personally believe to be an abomination), I don't see why the > standard library should support every possible use case with a > custom-made decorator. Let the author of that tag library provide the > decorator. > > 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 example that I know of where > __context__ doesn't return self is the decimal module. So the decimal > users would have to type > +1. -Brett > with mycontext.some_method() as ctx:# ctx is a clone of mycontext > ctx.prec += 2 > > > The implementation of some_method() could be exactly what we currently > have as the __context__ method on the decimal.Context object. Its > return value is a decimal.WithStatementContext() instance, whose > __enter__() method returns a clone of the original context object > which is assigned to the variable in the with-statement (here 'ctx'). > > This even has an additional advantage -- some_method() could have > keyword parameters to set the precision and various other context > parameters, so we could write this: > > with mycontext.some_method(prec=mycontext.prec+2): > > > Note that we can drop the variable too now (unless we have another > need to reference it). An API tweak for certain attributes that are > often incremented or decremented could reduce writing: > > with mycontext.some_method(prec_incr=2): > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101: Advanced String Formatting
"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 just a wrapper that calls cformat. > > The parameters to the cformat function are: > > -- The format string (or unicode; the same function handles >both.) A class method gets the class as its first argument. If the format string in the first argument, then it is a normal instance method. tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
""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 (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, anymore. 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 with a naked '*'. To the first, I said "The rationale for this is pretty obvious.". To the second, I asked, and still ask, "Why?". Talin himself said today in a followup post: > One suggestion I would have would be to implement the two parts of the > PEP (keyword-only arguments vs. the 'naked star' syntax) as two > separate patches; While there seems to be a relatively wide-spread > support for the former, the latter is still somewhat controversial and > will require further discussion. 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? Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
"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) without the >> parameter name? Like Martin, you clipped most of the essential context of my question: Talin's second proposal. >>>The second syntactical change is to allow the argument name to >>>be omitted for a varargs argument: >>>def compare(a, b, *, key=None): >>>The reasoning behind this change is as follows. Imagine for a >>>moment a function which takes several positional arguments, as >>>well as a keyword argument: >>>def compare(a, b, key=None): Again I ask, why would one want that? And, is the need for that so strong as to justify introducing '*' as a pseudoparameter? > 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 'explanation' is about Talin's first proposal, to which I already had said "The rationale for this is pretty obvious". Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
> ""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 variable number of arguments. Could you please provide an example use case? tjr ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unittest argv
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 arguments minus the name of the python file being executed). The parseArgs() function then uses getopt to parse argv. It currently ignores the first item in the argv list, but this causes a problem when it is called from another python function and not from the command line. So using the current code if I call: python mytest.py -v then argv in parseArgs is ['mytest.py', '-v'] But, if I call: unittest.main(module=None, argv=['-v','mytest']) then argv in parseArgs is ['mytest'], as you can see the verbosity option is now gone and cannot be used. Here's a diff to show the code changes I have made: 744c744 < argv=None, testRunner=None, testLoader=defaultTestLoader): --- > argv=sys.argv[1:], testRunner=None, > testLoader=defaultTestLoader): 751,752d750 < if argv is None: < argv = sys.argv 757c755 < self.progName = os.path.basename(argv[0]) --- > #self.progName = os.path.basename(argv[0]) 769c767 < options, args = getopt.getopt(argv[1:], 'hHvq', --- > options, args = getopt.getopt(argv, 'hHvq', You may notice I have commented out the self.progName line. This variable is not used anywhere in the module so I guess it could be removed. To keep it then conditional check on argv would have to remain and be moved after the self.progName line. I hope this makes sense, and it's my first post so go easy on me ;) Thanks, -John K ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
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 discussion. > > I believe the context API design has gotten totally out of hand. > Regardless of the merits of the "with" approach to HTML generation > (which I personally believe to be an abomination), The example is tempting because it's easy to follow. I agree actually doing it in real code would almost certainly be nuts :) > I don't see why the > standard library should support every possible use case with a > custom-made decorator. Let the author of that tag library provide the > decorator. The HTML tag was just an example. The underlying idea is being able to easily create a re-usable object that can be passed to multiple with statements (potentially nested within each other or within distinct threads). Without the __context__ method, the naive version of such an object looks like: class reusable(object): def __init__(self, factory): self.factory = factory factory() # Check the factory works at definition time def __enter__(self): current = self.current = factory() return current.__enter__() def __exit__(self, *exc_info): return self.current.__exit__(*exc_info) The downside of this over the __context__ method is that it is neither nesting nor thread-safe. Because the storage is on the object rather than in the execution frame, sharing such objects between threads or using one for nested with statements will break (as self.current gets overwritten). > 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 example that I know of where > __context__ doesn't return self is the decimal module. It would also prevent threading.Condition from using its underlying lock object as the managed context. The real problem I have with removing __context__() is that it pushes the burden of handling thread-safety and nesting-safety issues onto the developers of context managers without giving them any additional tools beyond threading.locals(). This was the problem Jason brought up for decimal.Context that lead to the introduction of __context__ in the first place. Without the __context__() method, *users* of the with statement will be forced to create a new object with __enter__()/__exit__() methods every time, either by invoking a method (whose name will vary from object to object, depending on the whim of the designer) or by calling a factory function (which is likely to be created either as a zero-argument lambda returning an object with enter/exit methods, or else by using PEP 309's partial function). So if you see a with statement with a bare variable name as the context expression, it will probably be wrong, unless: a) the implementor of that type provided thread-safety and nesting-safety; or b) the object is known to be neither thread-safe nor nesting-safe The synchronisation objects in threading being examples of category a, file objects being examples of category b. In this scenario, generator contexts defined using @contextfactory should always be invoked directly in the context expression, as attempting to cache them in order to be reused won't work (you would need to put them in a zero-argument lambda and call it in the context expression, so that you get a new generator object each time). Documenting all of the thread-safety and nesting-safety issues and how to deal with them would be a serious pain. I consider it much easier to provide the __context__() method and explain how to use that as the one obvious way to deal with such problems. Then only implementors need to care about it - from a user's point of view, you just provide a context expression that resolves to a context manager, and everything works as intended, including being able to cache that expression in a local variable and use it multiple times. (That last point obviously not applying to context managers like files that leave themselves in an unusable state after __exit__, and don't restore themselves to a usable state in __enter__). Essentially, I don't think dropping __context__ would gain us anything - the complexity associated with it is real, and including that method in the API let's us deal with that complexity in one place, once and for all. Removing the method from the statement definition just pushes the documentation burden out to all of the context managers where it matters (like decimal.Context, the documentation for which would get stuck with trying to explain why you have to call a method in order to get a usable conte
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
> 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 to the decimal lovers. You could call it push() or stack() or establish() or some other non-descript word. Or manage() or manager(). The method name can't involve the word "context" since the object is already called a context. But that still leaves an infinite number of possible names. :-) > If you can solve the naming issue for these use cases (and I notice you > punted on that issue by calling it "some_method"), then +1 on removing > __context__. Otherwise, I'm -0; we're just fixing one > documentation/explanation problem (that only people writing contexts will > care about) by creating others (that will affect the people *using* > contexts too). To the contrary. Even if we never come up with a perfect name for decimal.Context.some_method(), then we've still solved a documentation problem for 9 out of 10 cases where __context__ is just empty ballast. But I'm sure that if we require that folks come up with a name, they will. 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 __context__ (or __with__, as it was originally called) was invented, were by far its happiest times. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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 with a naked > '*'. To the first, I said "The rationale for this is pretty obvious.". To > the second, I asked, and still ask, "Why?". 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 to enforce that calling convention on their users. This seems to me to go against the "consenting adults" principle. - A function's author believes they might change the signature in the future to accept new positional arguments, and they will want to put them before the args that they declare keyword-only. Both of these motivations seem fairly weak. Certainly, neither seems to warrant a significant change to function definition syntax. But perhaps there are other use cases that I'm failing to consider. Anyone know of any? -Edward ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
[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 __context__ returns self and those whose __context__ returns some other object. In all of the latter cases, the original object doesn't have __enter__ or __exit__ methods, so using it in the "reduced-with-statement" will be an immediate run-time error. Writing a method that returns the correct type of object with the correct behavior (thread-safe, or nesting, or whatever is required by that specific object) is no harder whether the method name is __context__ or not. > The real problem I have with removing __context__() is that it pushes the > burden of handling thread-safety and nesting-safety issues onto the developers > of context managers without giving them any additional tools beyond > threading.locals(). This was the problem Jason brought up for decimal.Context > that lead to the introduction of __context__ in the first place. Again, I don't see how writing the thread-safe version is easier when the method is called __context__. > Without the __context__() method, *users* of the with statement will be forced > to create a new object with __enter__()/__exit__() methods every time, You seem to be missing the evidence that 9 out of 10 objects currently have a __context__ that returns self. In all those cases the user of the with-statement won't have to make any changes at all compared to code that works with 2.5a2. > either > by invoking a method (whose name will vary from object to object, depending on > the whim of the designer) or by calling a factory function (which is likely to > be created either as a zero-argument lambda returning an object with > enter/exit methods, or else by using PEP 309's partial function). Having the name being different in each situation may actually be an advantage -- it will give an additional clue as to what is happening, and it will let us design different APIs for use in a with-statement (just like dicts have iterkeys() and iteritems()). > So if you see a with statement with a bare variable name as the context > expression, it will probably be wrong, unless: > a) the implementor of that type provided thread-safety and nesting-safety; > or > b) the object is known to be neither thread-safe nor nesting-safe > > The synchronisation objects in threading being examples of category a, file > objects being examples of category b. In this scenario, generator contexts > defined using @contextfactory should always be invoked directly in the context > expression, as attempting to cache them in order to be reused won't work (you > would need to put them in a zero-argument lambda and call it in the context > expression, so that you get a new generator object each time). Now we get to the crux of the matter. When I recommend that people write with foo.some_method(): you are worried that if they need two separate blocks like that, they are tempted to write x = foo.some_method() with x: with x: But there's an obvious solution for that: make sure that the object returned by foo.some_method() can only be used once. The second "with x" will raise an exception explaining what went wrong. (We could even rig it so that nesting the second "with x" inside the first one will produce a different error message.) So the "with foo.some_method()" idiom is the only one that works, and that is just as thread-safe and nesting-resilient as is writing __context__() today. 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(). > Essentially, I don't think dropping __context__ would gain us anything - the > complexity associated with it is real, and including that method in the API > let's us deal with that complexity in one place, once and for all. It's not real in 9 out of 10 current cases. (And the Condition variable could easily be restored to its previous case where it had its own __enter__ and __exit__ methods that called the corresponding methods of the underlying lock. The code currently in svn is merely an optimization.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] More on contextlib - adding back a contextmanager decorator
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, you've moved me to at least +0 for dropping __context__. I have only one object myself that has a non-self __context__, and it doesn't have a __call__, so none of my code breaks beyond the need to add parentheses in a few places. ;) As for decimal contexts, I'm thinking maybe we should have a decimal.using(ctx=None, **kw) function, where ctx defaults to the current decimal context, and the keyword arguments are used to make a modified copy, seems like a reasonable best way to implement the behavior that __context__ was added for. And then all of the existing special machinery can go away and be replaced with a single @contextfactory. (I think we should stick with @contextfactory as the decorator name, btw, even if we go back to calling __enter__/__exit__ things context managers.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] methods on the bytes object
"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 assume you mean unicode strings which
> > contain data, and not some new "character string" type?
>
> 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.
> > I know I must
> > have missed some conversation. I was under the impression that in Py3k:
> >
> > Python 1.x and 2.x str -> mutable bytes object
>
> No. Python 1.x and 2.x str -> str, Python 2.x unicode -> str
> In addition, a bytes type is added, so that
> Python 1.x and 2.x str -> bytes
>
> The problem is that the current string type is used both to represent
> bytes and characters. Current applications of str need to be studied,
> and converted appropriately, depending on whether they use
> "str-as-bytes" or "str-as-characters". The "default", in some
> sense of that word, is that str applications are assumed to operate
> on character strings; this is achieved by making string literals
> objects of the character string type.
Certainly it is the case that right now strings are used to contain
'text' and 'bytes' (binary data, encodings of text, etc.). The problem
is in the ambiguity of Python 2.x str containing text where it should
only contain bytes. But in 3.x, there will continue to be an ambiguity,
as strings will still contain bytes and text (parsing literals, see the
somewhat recent argument over bytes.encode('base64'), etc.). We've not
removed the problem, only changed it from being contained in non-unicode
strings to be contained in unicode strings (which are 2 or 4 times larger
than their non-unicode counterparts).
Within the remainder of this email, there are two things I'm trying to
accomplish:
1. preserve the Python 2.x string type
2. make the bytes object more pallatable regardless of #1
The current plan (from what I understand) is to make all string literals
equivalent to their Python 2.x u-prefixed equivalents, and to leave
u-prefixed literals alone (unless the u prefix is being removed?). I
won't argue because I think it is a great idea.
I do, however, believe that the Python 2.x string type is very useful
from a data parsing/processing perspective. Look how successful and
effective it has been so far in the history of Python. In order to make
the bytes object be as effective in 3.x, one would need to add basically
all of the Python 2.x string methods to it (having some mechanism to use
slices of bytes objects as dictionary keys (if data[:4] in handler: ...
-> if tuple(data[:4]) in handler: ... ?) would also be nice). Of course,
these implementations, ultimately, already exist with Python 2.x
immutable strings.
So, what to do? Rename Python 2.x str to bytes. The name of the type
now confers the idea that it should contain bytes, not strings. If
bytes literals are deemed necessary (I think they would be nice, but not
required), have b"..." as the bytes literal. Not having a literal, I
think, will generally reduce the number of people who try to put text
into bytes.
Ahh, but what about the originally thought-about bytes object? That
mutable, file-like, string-like thing which is essentially array.array
('B', ...) with some other useful stuff? Those are certainly still
useful, but not so much from a data parsing/processing perspective, as
much as a mutable in-memory buffer (not the Python built-in buffer
object, but a C-equivalent char* = (char*)malloc(...); ). I currently
use mmaps and array objects for that (to limited success), but a new
type in the collections module (perhaps mutablebytes?) which offers such
functionality would be perfectly reasonable (as would moving the
immutable bytes object if it lacked a literal; or even switch to
bytes/frozenbytes).
If we were to go to the mutable/immutable bytes object pair, we could
still give mutable bytes .read()/.write(), slice assignment, etc., and
even offer an integer view mechanism (for iteration, assignment, etc.).
Heck, we could do the same thing for the immutable type (except for
.write(), assignment, etc.), and essentially replace
cStringIO(initializer) (of course mutable bytes effectively replace
cStringIO()).
> > and that there would be some magical argument
> > to pass to the file or open open(fn, 'rb', magical_parameter).read() ->
> > bytes.
>
> I think the precise details of that are still unclear. But yes,
> the plan is to have two file modes: one that returns character
> strings (type 'str') and one that returns type 'bytes'.
Here's a thought; require 'b' or 't' as arguments to open/file, the 't'
also having an optional encoding argument (which defaults to the current
default encoding). If one
Re: [Python-Dev] methods on the bytes object
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 first. Neither array.fromstring nor struct.unpack will
produce/consume type 'str' in Python 3; both will operate on the
bytes type. So fromstring should probably be renamed frombytes.
> Certainly it is the case that right now strings are used to contain
> 'text' and 'bytes' (binary data, encodings of text, etc.). The problem
> is in the ambiguity of Python 2.x str containing text where it should
> only contain bytes. But in 3.x, there will continue to be an ambiguity,
> as strings will still contain bytes and text (parsing literals, see the
> somewhat recent argument over bytes.encode('base64'), etc.).
No. In Python 3, type 'str' cannot be interpreted to contain bytes.
Operations that expect bytes and are given type 'str', and no encoding,
should raise TypeError.
> We've not removed the problem, only changed it from being contained
> in non-unicode
> strings to be contained in unicode strings (which are 2 or 4 times larger
> than their non-unicode counterparts).
We have removed the problem.
> Within the remainder of this email, there are two things I'm trying to
> accomplish:
> 1. preserve the Python 2.x string type
I would expect that people try that. I'm -1.
> 2. make the bytes object more pallatable regardless of #1
This might be good, but we have to be careful to not create a type
that people would casually use to represent text.
> I do, however, believe that the Python 2.x string type is very useful
> from a data parsing/processing perspective.
You have to explain your terminology somewhat better here: What
applications do you have in mind when you are talking about
"parsing/processing"? To me, "parsing" always means "text", never
"raw bytes". I'm thinking of the Chomsky classification of grammars,
EBNF, etc. when I hear "parsing".
> Look how successful and
> effective it has been so far in the history of Python. In order to make
> the bytes object be as effective in 3.x, one would need to add basically
> all of the Python 2.x string methods to it
The precondition of this clause is misguided: the bytes type doesn't
need to be as effective, since the string type is as effective in 2.3,
so you can do all parsing based on strings.
> (having some mechanism to use
> slices of bytes objects as dictionary keys (if data[:4] in handler: ...
> -> if tuple(data[:4]) in handler: ... ?) would also be nice).
You can't use the bytes type as a dictionary key because it is
immutable. Use the string type instead.
> So, what to do? Rename Python 2.x str to bytes. The name of the type
> now confers the idea that it should contain bytes, not strings.
It seems that you want an immutable version of the bytes type. As I
don't understand what "parsing" is, I cannot see the need for it;
I think having two different bytes types is confusing.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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, anymore. > > 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 with a naked > '*'. To the first, I said "The rationale for this is pretty obvious.". To > the second, I asked, and still ask, "Why?". 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 these cases, you don't *want* name, age to be passed in a positional way. How else would you formulate that if this syntax wasn't available? (I know it is possible to formulate it elsehow, I'm asking what notation you would use) > 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? I see an important use case for k=0 functions, and k=1 methods (where the only positional argument is self). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
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 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 left. Now I understand, though. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Tkinter lockups.
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 when > the first call was succesful, but it doesn't remember failure cases. I > don't know enough about Tcl/Tk or Tkinter how this is best handled, but > it would be mightily convenient if it were. ;-) I've created a bugreport > on it, and I hope someone with Tkinter knowledge can step in and fix it. > (It looks like SF auto-assigned it to Martin already, hmm.) I have now reported the underlying Tk bug at http://sourceforge.net/tracker/index.php?func=detail&aid=1479587&group_id=12997&atid=112997 and worked around it in _tkinter.c. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
