A couple of other threads started me to thinking that there are a couple
of things missing from our warnings framework.
Many languages have pragmas that allow you turn warnings on and off in
code. For instance, I should be able to put a pragma at the top of a
module that uses string functions to say: "I know that this module
doesn't adhere to the latest Python conventions. Please don't warn me
about it." I should also be able to put a declaration that says: "I'm
really paranoid about shadowing globals and builtins. Please warn me
when I do that."
Batch and visual linters could also use the declarations to customize
their behaviors.
And of course we have a stack of other features that could use pragmas:
* type signatures
* Unicode syntax declarations
* external object model language binding hints
* ...
A case could be made that warning pragmas could use a totally different
syntax from "user-defined" pragmas. I don't care much.
Paul
I executed cvs update today (removing the sourceforge machines from
.ssh/known_hosts worked fine for me, btw) followed by a configure and a make
clean. The last step failed with this output:
...
make[1]: Entering directory `/home/beluga/skip/src/python/dist/src/Modules'
Makefile.pre.in:20: *** missing separator. Stop.
make[1]: Leaving directory `/home/beluga/skip/src/python/dist/src/Modules'
make: [clean] Error 2 (ignored)
I found the following at line 20 of Modules/Makefile.pre.in:
@SET_CXX@
I then tried a cvs annotate on that file but saw that line 20 had been there
since rev 1.60 (16-Dec-99). I then checked the top-level Makefile.in
thinking something must have changed in the clean target recently, but cvs
annotate shows no recent changes there either:
1.1 (guido 24-Dec-93): clean: localclean
1.1 (guido 24-Dec-93): -for i in $(SUBDIRS); do \
1.74 (guido 19-May-98): if test -d $$i; then \
1.24 (guido 20-Jun-96): (echo making clean in subdirectory $$i; cd $$i; \
1.4 (guido 01-Aug-94): if test -f Makefile; \
1.4 (guido 01-Aug-94): then $(MAKE) clean; \
1.4 (guido 01-Aug-94): else $(MAKE) -f Makefile.*in clean; \
1.4 (guido 01-Aug-94): fi); \
1.74 (guido 19-May-98): else true; fi; \
1.1 (guido 24-Dec-93): done
Make distclean succeeded so I tried the following:
make distclean
./configure
make clean
but the last step still failed. Any idea why make clean is now failing (for
me)? Can anyone else reproduce this problem?
Skip
unicodeobject.c contains this code:
PyErr_Format(PyExc_ValueError,
"unsupported format character '%c' (0x%x) "
"at index %i",
c, c, fmt -1 - PyUnicode_AS_UNICODE(uformat));
c is a Py_UNICODE; applying C's %c to it only takes the lowest 8 bits,
so '%\u3000' % 1 results in an error message containing "'\000'
(0x3000)". Is this worth fixing? I'd say no, since the hex value is
more useful for Unicode strings anyway. (I still wanted to mention
this little buglet, since I just touched this bit of code.)
--amk
I began writing the fabled fancy setup script described in PEP 229,
and then realized there was duplication going on here. The code in
setup.py would need to know what libraries, #defines, &c., are needed
by each module in order to check if they're needed and set them. But
if Modules/Setup can be used to override setup.py's behaviour, then
much of this information would need to be in that file, too; the
details of compiling a module are in two places.
Possibilities:
1) Setup contains fully-loaded module descriptions, and the setup
script drops unneeded bits. For example, the socket module
requires -lnsl on some platforms. The Setup file would contain
"socket socketmodule.c -lnsl" on all platforms, and setup.py would
check for an nsl library and only use if it's there.
This seems dodgy to me; what if -ldbm is needed on one platform and
-lndbm on another?
2) Drop setup completely and just maintain setup.py, with some
different overriding mechanism. This is more radical. Adding a
new module is then not just a matter of editing a simple text file;
you'd have to modify setup.py, making it more like maintaining an
autoconf script.
Remember, the underlying goal of PEP 229 is to have the out-of-the-box
Python installation you get from "./configure;make" contain many more
useful modules; right now you wouldn't get zlib, syslog, resource, any
of the DBM modules, PyExpat, &c. I'm not wedded to using Distutils to
get that, but think that's the only practical way; witness the hackery
required to get the DB module automatically compiled.
You can also wave your hands in the direction of packagers such as
ActiveState or Red Hat, and say "let them make to compile everything".
But this problem actually inconveniences *me*, since I always build
Python myself and have to extensively edit Setup, so I'd like to fix
the problem.
Thoughts?
--amk
On Fri, 15 Dec 2000 08:16:37 -0800, Paul Prescod <paulp(a)ActiveState.com> wrote:
> Python is the only one I know of that implicitly shadows without
> requiring some form of declaration.
Perl and Scheme permit implicit shadowing too.
--
Moshe Zadka <sig(a)zadka.site.co.il>
This is a signature anti-virus.
Please stop the spread of signature viruses!
Thomas Wouters <thomas(a)xs4all.net> writes:
> On Fri, Dec 15, 2000 at 04:03:04AM -0800, Neil Schemenauer wrote:
> > On Fri, Dec 15, 2000 at 11:17:08AM -0500, Barry A. Warsaw wrote:
> > > I'm not sure I agree with that view either, but mostly because there
> > > is a non-GPL replacement for parts of the readline API:
> > >
> > > http://www.cstr.ed.ac.uk/downloads/editline.html
> >
> > It doesn't work with the current readline module. It is much
> > smaller than readline and works just as well in my experience.
> > Would there be any interest in including a copy with the standard
> > distribution? The license is quite nice (X11 type).
>
> Definately +1 from here. Readline reminds me of the cold war, for
> some reason. (Actually, multiple reasons ;) I don't have time to do
> it myself, unfortunately, or I would. (Looking at editline has been
> on my TODO list for a while... :P)
It wouldn't be particularly hard to rewrite editline in Python (we
have termios & the terminal handling functions in curses - and even
ioctl if we get really keen).
I've been hacking on my own Python line reader on and off for a while;
it's still pretty buggy, but if you're feeling brave you could look at:
http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.0.0.tar.gz
To try it out, unpack it, cd into the ./pyrl directory and try:
>>> import foo # sorry
>>> foo.test_loop()
It sort of imitates the Python command prompt, except that it doesn't
actually execute the code you type.
You need a recent _cursesmodule.c for it to work.
Cheers,
M.
--
41. Some programming languages manage to absorb change, but
withstand progress.
-- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html
I remember earlier discussion on the Python 2.1 release schedule, and
never managed to comment on those.
I believe that Python contributors and maintainers did an enourmous
job in releasing Python 2, which took quite some time from everybody's
life. I think it is unrealistic to expect the same amount of
commitment for the next release, especially if that release appears
just a few months after the previous release (that is, one month from
now).
So I'd like to ask the release manager to take that into
account. I'm not quite sure what kind of action I expect; possible
alternatives are:
- declare 2.1 a pure bug fix release only; with a minimal set of new
features. In particular, don't push for completion of PEPs; everybody
should then accept that most features that are currently discussed
will appear in Python 2.2.
- move the schedule for Python 2.1 back (or is it forward?) by, say, a
few month. This will people give some time to do the things that did
not get the right amount of attention during 2.0 release, and will
still allow to work on new and interesting features.
Just my 0.02EUR,
Martin
Andrew Kuchling <akuchlin(a)mems-exchange.org> writes:
> [CC'ing Thomas Gellekum <tg(a)melaten.rwth-aachen.de>]
>
> On Wed, Dec 13, 2000 at 01:24:01AM -0500, Fred L. Drake, Jr. wrote:
> > Would it be reasonable to add panel support as a second extension
> >module? Is there really a need for them to be in the same module,
> >since the panel library is a separate library?
>
> Quite possibly, though the patch isn't structured that way. The panel
> module will need access to the type object for the curses window
> object, so it'll have to ensure that _curses is already imported, but
> that's no problem.
You mean as separate modules like
import curses
import panel
? Hm. A panel object is associated with a window object, so it's
created from a window method. This means you'd need to add
window.new_panel() to PyCursesWindow_Methods[] and
curses.update_panels(), curses.panel_above() and curses.panel_below()
(or whatever they're called after we're through discussing this ;-))
to PyCurses_Methods[].
Also, the curses.panel_{above,below}() wrappers need access to the
list_of_panels via find_po().
> Thomas, do you feel capable of implementing it as a separate module,
> or should I work on it?
It's probably finished a lot sooner when you do it; OTOH, it would be
fun to try it. Let's carry this discussion a bit further.
> Probably a _cursesmodule.h header will have
> to be created to make various definitions available to external
> users of the basic objects in _curses.
That's easy. The problem is that we want to extend those basic objects
in _curses.
> (Bonus: this means that the
> menu and form libraries, if they ever get wrapped, can be separate
> modules, too.)
Sure, if we solve this for panel, the others are a SMOP. :-)
tg
I'm maybe about three quarters on the way with writing PEP 230 -- far
enough along to be asking for comments. Get it from CVS or go to:
http://python.sourceforge.net/peps/pep-0230.html
A prototype implementation in Python is included in the PEP; I think
this shows that the implementation is not too complex (Paul Prescod's
fear about my proposal).
This is pretty close to what I proposed earlier (Nov 5), except that I
have added warning category classes (inspired by Paul's proposal).
This class also serves as the exception to be raised when warnings are
turned into exceptions.
Do I need to include a discussion of Paul's counter-proposal and why I
rejected it?
--Guido van Rossum (home page: http://www.python.org/~guido/)
After perusing David Ascher's proposal, several versions of his
patches, and hundreds of email exchanged on this subject (almost all
of this dated April or May of 1998), I've produced a reasonably
semblance of PEP 207. Get it from CVS or here on the web:
http://python.sourceforge.net/peps/pep-0207.html
I'd like to hear your comments, praise, and criticisms!
The PEP still needs work; in particular, the minority point of view
back then (that comparisons should return only Boolean results) is not
adequately represented (but I *did* work in a reference to tabnanny,
to ensure Tim's support :-).
I'd like to work on a patch next, but I think there will be
interference with Neil's coercion patch. I'm not sure how to resolve
that yet; maybe I'll just wait until Neil's coercion patch is checked
in.
--Guido van Rossum (home page: http://www.python.org/~guido/)