Re: [Python-3000] Python-3000 Digest, Vol 10, Issue 40

Guido van Rossum wrote: > Ok, so be it. Let this be a pronouncement -- the only stdlib reorg > we're doing will be (a) deleting silly old stuff; (b) rename modules > that don't conform to the current module/package naming convention, > like StringIO, cPickle or UserDict. I feel strongly that

Re: [Python-3000] Refactoring Tool

Guido van Rossum" <[EMAIL PROTECTED]> wrote: > As a symptom, I received very few > responses to my announcement of a refactoring tool; the ones that I > got were more of a theoretical nature "maybe look at this alternative > approach" rather than "how can I help" or "here's a refactoring I > wrote

Re: [Python-3000] Warning about future-unsafe usage patterns in Python 2.x e.g. dict.keys().sort()

Brian Quinlan said: > It is my understanding that, in Python 3000, certain functions and > methods that currently return lists will return some sort of view type > (e.g. dict.values()) or an iterator (e.g. zip). So certain usage > patterns will no longer be supported e.g. d.keys().sort(). I us

[Python-3000] Debuggers was Re: What do do about IDLE?

Talin <[EMAIL PROTECTED]> wrote: > I don't think we really need an IDE, but a debugger that is > at least able to show source code, call stack, and local > variables in a window would be extremely useful. > > So my thought is this: How hard would it be to make > a curses-based debugger? For

[Python-3000] Debugger was Re: What do do about IDLE?

___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com

[Python-3000] Use of bracketing characters: (), {}, []

There is a current thread on notations for sets and dicts. A more general question is: How should the precious pairs of bracketing characters,(), {}, and [] be used? Currently, parentheses are used for grouping, function calls and tuples. Curly brackets are used for dictionaries and, perhaps in

Re: [Python-3000] Cleaning up argument list parsing

For fancy argument list parsing, perhaps we need a module "argsparse" that is analogous to "optparse". ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/op

[Python-3000] A wish: build C, C++, FORTRAN library wrapping into Python.

Wild wish. Many C, C++ and FORTRAN libraries have been wrapped in Python. These wrapped libraries are used a lot. A number of programs have been written that automate this process, the standard example being SWIG. These programs have become fairly mature. How much of the wrapping process can b

[Python-3000] After 2.6 should be 3.0

Wild idea. I would like to see Python 3.0 before the turn of the next millennium. I suggest that Python 2.6 be devoted to implementing some of the backward compatible changes for Python 3.0. In particular, do the long-overdue reorganization of the libraries. After 2.6 should be 3.0. ___

[Python-3000] Special object to return from functions that return only None

Wild idea. When I was a newbie, I repeatedly make the mistake of writing alist = alist.sort() I suggest a singleton object "UseForbidden" ("Py_UseForbidden" in C). "UseForbidden" can be used only to return from a function. Any other attempt to use "UseForbidden" raises an exception. The incorr

[Python-3000] Use Py_CLEAR only

Wild idea: Can Py_CLEAR completely replace Py_DECREF and Py_XDECREF? ___ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-a

[Python-3000] Is reference counting still needed?

Wild Idea: From Section 1.10 of "Extending and Embedding": Maybe some day a sufficiently portable automatic garbage collector will be available for C. Until then, we'll have to live with reference counts. Any hope such a GC will be available before Python 3.0? _

Re: [Python-3000] pre-PEP: Things that Will Not Change in Python 3.0

Greg Ewing <[EMAIL PROTECTED]> wrote > Subject: Re: [Python-3000] pre-PEP: Things that Will Not Change in > Python 3.0 > To: python-3000@python.org > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Guido van Rossum wrote: > >> Good idea. Ma

Re: [Python-3000] Best Practices essays

Adam DePrince wrote: > Now, as for your example m * [ n * [0]], I would exclude it from a best > practices document. If your goal is to create a two dimensional array > of numbers, it doesn't work. The first part, n* [0] is right, you are > creating a list of n zeros, and when you say l[x]=y yo

[Python-3000] Best Practices essays

"Brett Cannon" <[EMAIL PROTECTED]> wrote: > Right. I am really starting to think that having a group of Best > Practices essays that discuss common Python idioms might be handy. > Part tutorial, part advanced usage, they would provide a way for > people to have a place to go to find out expec