Python-Dev December 2000

python-dev@python.org

50 participants
96 discussions

by Paul Prescod

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

20 years, 3 months

Did something change in Makefile.in or Modules/Makefile.pre.in?

by Skip Montanaro

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

20 years, 3 months

Use of %c and Py_UNICODE

by A.M. Kuchling

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

20 years, 3 months

What to do about PEP 229?

by A.M. Kuchling

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

20 years, 3 months

Re: [Python-Dev] new draft of PEP 227

by Moshe Zadka

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!

20 years, 3 months

Re: (offtopic) RE: [Python-Dev] Python 2.0 license and GPL

by Michael Hudson

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

20 years, 3 months

PEP 226

by Martin v. Loewis

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

20 years, 3 months

Re: [Python-Dev] Splitting up _cursesmodule

by Thomas Gellekum

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

20 years, 3 months

Warning Framework (PEP 230)

by Guido van Rossum

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/)

20 years, 3 months

PEP 207 -- Rich Comparisons

by Guido van Rossum

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/)

20 years, 3 months

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev December 2000