Mailman 3 June 2002 - Python-Dev

Xrange and Slices
by Raymond Hettinger 12 Jul '02

12 Jul '02

Wild idea of the day: Merge the code for xrange() into slice(). So that old code will work, make the word 'xrange' a synonym for 'slice' >>> x = xrange(0,10,2) >>> s = slice(0,10,2) >>> [m for m in dir(x) if m not in dir(s)] ['__getitem__', '__iter__', '__len__'] >>> [m for m in dir(s) if m not in dir(x)] ['__cmp__', 'start', 'step', 'stop'] Raymond Hettinger 'regnitteh dnomyar'[::-1]

7 15

PEP 292, Simpler String Substitutions
by Damien Morton 12 Jul '02

12 Jul '02

"I'd rather have a notation that's less error-prone than a better way to check for errors. (Not that PyChecker 2 isn't a great idea. :-)" Percent notation "%s" notation already exists for strings. Backquote notation is already in python, though I think, little used. The $ notation reeks of obscure languages such as perl and shell. Why not simply add backquote notation to python strings. I read in a recent email from Timbot, I think, that the backquote notation was originally intended for string interpolation too. name = "guido" country = "the netherlands" height = 1.92 "`name` is from `country`".sub() -> "guido is from the netherlands" "`name.capitalize()` is from `country`" -> "Guido is from the netherlands" "`name` is %`height`4.1f meters tall".sub() -> "guido is 1.9 meters tall" "`name.capitalize()` can jump `height*1.7` meters".sub() -> "guido can jump 3.264 meters" You could probably also compile these interpolation strings as well. Another thought: One of the main problems with the "%(name)4.2f" notation is that the format comes after the variable name. Is easy to forget adding the actual format specifier in after the name. Why not alter the notation to allow the format specifier to come before the name part. "%4.2f(height)" I think would be a whole lot less error prone, and would allow for the format specifier to default to "s" where omitted. "%(height)" is also less error prone, though it is ambiguous in the current scheme. Ive seen a nice class which evaluates the string used in the name part. class itpl: def __getitem__(self, s): return eval(s, globals())

14 29

New Subscriber Introduction
by Brett Cannon 12 Jul '02

12 Jul '02

Uh, I realize this is a little late, but I didn't thoroughly read the intro email for the list and so I didn't realize this was requested into lalo sent his email. Anyway, better late then never. So my name is Brett Cannon. I am a recent graduate of the philosophy program here at UC Berkeley. I am taking a year off from school (and apparently employment =P) while I apply to grad school in hopes of persuing as masters or doctorate in CS. I also hope to discover an area of CS that I love above all else during this year so that I can stop jumping between different areas of programming (I have the slight issue of wnating to be the best that I can be at everything and this jumping around is not helping with that =). I discovered Python in Fall 2000. Was trying to choose a language to use to teach myself OOP before I took my first CS course here at Cal. Have been using Python pretty exclusively since except for CS coursework; Python spoiled me and didn't help when I had to use Scheme, Lisp, or Java in my classes. The only grumblings anyone has heard out of me as yet on this list is over my Python implementation of strptime. I do plan to stay on this list, though, even after this is resolved and be as involved as I can on the list (which is going to be limited until I get off my rear and really dive into the C source). -Brett C.

5 10

Indexing builtin sequences with objects which supply __int__
by Todd Miller 12 Jul '02

12 Jul '02

There has been some recent interest in the Numeric/numarray community for using array objects as indices for builtin sequences. I know this has come up before, but to make myself clear, the basic idea is to make the following work: class C: def __int__(self): return 5 object = C() l = "Another feature..." print l[object] "h" Are there any plans (or interest) for developing Python in this direction? Todd

6 16

deprecating string module?
by Skip Montanaro 11 Jul '02

11 Jul '02

I know this has been discussed before. In light of the recent PEP8 update: Avoid the use of the string module; instead use string methods. These are always much faster and share the same API with unicode strings. I thought I'd raise it again. How about deprecating the string module? In the past, this has presented two major problems. First, its near ubiquity in Python programs before the availability of string methods. Second, the presence of a few useful data objects (digits, uppercase, etc). The first problem can be solved by extending the deprecation time suitably (two years/four releases?) I think the second problem can be solved by adding those data objects to either sys or locale(preferably the latter). string.letters and its subsets are locale-dependent. In relevant locales I presume string.punctuation and string.whitespace would also be different than their common ASCII elements. Finally, I'd amend the above PEP8 admontion something like Avoid the use of the string module unless backward-compatibility with versions earlier than Python 2.0 is important; instead use string methods. These are always much faster and share the same API with unicode strings. Skip

22 118

