headers
guido | 12 Jul 1999 21:03
Favicon

re group self-reference weird behavior (PR#2)

Full_Name: Guido van Rossum
Version: 1.5.2
OS: Unix, Windows
Submission from: eric.cnri.reston.va.us (132.151.1.38)

Try the following:

import re
re.search("((.)\\1+)","a")

This isn't proper syntax (you shouldn't reference a group
inside itself), but it seems to hang -- in fact it takes
several minutes to execute.

Possibly it runs out of some resource on its path to infinite
recursion and then backtracks?
Permalink | Reply | 0 comments |
headers
skip | 12 Jul 1999 21:36

rfc822.Message.readheaders bug (PR#3)

Full_Name: Skip Montanaro
Version: 1.5.2
OS: Unix
Submission from: eric.cnri.reston.va.us (132.151.1.38)
Submitted by: guido

[resubmitted by GvR]

I think there's a bug in rfc822.Message.readheaders (v. 1.5.2).  In that
method it splits a header into name and value and assigns to a dict:

    headerseen = self.isheader(line)
    if headerseen:
	# It's a legal header line, save it.
	list.append(line)
	self.dict[headerseen] = string.strip(line[len(headerseen)+2:])
	continue

See the "len(headerseen)+2" as the starting index of the slice?  I think
that should be "len(headerseen)+1".  It appears the code assumes there is a
space following the colon that separates the name and the value.  My reading 
of the relevant section of RFC 822 suggests that a single colon is the only
separator between a field name and its value:

     3.2.  HEADER FIELD DEFINITIONS

          These rules show a field meta-syntax, without regard for the
     particular  type  or internal syntax.  Their purpose is to permit
     detection of fields; also, they present to  higher-level  parsers
     an image of each field as fitting on one line.
(Continue reading)

Permalink | Reply | 0 comments |
headers
MHammond | 12 Jul 1999 21:38
Picon
Favicon

pdb can only step when at botframe (PR#4)

Full_Name: Mark Hammond
Version: 1.5.2
OS: Windows
Submission from: eric.cnri.reston.va.us (132.151.1.38)
Submitted by: guido

[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
(Continue reading)

Permalink | Reply | 0 comments |
headers
guido | 12 Jul 1999 21:55
Favicon

tuple repetition not safe (PR#6)

Full_Name: Guido van Rossum
Version: 1.5.2
OS: Unix
Submission from: eric.cnri.reston.va.us (132.151.1.38)

Found this on the news:

> This is on a Sun machine:
>
> >>> x=sys.maxint*[1,]
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> MemoryError
> >>> x=sys.maxint*(1,)
> Segmentation Fault (core dumped)
Permalink | Reply | 0 comments |
headers
da | 13 Jul 1999 00:53

comparisons of recursive objects (PR#7)

Full_Name: David Ascher
Version: 1.5.2
OS: NT4SP3
Submission from: (NULL) (209.117.142.20)

When comparing (e.g.) two lists that contain themselves, the interpreter can
dump core. For
example: 

  a = []; a.append(a)
  b = []; b.append(b)
  cmp(a, b)
Permalink | Reply | 0 comments |
headers
da | 13 Jul 1999 00:53

comparisons of recursive objects (PR#8)

Full_Name: David Ascher
Version: 1.5.2
OS: NT4SP3
Submission from: (NULL) (209.117.142.20)

When comparing (e.g.) two lists that contain themselves, the interpreter can
dump core. For
example: 

  a = []; a.append(a)
  b = []; b.append(b)
  cmp(a, b)
Permalink | Reply | 0 comments |
headers
guido | 13 Jul 1999 01:19
Picon
Picon

test jitterbug (PR#9)

Full_Name: GvR
Version: 1.5.2
OS: NT4SP3
Submission from: (NULL) (209.117.142.20)

testing
Permalink | Reply | 0 comments |
headers
bwarsaw | 13 Jul 1999 01:21
Favicon

testing jitterbug through cgi (PR#10)

Full_Name: Barry Warsaw
Version: 1.5.2+
OS: Solaris
Submission from: anthem.cnri.reston.va.us (132.151.1.40)

testing jitterbug through cgi
Permalink | Reply | 0 comments |
headers
tim_one | 13 Jul 1999 02:47
Picon

Traceback off by a line under -x (PR#11)

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust154.tnt3.bos1.da.uu.net (153.34.162.154)

Running

    python -x whatever.py

skips over the first line of the script (that's a feature), but Python also then
considers the second line of the file to be line number 1.  This causes
tracebacks in the main script to display a wrong (off by one) line.

Already fixed in the CVS version.
Permalink | Reply | 0 comments |
headers
tim_one | 13 Jul 1999 02:53
Picon

PyThreadState_Delete: invalid tstate (PR#12)

Full_Name: Tim Peters
Version: 1.5.2
OS: Win95
Submission from: 1cust154.tnt3.bos1.da.uu.net (153.34.162.154)

People running a threaded Python under 1.5.2 (& earlier) sometimes reported
random

    Fatal Python error: PyThreadState_Delete: invalid tstate

deaths, and more rarely memory faults.  These typically occurred under heavy
load, with a high rate of thread death.

This is probably fixed in the CVS version:  some small timing holes were
discovered "by eye" in the code that cleans up thread states, and got fixed.  A
test case written to provoke the problem ran without incident on several systems
after the fix.
Permalink | Reply | 0 comments |

Gmane