Re: [Python-Dev] Py2.6 ideas
Sorry, forgot to include the output of doctest_driver.py --help. Here it is: -Edward Usage: doctest_driver.py [options] NAME ... Options: --version show program's version number and exit -h, --helpshow this help message and exit Actions (default=check): --check Verify the output of the doctest examples in the given files. -u, --updateUpdate the expected output for new or out-of- date doctest examples in the given files. In particular, find every example whose actual output does not match its expected output; and replace its expected output with its actual output. You will be asked to verify the changes before they are written back to the file; be sure to check them over carefully, to ensure that you don't accidentally create broken test cases. --debug Verify the output of the doctest examples in the given files. If any example fails, then enter the python debugger. Reporting: -v, --verbose Increase verbosity. -q, --quiet Decrease verbosity. -d, --udiff Display test failures using unified diffs. --cdiff Display test failures using context diffs. --ndiff Display test failures using ndiffs. Output Comparison: --ellipsis Allow "..." to be used for ellipsis in the expected output. --normalize_whitespace Ignore whitespace differences between the expected output and the actual output. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.6 ideas
On Feb 15, 2007, at 2:59 PM, Raymond Hettinger wrote: > * Enhance doctest with a method that computes updated doctest > results. If the > only change I make to a matrix suite is to add commas to long > numbers in the > matrix repr(), then it would be nice to have an automated way to > update the > matrix output on all the other test cases in the module. A while back I wrote up a command-line doctest driver that does this and more [1]. The output of "doctest_driver.py --help" is below; note in particular the --update and --debug options. I also wrote an emacs mode [2] that has support for running doctest & putting the output (^c^c) or diffs (^c^d) in an output buffer; and for updating the output of selected examples (^c^r). I never really got around to doing official releases for either (although doctest-mode.el is part of the python-mode.el package). I could move some of this code into the doctest mode, if it seems appropriate; or I could just go ahead and release the driver and publicize it. -Edward [1] http://nltk.svn.sourceforge.net/viewvc/nltk/trunk/nltk/nltk_lite/ test/doctest_driver.py?view=markup [2] http://python-mode.svn.sourceforge.net/viewvc/*checkout*/python- mode/trunk/python-mode/doctest-mode.el?revision=424 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python Library Reference top page too long
Martin v. Löwis wrote:
> Edward C. Jones wrote:
>> The contents page for the Python Library Reference
>> ("http://docs.python.org/dev/lib/lib.html";) has become much too long.
>
> I disagree. It serves my purposes very well: I usually search in the
> page for a keywork I think should be there. If the page was broken
> into multiple pages, that would break.
Perhaps the lib page could have a portal-like index like the one Edward
Jones suggested at the top, followed the full list w/ descriptions?
That way, it would be easier to pick out a module with a fairly quick
glance, but searching the page would still work.
-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Prevalence of low-level memory abuse?
Tim Peters wrote: > If extension modules in real life prove as sloppy as Python's > front end, we'll have to revert the objimpl.h + pymem.h part of this > patch. Note that no problems will show up in a debug build (all > calls still go thru obmalloc then). Problems will show up only in a > release build, most likely segfaults. Could the debug build's macros for PyMem/PyObject_new/free be modified to check for mismatches? Or would storing information about which method was used to allocate each pointer be too expensive? Perhaps a special build could be used to check for mismatches? -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Must objects with __enter__/__exit__ also supply __context__?
Nick Coghlan wrote: > OTOH, if the two protocols are made orthogonal, then it's clear that the > manager is always the original object with the __context__ method. Then the > three cases are: > > - a pure context manager (only provides __context__) > - a pure managed context (only provides __enter__/__exit__) > - a managed context which can be its own context manager (provides all > three) +1 on keeping the two protocols orthogonal and using this terminology (context manager/managed context). -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Josiah Carlson wrote: > [...] get str.join to support objects which > implement the buffer interface as one of the items in the sequence? > > Something like: > > y = 'hello world' > buf1 = buffer(y, 0, 5) > buf2 = buffer(y, 6) > print ''.join([buf1, buf2]) > > should print "helloworld" This is incompatible with the recent proposal making str.join automatically str-ify its arguments. i.e.: ''.join(['a', 12, 'b']) -> 'a12b'. I don't feel strongly about either proposal, I just thought I'd point out that they're mutually exclusive. -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Crazy idea for str.join
Nick Coghlan wrote: > Edward Loper wrote: >> This is incompatible with the recent proposal making str.join >> automatically str-ify its arguments. i.e.: >> >>''.join(['a', 12, 'b']) -> 'a12b'. >> >> I don't feel strongly about either proposal, I just thought I'd point >> out that they're mutually exclusive. > > Doesn't accepting objects that support the buffer interface come for > free with stringification? (My understanding of buffer objects is fairly > sketchy, so I may be missing something here. . .) It's quite possible that I'm the one who was confused.. I just tried it out with string-based buffers, and for that case at least it works fine. I don't know about other buffers. So actually these two proposals might be compatible after all. -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
Martin v. Löwis wrote: > One reason I see is to have keyword-only functions, i.e. with no > positional arguments at all: > > def make_person(*, name, age, phone, location): > pass > > which also works for methods: > > def make_person(self, *, name, age, phone, location): > pass > > In 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? But is it necessary to syntactically *enforce* that the arguments be used as keywords? I.e., why not just document that the arguments should be used as keyword arguments, and leave it at that. If users insist on using them positionally, then their code will be less readable, and might break if you decide to change the order of the parameters, but we're all consenting adults. (And if you *do* believe that the parameters should all be passed as keywords, then I don't see any reason why you'd ever be motivated to change their order.) -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
Fred L. Drake, Jr. wrote: > On Sunday 30 April 2006 22:50, Edward Loper wrote: > > I see two possible reasons: > > Another use case, observed in the wild: > >- An library function is written to take an arbitrary number of > positional arguments using *args syntax. The library is released, > presumably creating dependencies on the specific signature of the > function. In a subsequent version of the function, the function is > determined to need additional information. The only way to add an > argument is to use a keyword for which there is no positional > equivalent. This falls under the "first subproposal" from Terry's email: > 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 was trying to come up with use cases for the "second subproposal." -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
Fredrik Lundh wrote: >> And again, why would you *make* me, the user-programmer, type >> >> make_person(name=namex, age=agex, phone=phonex, location = locationx) >> #instead of >> make_person(namex,agex,phonex,locationx) >> ? > > because a good API designer needs to consider more than just the current > release. I believe that it's quite possible that you're right, but I think more concrete answers would be helpful. I.e., how does having parameters that are syntactically keyword-only (as opposed to being simply documented as keyword-only) help you develop an API over time? I gave some thought to it, and can come up with a few answers. In all cases, assume a user BadUser, who decided to use positional arguments for arguments that you documented as keyword-only. - You would like to deprecate, and eventually remove, an argument to a function. For people who read your documentation, and use keyword args for the keyword-only arguments, their code will break in a clean, easy-to-understand way. But BadUser's code may break in strange hard-to-understand ways, since their positional arguments will get mapped to the wrong function arguments. - You would like to add a new parameter to a function, and would like to make that new parameter available for positional argument use. So you'd like to add it before all the keyword arguments. But this will break BadUser's code. - You have a function that takes one argument and a bunch of keyword options, and would like to change it to accept *varargs instead of just one argument. But this will break BadUser's code. I think that this kind of *concrete* use-case provides a better justification for the feature than just saying "it will help API design." As someone who has had a fair amount of experience designing & maintaining APIs over time, perhaps you'd care to contribute some more use cases where you think having syntactically keyword-only arguments would help? -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] signature object issues (to discuss while I am out of contact)
Brett Cannon wrote: > The second question is whether it is worth providing a function that > will either figure out if a tuple and dict representing arguments > would work in calling the function. Some have even suggested a > function that returns the actual bindings if the call were to occur. > Personally I don't see a huge use for either, but even less for the > latter version. If people have a legit use case for either please > speak up, otherwise I am tempted to keep the object simple. One use case that comes to mind is a type-checking decorator (or precondition-checking decorator, etc): @precondition(lambda x,y: x>y) @precondition(lambda y,z: y>z) def foo(x, y, z): ... where precondition is something like: def precondition(test): def add_precondition(func): def f(*args, **kwargs): bindings = func.__signature__.bindings(args, kwargs) if not test(**bindings): raise ValueError, 'Precontition not met' func(*args, **kwargs) return f return add_precondition -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
On May 6, 2006, at 2:40 AM, Nick Coghlan wrote:
> Remember, the idea with portable path information is to *never*
> store os.sep
> and os.extsep anywhere in the internal data - those should only be
> added when
> needed to produce strings to pass to OS-specific functions or to
> display to users.
If one of the path segments contained a path-splitting character,
should it automatically get quoted? (Is that even possible on all
platforms?) E.g., what would the following give me on windows?
str(Path('a', 'b\\c'))
-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101 Update
Talin wrote:
> Braces can be escaped using a backslash:
>
> "My name is {0} :-\{\}".format('Fred')
>
> Which would produce:
>
> "My name is Fred :-{}"
Do backslashes also need to be backslashed then? If not, then what is
the translation of this:?
r'abc\{%s\}' % 'x'
I guess the only sensible translation if backslashes aren't backslashed
would be:
r'abc\\{{0}\\}'.format('x')
But the parsing of that format string seems fairly unintuitive to me.
If backslashes do need to be backslashed, then that fact needs to be
mentioned.
-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3101 Update
Steven Bethard wrote:
> On 5/7/06, Edward Loper <[EMAIL PROTECTED]> wrote:
>> Talin wrote:
>>> Braces can be escaped using a backslash:
>>>
>>> "My name is {0} :-\{\}".format('Fred')
>>>
>>> Which would produce:
>>>
>>> "My name is Fred :-{}"
>> Do backslashes also need to be backslashed then? If not, then what is
>> the translation of this:?
>>
>> r'abc\{%s\}' % 'x'
>
> I believe the proposal is taking advantage of the fact that '\{' is
> not interpreted as an escape sequence -- it is interpreted as a
> literal backslash followed by an open brace:
Yes, I knew that fact, but it's not related to my question. The basic
issue is, that if you have a quote character ('\\'), then you usually
need to be able to quote that quote character ('') in at least some
contexts.
So I'll try again with a different example. I'll avoid using raw
strings, just because doing so seems to have confused a couple people
about what my question is about. Let's say I have a program now that
contains the following line:
print 'Foo\\%s' % x
And I'd like to translate that to use str.format. How do I do it? If I
just replace %s with {0} then I get:
print 'Foo\\{0}'.format(x)
but this will presumably raise an exception, since the '\\{' (which is
identical to '\{') gets treated as a quoted brace, and the '}' is
unmatched. If it were possible to backslash backslashes, then I could do:
print 'Foo{1}' % x
(which can also be spelled r'Foo\\{1}' -- i.e., the string now contains
two backslash characters).
But I haven't seen any mention of backslashing backslashes so far.
-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] total ordering.
Guido van Rossum wrote: > On 5/11/06, Vladimir 'Yu' Stepanov <[EMAIL PROTECTED]> wrote: >> If for Python-3000 similar it will be shown concerning types >> str(), int(), complex() and so on, and the type of exceptions >> will strongly vary, it will make problematic redefinition of >> behavior of function of sorting. > > Not really. We'll just document that sort() should only be used on a > list of objects that implement a total ordering. [...] It might be useful in some cases to have a keyword argument to sort/sorted that says to ignore exceptions arising from comparing elements, and leaves the ordering of non-comparable values undefined. -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] correction of a bug
draconux wrote:
>
> Hello all ,
> string.lstrip("source/old_prog","source/") return "ld_prog" instead of
> "old_prog"
You are misunderstanding what the second argument to lstrip does. It is
interpreted as a list of characters; and lstrip will remove the maximal
prefix of the string that consists of these characters. E.g.:
>>> 'aaabbbcccaax'.lstrip('abc')
'x'
The first character in your string that is not one of the characters
's', 'o', 'u', 'r', 'c', 'e', or '/' is 'l', so it strips all characters
up to that one.
-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] xturtle.py a replacement for turtle.py(!?) ATTENTION PLEASE!
Gregor Lingl wrote: > Yes,, and I have some ideas in this respect, but mainly a prioncipal > question. I read about > using doctest and unittest, but how does one devise > automatic test suites for graphical output. In the end it depends on how > it looks like. There are a few options here.. Two that come to mind are: - Check the output -- e.g., run a demo, and then use Tkinter.Canvas to write its output to postscript, and then check the contents of that postscript file against a known correct file. - Monkey-patching -- replace specific classes (e.g., ScrolledCanvas?) with new testing classes that simply intercept drawing primitives, rather than displaying graphics. Then check that the right drawing primitives (lines, circles, etc) are generated in the right order. The former may be more robust, but requires that you have a display surface available. With the former approach, you may also run into some problems with different postscript files being generated on different systems (esp. with respect to font sizes -- I seem to remember that using negative font sizes might help there?). -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Event loops, PyOS_InputHook, and Tkinter
As I understand it, you want to improve the performance of interactively run plot commands by queuing up all the plot sub-commands, and then drawing them all at once. Hooking into a python event loop certainly isn't the only way to do this. Perhaps you could consider the following approach: - The plot event loop is in a separate thread, accepting messages from the interactive thread. - These messages can contain plot commands; and they can also contain two new commands: - suspend -- stop plotting, and start saving commands in a queue. - resume -- execute all commands in the queue (with whatever increased efficiency tricks you're using) Then you can either just add functions to generate these messages, and call them at appropriate places; or set PyOS_InputHook to wrap each interactive call with a suspend/resume pair. But note that putting an event loop in a separate thread will be problematic if you want any of the events to generate callbacks into user code -- this could cause all sorts of nasty race-conditions! Using a separate thread for an event loop only seems practical to me if the event loop will never call back into user code (or if you're willing to put the burden on your users of making sure everything is thread safe). -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Metaclass problem in the "with" statement semantics in PEP 343
Michael Chermside wrote: >> Right now, we say that there's one rule for all *normal* attributes >> and >> methods, and a slightly different rule for all double-underbar >> methods. Guido responded: > But it's not normal vs. __xyzzy__. A specific set of slots (including > next, but excluding things like __doc__) get special treatment. The > rest don't. All I'm saying is that I don't care to give __context__ > this special treatment. Perhaps we should officially document that the effect on special methods of overriding a class attribute with an instance attribute is undefined, for some given set of attributes? (I would say all double-underbar methods, but it sounds like the list needs to also include next().) Otherwise, it seems like people might write code that relies on the current behavior, which will then break if we eg turn __context__ into a slot. (It sounds like you want to reserve the right to change this.) Well, of course, people may rely on the current behavior anyway, but at least they'll have been warned. :) -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Short-circuiting iterators
> I had an idea this morning for a simple extension to Python's iterator
> protocol that would allow the user to force an iterator to raise
> StopIteration on the next call to next(). My thought was to add a new
> method to iterators called stop().
There's no need to change the iterator protocol for your example use
case; you could just define a simple iterator-wrapper:
class InterruptableIterator:
stopped = False
def __init__(self, iter):
self.iter = iter()
def next(self):
if stopped:
raise StopIteration('iterator stopped.')
return self.iter.next()
def stop(self):
self.stopped = True
And then just replace:
> generator = some_generator_function()
with:
generator = InterruptableIterator(some_generator_function())
-Edward
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Doc-SIG] that library reference, again
Robey Pointer wrote: On 30 Dec 2005, at 18:29, Christopher Armstrong wrote: >> [epydoc] is not really even "good enough" for a lot of my usage without some >> seriously evil hacks. The fundamental design decision of epydoc to >> import code, plus some other design decisions on the way it figures >> types and identity seriously hinder its utility. [...] As a side note, I've done a significant amount of work on a newer version of epydoc that supports both inspection & source-code parsing (and can merge the info from both sources, if they're available). Hopefully this new version will address some of these concerns (and some other issues I've heard raised). But I haven't had time to work on it in a while -- I need to concentrate on getting my phd thesis done. If anyone is interested in working on this new version, just let me know. :) -Edward ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