Re: *Simpler* string substitutions
by Moore, Paul 11 Jul '02

11 Jul '02

Some points on the current thread, in no particular order... 1. While I agree that "$" is better known as an interpolation character than "%", it shouldn't be forgotten that "%" is the interpolation character in DOS/Windows shells. Some recent examples which showed "%" used ("The sum of %x and %y is %(x+y)") looked entirely natural to me (I use Windows more than Unix) - in fact, more so than "$"!! 2. The internationalisation issue is clearly important. However, it has very different characteristics insofar as the template string is (of necessity) handled at runtime, so issues of compilation and security become relevant. I'm no I18N expert, so I can't comment on details, but I *do* think it's worth separating out the I18N issues from the "simple interpolation" issues... 3. I feel that the existing % formatting operator cannot realistically be removed. Tidying up some of its warts may be possible, and even sensible, but there's too much code using it (and as was pointed out, template strings may not event be stored in code files) to make major changes. 4. Access to variables is also problematic. Without compile-time support, access to nested scopes is impossible (AIUI). But on the other hand, a scheme with subtle limitations such as lack of such access may not realistically count as "simple"... 5. (Personal opinion here!) I believe that formatting specifiers so not belong in a "simple" scheme - leave them for the "advanced" verion (the existing % operator). On the other hand, I feel that expression interpolation, within limits, *is* suitable. It's the user's responsibility not to go overboard, though... Sorry for butting into an already long thread. I hope the summary is useful, at least... Paul.

4 3

List comprehensions
by Gerald S. Williams 05 Jul '02

05 Jul '02

Has anyone summarized the list comprehension design discussions? I found references to "lots of discussion" about it but haven't yet found the discussions themselves. I don't want to rehash any old discussions, but I came across a surprise recently while converting constructs like "map(lambda x:x+1,x)" and just wanted to see the rationale behind not creating a local scope for list comprehension variables. Any pointer would be appreciated. Thanks, -Jerry

6 7

Infinie recursion in Pickle
by Oleg Broytmann 02 Jul '02

02 Jul '02

Hello! Nobody noted the message in c.l.py, let me try to ask you before I file a bug report on SF. ----- Forwarded message from Oleg Broytmann <phd(a)phd.pp.ru> ----- On Thu, Jun 27, 2002 at 08:45:16PM +0000, Bengt Richter wrote: > > Recently Python (one program that I am dbugging) started to crash. > >FreeBSD kills it with "Bus error", Linux with "Segmentation fault". > > > > I think the program crashed in the cPickle.dump(file, 1) I replaced cPikle.dump with pikle.dump and got infinite rcursion. The traceback is below. What's that? Are there any limits that an object to be pikled must follow? Could it be a tree with loops? (I am pretty sure it could - I used the program for years, and data structures was not changed much). Could it be "new" Python class? (Recently I changed one of my classes to be derived from builtin list instead of UserList). Well (or not so well), the traceback: Traceback (most recent call last): File "/home/phd/lib/bookmarks_db/check_urls.py", line 158, in ? run() File "/home/phd/lib/bookmarks_db/check_urls.py", line 145, in run storage.store(root_folder) File "bkmk_stpickle.py", line 23, in store File "/usr/local/lib/python2.2/pickle.py", line 973, in dump Pickler(file, bin).dump(object) File "/usr/local/lib/python2.2/pickle.py", line 115, in dump self.save(object) File "/usr/local/lib/python2.2/pickle.py", line 219, in save self.save_reduce(callable, arg_tup, state) File "/usr/local/lib/python2.2/pickle.py", line 245, in save_reduce save(arg_tup) File "/usr/local/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/local/lib/python2.2/pickle.py", line 374, in save_tuple save(element) File "/usr/local/lib/python2.2/pickle.py", line 225, in save f(self, object) [about 1000 lines skipped - they are all the same] File "/usr/local/lib/python2.2/pickle.py", line 498, in save_inst save(stuff) File "/usr/local/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/local/lib/python2.2/pickle.py", line 447, in save_dict save(value) File "/usr/local/lib/python2.2/pickle.py", line 219, in save self.save_reduce(callable, arg_tup, state) File "/usr/local/lib/python2.2/pickle.py", line 245, in save_reduce save(arg_tup) File "/usr/local/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/local/lib/python2.2/pickle.py", line 374, in save_tuple save(element) File "/usr/local/lib/python2.2/pickle.py", line 225, in save f(self, object) File "/usr/local/lib/python2.2/pickle.py", line 414, in save_list save(element) File "/usr/local/lib/python2.2/pickle.py", line 143, in save pid = self.persistent_id(object) RuntimeError: maximum recursion depth exceeded ----- End forwarded message ----- Oleg. -- Oleg Broytmann http://phd.pp.ru/ phd(a)phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

