On c.l.py someone asked about forcing a tailend interactive shell from
within the program. Try Melhase proposed:
import os
if __name__ == '__main__':
discrepancy = True
if discrepancy:
os.environ['PYTHONINSPECT'] = "why yes, i'd like that"
but observed that it doesn't work because the environment variable is only
checked at program start.
This change to Modules/main.c makes the above work:
% cvs diff main.c
Index: main.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/main.c,v
retrieving revision 1.77
diff -c -r1.77 main.c
*** main.c 30 Mar 2003 17:09:58 -0000 1.77
--- main.c 27 Jun 2003 11:50:42 -0000
***************
*** 418,423 ****
--- 418,428 ----
filename != NULL, &cf) != 0;
}
+ /* also check at the end in case the program set PYTHONINSPECT */
+ if (!saw_inspect_flag &&
+ (p = Py_GETENV("PYTHONINSPECT")) && *p != '\0')
+ inspect = 1;
+
if (inspect && stdin_is_interactive &&
(filename != NULL || command != NULL))
/* XXX */
I can't see that it would affect the functioning of any programs other than
those which set PYTHONINSPECT now. (But why would they do that and what's
the likelihood such programs exist?)
Any chance this could be squeezed in? It seems rather elegant:
try:
something which fails
except:
os.environ["PYTHONINSPECT"] = 1
raise
(I know we're at beta1, and the programmer could re-run with -i. But
still...)
Skip
I've just tagged and branched Python 2.3b2, so the trunk is now open for
checkins again. Of course the r23b2-branch is closed so we can spin the
release.
-Barry
>>> Anthony Baxter wrote
>
> Attempting a cvs up at the moment is failing with:
>
> cvs server: failed to create lock directory for `/cvsroot/python/python/dist/
src' (/cvsroot/python/python/dist/src/#cvs.lock): Permission denied
> cvs server: failed to obtain dir lock in repository `/cvsroot/python/python/d
ist/src'
> cvs [server aborted]: read lock failed - giving up
After quite some time of not working, it of course started working 2 minutes
after I sent this email. *sigh*
cvs: less bad than the alternatives...
Anthony
Python has everything else, but it doesn't have a nameserver lookup class.
I propose creating a library which will perform the equivalent of the "dig" or "nslookup" commands. My own application is using it to query a DNS for mx records as a preface to using smtplib. (Perhaps this should be added to smtplib?)
dnslib? diglib? domainlib? nslookuplib?
Possibly:
servers=dnsquery([nameserver],[name],[type],[class])
i.e.
>>>from dnslib import dnsquery
>>>d=dnsquery(,"google.com","mx")
>>>print d
['10 smtp1.google.com','20 smtp2.google.com']
It would have the usual options, etc.
Is this a good idea or do I need to spend more time in the oven?
(or worse, it already exists and I overlooked it?)
[Kevin Jacobs, privately]
> I'll vote for applying patch #751916, which fixes some memory leaks in the
> timeout code, and allows the SSL code to recover from keyboard interrupts.
> I have several applications that work with 2.2.x that do not currently with
> the 2.3 CVS due to this issue.
Can someone review this and apply if it's okay? From this description
I'd be okay with including it, but I have no time to review.
--Guido van Rossum (home page: http://www.python.org/~guido/)
There's a long standing, hard to reproduce bug report about httplib --
666219 -- that got me looking at the socket timeout code today. The
most basic question I have is: Do we expect the timeout code to work
with the httplib module? The original timeoutsocket module uses httplib
as an example of its use.
I ask because some simple httplib tests aren't working as expected with
timeouts turned on. I'm also curious because the socket documentation
says you shouldn't mix timeouts and makefile(), and httplib uses
makefile().
When I do have a small timeout and a slow server, I sometimes see an
error like this:
Traceback (most recent call last):
File "/tmp/foo.py", line 14, in ?
f = urllib.urlopen(url)
File "/home/jeremy/src/python/dist/src/Lib/urllib.py", line 76, in
urlopen
return opener.open(url)
File "/home/jeremy/src/python/dist/src/Lib/urllib.py", line 181, in
open
return getattr(self, name)(url)
File "/home/jeremy/src/python/dist/src/Lib/urllib.py", line 297, in
open_http
h.endheaders()
File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 710, in
endheaders
self._send_output()
File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 595, in
_send_output
self.send(msg)
File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 562, in
send
self.connect()
File "/home/jeremy/src/python/dist/src/Lib/httplib.py", line 546, in
connect
raise socket.error, msg
IOError: [Errno socket error] (114, 'Operation already in progress')
The socketmodule code is specifically looking for an EINPROGRESS return
from connect(), but I'm getting an EALREADY. These are related but
distinct errors on Linux.
I'm not sure if I should file a bug report for code or documentation or
if it should somehow be obvious that I'm doing something wrong.
Jeremy
I've just submitted to SF #757624 the third implementation of the
SRE changes.
Unlike the other implementations, this one doesn't recurse at all, and
doesn't change the meaning of the opcodes in the engine. Indeed, the
original logic is mostly unchanged, and the recursion has been removed
by a code reorganization. Most of the magic is done using "jumps", and
"context saving" inside SRE_MATCH. It's even possible to reenable the
recursive scheme by enabling the USE_RECURSION macro.
Besides the regression tests, I have tested this using Fredrik's
suggestion, with a 4MB XML file and xmllib/tokenize modules. There
was a very small slow down (i.e. about 37.4s in old implementation
vs. 38.0s in new implementation).
Bugs previously mentioned are also fixed in this implementation.
This implementation also includes the protection against zero-width
match in greedy expressions ("(?=a)*", "a"). Even if this implementation
doesn't get into 2.3, I was thinking about backporting this specific fix
to 2.3. Unfortunately, this would need an additional local variable in
SRE_MATCH of the current implementation, and I'm afraid to reduce the
recursion limit even more by introducing it.
Additionally, after a quick look over perl's regex engine, I also have
some ideas for matching optimization in SRE, but I'll wait a little bit
before fiddling with it.
--
Gustavo Niemeyer
http://niemeyer.net
I'd like to introduce a small enhancement to Tkinter, but would like
some idea of whether it has a chance of acceptance before proceeding too
far (e.g. before checking in a patch).
The primary change is to add a "name" argument to the Variable.__init__,
bringing it in line with other Tkinter classes. The justification is to
allow users to create new Tkinter variables that point to existing tcl
variables (e.g. somewhat similar to nametowidget). In some cases this
may be more convenient than using setvar and getvar.
Subtlety:
- A new __eq__ method makes two Tkinter variables compare as equal if
they are of the same type and have the same tcl name.
If it is not overreaching, I'd like to introduce a few related changes
at the same time.
1) add a "value" argument to Variable.__init__. This would set the
initial value of the new variable -- a feature I've long wanted.
Subtlety:
- If "name" is specified and the variable already exists, then "value"
is ignored (so the existing value is preserved). One could always ignore
"value" if the variable exists, but I suspect users would prefer to
assume that newly created auto-named variables will be properly
initialized to some default value.
2) add a new function "nametovariable" which returns a Tkinter variable
given the name of a tcl variable.
Subtleties:
- To return a Tkinter variable of the correct class, this requires
changing the auto naming scheme for Tkinter variables. I propose
PY_class_num where class is the appropriate subclass of Variable. This
is the only change that has any danger of affecting existing code.
- If the name does not meet the criteria, a StringVar is returned
- If the tcl variable does not exist, an exception is raised. This is
not necesarry, but prevents accidentaly creating a new variable when one
was trying to point to an existing one.
If this is too much of a change for 2.3b1 but might be considered for
later releases, I'd like some idea if I should submit any of it now or
wait or what.
-- Russell
In the next chapter of the war for Persistent.__cmp__, I found a bug in
ExtensionClass's handling of __coerce__. Here's a paired-down testcase.
from ExtensionClass import Base
class Foo(Base):
def __coerce__(self, other): return None
class Bar(Base):
def __coerce__(self, other): return NotImplemented
f = Foo(); assert 0 < f
-> SystemError: error return without exception set
b = Bar(); assert 0 < b
-> SystemError: new style getargs format but argument is not a tuple
As far as I know (and the PSL docs say) these are the only valid ways to
give up __coerce__. Guido has in the past provided a hint to the latter
error:
http://mail.zope.org/pipermail/zope-coders/2002-January/000594.html
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