10 19

Silent Deprecation Candidate -- buffer()
by Raymond Hettinger 01 Jul '02

01 Jul '02

As far as I can tell, buffer() is one of the least used or known about Python tools. What do you guys think about this as a candidate for silent deprecation (moving out of the primary documentation)? Raymond Hettinger

6 12

posixmodule.c diffs for working forkpty() and openpty() under Solaris 2.8
by Lance Ellinghaus 30 Jun '02

30 Jun '02

Hello everyone! I had to get forkpty() and openpty() working under Solaris 2.8 for a project I am working on. Here are the diffs to the 2.2.1 source file. Please let me know if anyone has any problems with this! Lance Ellinghaus ===== -- Lance Ellinghaus __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com *** Python-2.2.1/Modules/posixmodule.c Tue Mar 12 16:38:31 2002 --- Python-2.2.1.new/Modules/posixmodule.c Tue May 21 01:16:29 2002 *************** *** 1904,1910 **** } #endif ! #if defined(HAVE_OPENPTY) || defined(HAVE_FORKPTY) #ifdef HAVE_PTY_H #include <pty.h> #else --- 1904,1913 ---- } #endif ! #if defined(HAVE_OPENPTY) || defined(HAVE_FORKPTY) || defined(sun) ! #ifdef sun ! #include <sys/stropts.h> ! #endif #ifdef HAVE_PTY_H #include <pty.h> #else *************** *** 1914,1920 **** #endif /* HAVE_PTY_H */ #endif /* defined(HAVE_OPENPTY) || defined(HAVE_FORKPTY) */ ! #if defined(HAVE_OPENPTY) || defined(HAVE__GETPTY) static char posix_openpty__doc__[] = "openpty() -> (master_fd, slave_fd)\n\ Open a pseudo-terminal, returning open fd's for both master and slave end.\n"; --- 1917,1923 ---- #endif /* HAVE_PTY_H */ #endif /* defined(HAVE_OPENPTY) || defined(HAVE_FORKPTY) */ ! #if defined(HAVE_OPENPTY) || defined(HAVE__GETPTY) || defined(sun) static char posix_openpty__doc__[] = "openpty() -> (master_fd, slave_fd)\n\ Open a pseudo-terminal, returning open fd's for both master and slave end.\n"; *************** *** 1925,1932 **** int master_fd, slave_fd; #ifndef HAVE_OPENPTY char * slave_name; #endif ! if (!PyArg_ParseTuple(args, ":openpty")) return NULL; --- 1928,1941 ---- int master_fd, slave_fd; #ifndef HAVE_OPENPTY char * slave_name; + #ifdef sun + void *sig_saved; #endif ! #endif ! #if !defined(HAVE_OPENPTY) && !defined(HAVE__GETPTY) && defined(sun) ! extern char *ptsname(); ! #endif ! if (!PyArg_ParseTuple(args, ":openpty")) return NULL; *************** *** 1933,1939 **** #ifdef HAVE_OPENPTY if (openpty(&master_fd, &slave_fd, NULL, NULL, NULL) != 0) return posix_error(); ! #else slave_name = _getpty(&master_fd, O_RDWR, 0666, 0); if (slave_name == NULL) return posix_error(); --- 1942,1948 ---- #ifdef HAVE_OPENPTY if (openpty(&master_fd, &slave_fd, NULL, NULL, NULL) != 0) return posix_error(); ! #elif HAVE__GETPTY slave_name = _getpty(&master_fd, O_RDWR, 0666, 0); if (slave_name == NULL) return posix_error(); *************** *** 1941,1946 **** --- 1950,1966 ---- slave_fd = open(slave_name, O_RDWR); if (slave_fd < 0) return posix_error(); + #else + master_fd = open("/dev/ptmx", O_RDWR|O_NOCTTY); /* open master */ + sig_saved = signal(SIGCHLD, SIG_DFL); + grantpt(master_fd); /* change permission of slave */ + unlockpt(master_fd); /* unlock slave */ + signal(SIGCHLD,sig_saved); + slave_name = ptsname(master_fd); /* get name of slave */ + slave_fd = open(slave_name, O_RDWR); /* open slave */ + ioctl(slave_fd, I_PUSH, "ptem"); /* push ptem */ + ioctl(slave_fd, I_PUSH, "ldterm"); /* push ldterm*/ + ioctl(slave_fd, I_PUSH, "ttcompat"); /* push ttcompat*/ #endif /* HAVE_OPENPTY */ return Py_BuildValue("(ii)", master_fd, slave_fd); *************** *** 1948,1954 **** } #endif /* defined(HAVE_OPENPTY) || defined(HAVE__GETPTY) */ ! #ifdef HAVE_FORKPTY static char posix_forkpty__doc__[] = "forkpty() -> (pid, master_fd)\n\ Fork a new process with a new pseudo-terminal as controlling tty.\n\n\ --- 1968,1974 ---- } #endif /* defined(HAVE_OPENPTY) || defined(HAVE__GETPTY) */ ! #if defined(HAVE_FORKPTY) || defined(sun) static char posix_forkpty__doc__[] = "forkpty() -> (pid, master_fd)\n\ Fork a new process with a new pseudo-terminal as controlling tty.\n\n\ *************** *** 1959,1968 **** --- 1979,2067 ---- posix_forkpty(PyObject *self, PyObject *args) { int master_fd, pid; + #if defined(sun) + int slave; + char * slave_name; + void *sig_saved; + int fd; + #endif if (!PyArg_ParseTuple(args, ":forkpty")) return NULL; + #if defined(sun) + master_fd = open("/dev/ptmx", O_RDWR|O_NOCTTY); /* open master */ + sig_saved = signal(SIGCHLD, SIG_DFL); + grantpt(master_fd); /* change permission of slave */ + unlockpt(master_fd); /* unlock slave */ + signal(SIGCHLD,sig_saved); + slave_name = ptsname(master_fd); /* get name of slave */ + slave = open(slave_name, O_RDWR); /* open slave */ + ioctl(slave, I_PUSH, "ptem"); /* push ptem */ + ioctl(slave, I_PUSH, "ldterm"); /* push ldterm*/ + ioctl(slave, I_PUSH, "ttcompat"); /* push ttcompat*/ + if (master_fd < 0 || slave < 0) + { + return posix_error(); + } + switch (pid = fork()) { + case -1: + return posix_error(); + case 0: + /* First disconnect from the old controlling tty. */ + #ifdef TIOCNOTTY + fd = open("/dev/tty", O_RDWR | O_NOCTTY); + if (fd >= 0) { + (void) ioctl(fd, TIOCNOTTY, NULL); + close(fd); + } + #endif /* TIOCNOTTY */ + if (setsid() < 0) + return posix_error(); + + /* + * Verify that we are successfully disconnected from the controlling + * tty. + */ + fd = open("/dev/tty", O_RDWR | O_NOCTTY); + if (fd >= 0) { + return posix_error(); + close(fd); + } + /* Make it our controlling tty. */ + #ifdef TIOCSCTTY + if (ioctl(slave, TIOCSCTTY, NULL) < 0) + return posix_error(); + #endif /* TIOCSCTTY */ + fd = open(slave_name, O_RDWR); + if (fd < 0) { + return posix_error(); + } else { + close(fd); + } + /* Verify that we now have a controlling tty. */ + fd = open("/dev/tty", O_WRONLY); + if (fd < 0) + return posix_error(); + else { + close(fd); + } + (void) close(master_fd); + (void) dup2(slave, 0); + (void) dup2(slave, 1); + (void) dup2(slave, 2); + if (slave > 2) + (void) close(slave); + pid = 0; + break; + defautlt: + /* + * parent + */ + (void) close(slave); + } + #else pid = forkpty(&master_fd, NULL, NULL, NULL); + #endif if (pid == -1) return posix_error(); if (pid == 0) *************** *** 5607,5616 **** #ifdef HAVE_FORK {"fork", posix_fork, METH_VARARGS, posix_fork__doc__}, #endif /* HAVE_FORK */ ! #if defined(HAVE_OPENPTY) || defined(HAVE__GETPTY) {"openpty", posix_openpty, METH_VARARGS, posix_openpty__doc__}, #endif /* HAVE_OPENPTY || HAVE__GETPTY */ ! #ifdef HAVE_FORKPTY {"forkpty", posix_forkpty, METH_VARARGS, posix_forkpty__doc__}, #endif /* HAVE_FORKPTY */ #ifdef HAVE_GETEGID --- 5706,5715 ---- #ifdef HAVE_FORK {"fork", posix_fork, METH_VARARGS, posix_fork__doc__}, #endif /* HAVE_FORK */ ! #if defined(HAVE_OPENPTY) || defined(HAVE__GETPTY) || defined(sun) {"openpty", posix_openpty, METH_VARARGS, posix_openpty__doc__}, #endif /* HAVE_OPENPTY || HAVE__GETPTY */ ! #if defined(HAVE_FORKPTY) || defined(sun) {"forkpty", posix_forkpty, METH_VARARGS, posix_forkpty__doc__}, #endif /* HAVE_FORKPTY */ #ifdef HAVE_GETEGID

3 4