[ python-Bugs-1166660 ] The readline module can cause python to segfault

[SourceForge.net]

Bugs item #110, was opened at 2005-03-19 21:48
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=110&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-30 11:10

Message:
Logged In: YES 
user_id=6656

While it does seem a bit odd to call the completer function in the thread 
that calls set_completer and not the thread that calls readline(), I don't 
immediately see how this is leading to segfaults.  Do you?

Anyway, I can reproduce the problem, so if your fix fixes it, I'll check it in 
(irrespective of fixing segfaults, it just makes more sense).

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-29 13:10

Message:
Logged In: YES 
user_id=6656

Unless there's some reason to suspect they share a common
cause (and, I don't see one) a second report is more
appropriate.

Also, if you understand what's going on, you can explain
there :)

--

Comment By: Yariv Ido (dcoder)
Date: 2005-03-28 23:33

Message:
Logged In: YES 
user_id=326689

I haven't (Completely forgot about it, after finding the
main one...). Should I post a seperate bug report, or will
this one do?

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

--

Comment By: Yariv Ido (dcoder)
Date: 2005-03-19 23:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=110&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1166660 ] The readline module can cause python to segfault

[SourceForge.net]

Bugs item #110, was opened at 2005-03-19 21:48
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=110&group_id=5470

Category: Threads
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-30 12:23

Message:
Logged In: YES 
user_id=6656

Oh, forget all that, I had a leap in understanding about the existing threads-
vs-hooks code in readline.c: it's all insane nonsense.

I used the PyGILState_* API rather than your suggestion, on the very faint 
chance that an embedder might be calling readline() directly and thus have 
not be setting _PyOS_ReadlineTState.

I also fixed the 'checking the return value from a hook function' while I was 
there, so you don't need to submit a new report for that.

Modules/readline.c revision 2.83.

Thanks for the report!


--

Comment By: Michael Hudson (mwh)
Date: 2005-03-30 11:10

Message:
Logged In: YES 
user_id=6656

While it does seem a bit odd to call the completer function in the thread 
that calls set_completer and not the thread that calls readline(), I don't 
immediately see how this is leading to segfaults.  Do you?

Anyway, I can reproduce the problem, so if your fix fixes it, I'll check it in 
(irrespective of fixing segfaults, it just makes more sense).

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-29 13:10

Message:
Logged In: YES 
user_id=6656

Unless there's some reason to suspect they share a common
cause (and, I don't see one) a second report is more
appropriate.

Also, if you understand what's going on, you can explain
there :)

--

Comment By: Yariv Ido (dcoder)
Date: 2005-03-28 23:33

Message:
Logged In: YES 
user_id=326689

I haven't (Completely forgot about it, after finding the
main one...). Should I post a seperate bug report, or will
this one do?

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

--

Comment By: Yariv Ido (dcoder)
Date: 2005-03-19 23:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=110&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1167300 ] Error "exec"ing python code

[SourceForge.net]

Bugs item #1167300, was opened at 2005-03-21 00:35
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error "exec"ing python code

Initial Comment:
I'm trying to 'exec'ing the following code:

class Foo: pass
class Bar:
f = Foo

The error appears when using 'exec f in {}, {}':

>>> f = ''.join(open('/home/stefan/t.py').readlines())
>>> exec f in {}, {}
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in ?
  File "", line 3, in Bar
NameError: name 'Foo' is not defined

I tested on python 2.3 and python 2.4, both show the same
behavior.

--

>Comment By: Michael Chermside (mcherm)
Date: 2005-03-30 07:40

Message:
Logged In: YES 
user_id=99874

I can confirm this... it appears that things which are set
in the global scope within an "exec ... in {}, {}" are not
then correctly accessed in the global scope when being read.
The following two examples illustrate the problem:

>>> exec """... x = 3
... def f():
... global x
... print x
... f()
... """ in {}, {}
3

... and again without the global definition:

>>> exec """... x = 3
... def f():
... print x
... f()
... """ in {}, {}
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 4, in ?
  File "", line 3, in f
NameError: global name 'x' is not defined

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'

[SourceForge.net]

Bugs item #1173407, was opened at 2005-03-30 15:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1165306 ] Property access with decorator makes interpreter crash

[SourceForge.net]

Bugs item #1165306, was opened at 2005-03-17 14:56
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1165306&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Remy Blank (remyblank)
Assigned to: Michael Hudson (mwh)
Summary: Property access with decorator makes interpreter crash

Initial Comment:
The attached file makes the interpreter crash.
Basially, a method is decorated, and used as the getter
function for a property. Accessing the property
provokes the crash.

I get the following output (linux-2.6.10):

[EMAIL PROTECTED] TestCases $ ./crashTest.py
Creating instance
Getting value
Segmentation fault

Using python-2.3.4 from Gentoo, i.e. it has a few
patches from 2.3.5.

On Windows XP with python-2.4, I get a "Python has
encountered a problem and needs to close." dialog box.

--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-30 17:32

Message:
Logged In: YES 
user_id=6656

Fixed, in 

Objects/classobject.c revision 2.177
Lib/test/test_new.py revision 1.20

Thanks for the report!

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 22:16

Message:
Logged In: YES 
user_id=6656

> > remyblank: let me guess your code wasn't doing what
> > you thought it did? :)
> 
> Err... Not sure what you mean... What would be the correct
> way to do what I thought it did?

Well, I don't know, but what it was doing was trying to create a method 
bound to None...

I'll check this in soon.

--

Comment By: Remy Blank (remyblank)
Date: 2005-03-17 20:13

Message:
Logged In: YES 
user_id=568100

> remyblank: let me guess your code wasn't doing what you
thought it did? :)

Err... Not sure what you mean... What would be the correct
way to do what I thought it did?

The code was largely inspired by a Cookbook entry. These are
still my first steps with decorators, and I have to admit I
don't yet fully understand why I have to create a MethodType
manually.

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 18:43

Message:
Logged In: YES 
user_id=6380

Looks OK on cursory inspection.

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:28

Message:
Logged In: YES 
user_id=6656

Let's attach a test case too.

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 17:15

Message:
Logged In: YES 
user_id=6656

Well, it's a bit more subtle than I thought:

>>> def f(): pass
... 
>>> print f.__get__(1).im_class
None

The problem occurs when *both* im_self and im_class are None; and I'm 
now reasonably convinced that calling the type object is the only way this 
can be acheived.  So a simple check along these lines in 
instancemethod_new would suffice (patch attached), and seems less likely 
to break code.

I suspect this has missed 2.4.1.

remyblank: let me guess your code wasn't doing what you thought it did? :)

--

Comment By: Guido van Rossum (gvanrossum)
Date: 2005-03-17 17:03

Message:
Logged In: YES 
user_id=6380

Looks like I wasn't finished with the thought when I checked
it in. I think I was trying to make instancemethod generally
useful as a currying primitive. That should probably be
considered more careful; please roll it back.

(I think it may have been part of the aborted experiment to
get rid of bound methods.)

Is there time to backport this to 2.4.1?

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 16:44

Message:
Logged In: YES 
user_id=6656

Hmm.  A little CVS log reading finds us this:

revision 2.170
date: 2003/04/09 19:35:08;  author: gvanrossum;  state: Exp;  lines: +2 -2
branches:  2.170.10;
Make it possible to call instancemethod() with 2 arguments.

Guido, what was the motivation for this?  Is it possible to create 
instancemethods with im_class == NULL some other way?  (If there is, I 
don't see it).

Also, you didn't add a unit test  (in fact, instancemethod_new only 
gets called twice during a run of the test suite, both times with three 
arguments).

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-17 15:17

Message:
Logged In: YES 
user_id=6656

Confirmed, on 2.4 HEAD, even.

There's a lot going on in your test file that is unecessary, though; this is a 
smaller test case:

types.MethodType(lambda :None, None)(1)

instancemethod_call doesn't seem to expect im_class to be NULL...

--

[ python-Bugs-542314 ] long file name support broken in windows

[SourceForge.net]

Bugs item #542314, was opened at 2002-04-10 21:23
Message generated for change (Comment added) made by stunorton
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: long file name support broken in windows

Initial Comment:
>From c.l.py, thread ""

Peter D:
I'm using windows and trying to call os.path.getmtime
() after using os.path.walk... However, I'm choking 
with "[Errno 38] Filename too long" on paths with len 
> ~260

Adding Martin's reply in a new comment (so it is not 
at the top of each and every mail I get on this bug :)

--

Comment By: Stuart Norton (stunorton)
Date: 2005-03-30 08:54

Message:
Logged In: YES 
user_id=1152606

I came across this suggestion while googling... and I would 
have expected it to work, but this code:

import os

os.chdir("\\ussvs-file02
\radpubs\wip\zStaging\translation\D10
\previous_test\cumulative\Common\Reference\API\Borland
.Eco.Persistence.Configuration\classes\PersistenceMapper
DefinitionCollection\Methods")
for filename in os.listdir("."):
print filename
infile = file(filename)

gives me 

C:\Documents and 
Settings\snorton\Desktop\h2build\buildtools>test.py
PersistenceMapperDefinitionCollection.AddRange.xml
PersistenceMapperDefinitionCollection.Assign.xml
PersistenceMapperDefinitionCollection.FindByName.xml
PersistenceMapperDefinitionCollection.NameExists.xml
PersistenceMapperDefinitionCollection.PersistenceMapperDefi
nitionCollection.xml
Traceback (most recent call last):
  File "C:\Documents and 
Settings\snorton\Desktop\h2build\buildtools\test.py", line 6, 
in ?
infile = file(filename)
IOError: [Errno 2] No such file or 
directory: 'PersistenceMapperDefinitionCollection.Persistence
MapperDefinitionCollection.xml'

... funny that the file with the long path comes up in listdir() 
but isn't found with file()...


--

Comment By: Mark Hammond (mhammond)
Date: 2002-04-10 21:26

Message:
Logged In: YES 
user_id=14198

Martin v. Loewis's reply on c.l.py:

Since you are asking for a work-around: cd into one of the 
more nested directories when the path gets longer 
(os.chdir), and use relative paths from then on.

If you want to study how to solve the problem: the relevant 
code snippet is in Modules/posixmodule.c

/* the library call can blow up if the file name is 
too long! */
if (pathlen > MAX_PATH) {
PyMem_Free(pathfree);
errno = ENAMETOOLONG;
return posix_error();
}

There might be different ways to approach this:

- challenge the correctness of the comment:
   - try to establish why the author of that code
 thought that the C library could blow up
   - analyse whether these arguments are still true
 with the current compiler version
  -or-
   - prove the argument wrong by analysing the source 
 code of the C library
- then remove the constraint
-or-
- use different API to achieve the same effect without
  suffering from the constraint.

I'm serious about these suggestions: users would appreciate 
if this gets fixed somehow - apparently, the system allows 
longer file names, and apparently, the system itself can 
deal with that quite well. This
can be only true if the system either doesn't use its C 
library, or if the C library does not have this restriction.


--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Feature Requests-700921 ] Wide-character curses

[SourceForge.net]

Feature Requests item #700921, was opened at 2003-03-10 16:45
Message generated for change (Comment added) made by moculus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=700921&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Cherniavsky Beni (cben)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wide-character curses

Initial Comment:
There exists a standard for wide-character curses
(http://www.opengroup.org/onlinepubs/7908799/cursesix.html)
and at least ncurses implements it (almost completely;
you need to enable this when configuring it).  It is
essensial for getting the maximum of modern UTF-8
terminals (e.g. xterm).
It would make sense for python's curses module to
support all the wide functions on systems where the
wide curses interface is present, especially since
Python already supports unicode.


--

Comment By: Erik Osheim (moculus)
Date: 2005-03-30 17:29

Message:
Logged In: YES 
user_id=542811

Is there any work still being done on this? I have been
hoping that a feature like this would be included for
awhile, and it's more than two years since this request was
posted.


--

Comment By: Michael Hudson (mwh)
Date: 2003-03-11 14:52

Message:
Logged In: YES 
user_id=6656

Cool.

You should be able to extend the current preprocessor
hackery to relieve some of the drudgery, shouldn't you?

--

Comment By: Cherniavsky Beni (cben)
Date: 2003-03-11 14:49

Message:
Logged In: YES 
user_id=36166

OK.  I don't care much whether it gets official quickly, I
do want something to play with :-) (of course I want it to
become official when it's good enough).

I've looked a bit at the code.  The prospect of
double-casing all functions to use the wide interface is not
pleasant but I don't see a better alternative yet; I'd like
to factor things out if I find a way...  And yes, any code I
produce wll certainly require review :-).

--

Comment By: Michael Hudson (mwh)
Date: 2003-03-11 14:06

Message:
Logged In: YES 
user_id=6656

It sounds like you've given this more thought already than
I'm likely to for some time :-)

This is unlikely to make 2.3, I'd have thought, so there's
no hurry, really.

I can answer any questions about details of implementation
and review any code you produce, but I think you have a
better handle on design issues.

--

Comment By: Cherniavsky Beni (cben)
Date: 2003-03-11 13:38

Message:
Logged In: YES 
user_id=36166

One more issue: constants.

I think the ``A_`` attribute constants  should not be
duplicated as ``WA_``; rather the same ``A_`` values will be
accepted in all cases and translated to the corresponding
``WA_`` values when passing them to wide curses functions.
``WA_`` attributes that have no ``A_`` counterpart in curses
should get one, possibly a long int:
A_{HORIZONTAL,LEFT,LOW,RIGHT,TOP,VERTICAL}.  Wait, we 
already define them ;-).  But they might be availiable on
some platforms only as ``WA_`` and not ``A_``...

The ``ACS_`` constants also have ``WACS_`` counterparts that
are (cchar_t *).  Probably the later should be exposed as
unicode strings instead of the 

Other constants added in XSI curses are:

* EOF/WEOF (actually declared in , ;
returned by `.getch()` - should be either exposed in the
module or converted to something sensible (None?).  getkey()
currently segfaults(!) on end of file, should return empty
string for consistency with `file.read()`...

* KEY_CODE_YES - return value of `get_wch()` to indicate the
code is a key.  Should not be exposed.

Update to previous message: the ``_wchstr`` family need not
be supported, at least as long as ``chstr`` family isn't (I
didn't notice there is such a thing).  In long run, it might
be useful (but then a completely new high-level wrapper of
windows as directly subscriptable/sliceable and 2D arrays
would be even better...  Let's leave it for now).

--

Comment By: Cherniavsky Beni (cben)
Date: 2003-03-10 20:55

Message:
Logged In: YES 
user_id=36166

Good question :-).
Here are the basic additions of the wide curses interface:

* `chtype` (which must be an integral type) donesn't have
enough place to hold a character OR-ed with the attributes,
nor would that be useful enough since combining characters
must be handled.  Therefore two types are intoroduced:

** attr_t - an integral type used to hold an OR-ed set of
attributes that begin with the prefix ``WA_``.  These
attributes are semantically a superset of the ``A_`` ones
and can have different values (although in ncurses they are
the same).

** ccha

[ python-Bugs-1172581 ] "cmp" should be "key" in sort doc

[SourceForge.net]

Bugs item #1172581, was opened at 2005-03-29 10:02
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 12:41

Message:
Logged In: YES 
user_id=593130

This has been fixed in the 2.4.1 doc released today
http://docs.python.org/lib/typesseq-mutable.html

(The old url with  /doc/current added no longer works for me).

Please close as 'fixed' if you can.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1171994 ] error in documentation for splitting empty string

[SourceForge.net]

Bugs item #1171994, was opened at 2005-03-28 12:49
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171994&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in documentation for splitting empty string 

Initial Comment:
Below is extracted from http://www.python.org/doc/2.4/
lib/string-methods.html describing the string method 
split().

---
split([sep [,maxsplit]])

... Splitting an empty string with a specified separator 
returns an empty list.

If sep is not specified or is None, a different splitting 
algorithm is applied. ... Splitting an empty string returns 
"['']".

---

The rationale for different treatment of splitting an empty 
string seems to be discussed in 811604. However the 
documentation seems to be the opposite of actual result.

>>> ''.split(',')
['']
>>> ''.split()
[]


--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 12:56

Message:
Logged In: YES 
user_id=593130

The new 2.4.1 doc (released today) at
http://docs.python.org/lib/string-methods.html
remains the same.

Verified behavior on 2.2.  If unchanged (lest code be broken), 
there does seem to be a problem.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1171994&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1172581 ] "cmp" should be "key" in sort doc

[SourceForge.net]

Bugs item #1172581, was opened at 2005-03-29 10:02
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:03

Message:
Logged In: YES 
user_id=593130

Ignore previous comment about 'old url'.  Did not 
notice 'www.python' versus 'doc.python'.  It seems 
that 'www.python.org/doc/current' and 'docs.python.org' are 
aliased prefixes leading to the 'current' docs.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 12:41

Message:
Logged In: YES 
user_id=593130

This has been fixed in the 2.4.1 doc released today
http://docs.python.org/lib/typesseq-mutable.html

(The old url with  /doc/current added no longer works for me).

Please close as 'fixed' if you can.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1170424 ] why should URL be required for all packages

[SourceForge.net]

Bugs item #1170424, was opened at 2005-03-25 04:58
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170424&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jürgen A. Erhard (jae)
Assigned to: Nobody/Anonymous (nobody)
Summary: why should URL be required for all packages

Initial Comment:
Annoying if you just want to roll an in-house package.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:12

Message:
Logged In: YES 
user_id=593130

Bugs are a discrepancy between intended/claimed behavior and 
actual behavior.  Since this does not appear to report such a 
discrepancy, it does not appear to be a bug report.  Please close 
and ask your question and make your comment on the Python 
discussion mailing list or newsgroup (comp.lang.python).

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170424&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1170422 ] doc speaks of extensions option while it's *called* ext_modu

[SourceForge.net]

Bugs item #1170422, was opened at 2005-03-25 04:56
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jürgen A. Erhard (jae)
Assigned to: Nobody/Anonymous (nobody)
Summary: doc speaks of extensions option while it's *called* ext_modu

Initial Comment:
ext_modules, of course (crap bugtracker)

Another minor fix would be to show an import Extension
in at least one example.  Quite a lot easier to see for
the impatient.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:29

Message:
Logged In: YES 
user_id=593130

What I understand is that you want something (literally 'extention 
option'?) replaced by 'ext_module' somewhere.  Could you be 
more specific as to where (which section of which document, or 
a url) and what something?  Giving the current phrase or 
sentence and your suggested replacement makes a change 
decision easier.

--

Comment By: Jürgen A. Erhard (jae)
Date: 2005-03-25 05:03

Message:
Logged In: YES 
user_id=10380

Ouch, forget about the import Extension... it's there, and I
was just blind.  Note to self: the usual ;-)

(I wish I could edit my own submissions)

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170422&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1170331 ] Error in base64.b32decode

[SourceForge.net]

Bugs item #1170331, was opened at 2005-03-24 23:05
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170331&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: toidinamai (toidinamai)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error in base64.b32decode

Initial Comment:
Hi,   
  
 
  
  
 
I believe there is an error in base64.b32decode because
it doesn't seem to
  
allow to decode arbitrary binary data:
  
 


  
 
#!/usr/bin/env python2.4  
  
 
  
  
 
import base64 
  
 
  
  
 
b64d = base64.b64decode   
  
 
b64e = base64.b64encode   
  
 
  
  
 
print "base64: ", repr(b64d(b64e('\x00')))
  
 
  
  
 
b16d = base64.b16decode   
  
 
b16e = base64.b16encode   
  
 
  
  
 
print "base16: ", repr(b16d(b16e('\x00')))
  
 
  
  
 
b32d = base64.b32decode   
  
 
b32e = base64.b32encode   
  
 
  
  
 
print "base32: ", repr(b32d(b32e('\x00')))
  
 
   
  
 
  
  
 
This raises a very strange exception: 
  
 
  
  
 
Traceback (most recent call l

[ python-Bugs-1170311 ] zipfile UnicodeDecodeError

[SourceForge.net]

Bugs item #1170311, was opened at 2005-03-24 21:51
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: adam davis (adamx97)
Assigned to: M.-A. Lemburg (lemburg)
Summary: zipfile UnicodeDecodeError

Initial Comment:
I think this is the same as #  705295, which may have
been prematurely closed.

I think the error is dependent on the data or time.

File "C:\Python24\lib\zipfile.py", line 166, in FileHeader
return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd0 in position 10: ordinal not in range(128)

The header is packed like this:
header = struct.pack(structFileHeader,
stringFileHeader,
 self.extract_version, self.reserved,
self.flag_bits,
 self.compress_type, dostime, dosdate, CRC,
 compress_size, file_size,
 len(self.filename), len(self.extra))

the header is:

[Dbg]>>> header
'PK\x03\x04\x14\x00\x00\x00\x00\x00\xd0\xa9x2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00-\x00\x00\x00'

and here are the parts that made it up:

[Dbg]>>> structFileHeader, stringFileHeader,
self.extract_version, self.reserved,
self.flag_bits,self.compress_type, dostime, dosdate,
CRC, compress_size, file_size, len(self.filename),
len(self.extra)
('<4s2B4HlLL2H', 'PK\x03\x04', 20, 0, 0, 0, 43472,
12920, 0, 0, 0, 45, 0)


here's the pieces of the 

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:39

Message:
Logged In: YES 
user_id=593130

Your report ends with 'here's the pieces of the'.  Was something 
cut off?  If you meant to attach a file, try again.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1169108 ] PySys_WriteStderr() -> WaitForSingleObject() hangs system

[SourceForge.net]

Bugs item #1169108, was opened at 2005-03-23 08:55
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169108&group_id=5470

Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: stan pinte (stanpinte)
Assigned to: Nobody/Anonymous (nobody)
Summary: PySys_WriteStderr() -> WaitForSingleObject() hangs system

Initial Comment:
hello,

I am running Simpy (python simulation framework) within
pythondotnet (a slightly modified python version, based
on python2.4),
and, even though this process is single-thread, it
hangs misteriously,
in an unpredictable way...

Python console cease to respond to Ctrl-C events...

Here is the current Thread status:

Thread Start Address:
Symbol Name:Line Number:PC:
mscoree!_CorExeMain() + 0x0 --- 7917D08C

Thread Stack:

ntdll ! KiFastSystemCallRet() + 0x
KERNEL32 ! WaitForSingleObject() + 0x12
python24 ! PySys_WriteStderr() + 0x14d
python24 ! PyTuple_Type() + 0x0

However, I would like to be able to go higher in the
stack, to see what
caused this deadlock.

Any proposed strategy to guess what happened, or to
track down the problem?

thanks a lot,

Stan.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:45

Message:
Logged In: YES 
user_id=593130

Unless you claim/believe that there is a bug in unmodified 
CPython 2.4.1 (just released) please close this item.

--

Comment By: stan pinte (stanpinte)
Date: 2005-03-23 10:28

Message:
Logged In: YES 
user_id=154693

 Hello!

I solved my problem by removing all references to
Queue.queue instances in my python code. --> my usage of
Queues was so heavy that it was triggering a nice bug in
python synchronization code.

I was pointed to threading issues by enabling full trace in
my python code, and some traces were showing code from
threading.py

thanks a lot anyway for the help.

Stan.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1169108&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'

[SourceForge.net]

Bugs item #1173407, was opened at 2005-03-30 10:42
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1170311 ] zipfile UnicodeDecodeError

[SourceForge.net]

Bugs item #1170311, was opened at 2005-03-25 03:51
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: adam davis (adamx97)
>Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile UnicodeDecodeError

Initial Comment:
I think this is the same as #  705295, which may have
been prematurely closed.

I think the error is dependent on the data or time.

File "C:\Python24\lib\zipfile.py", line 166, in FileHeader
return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd0 in position 10: ordinal not in range(128)

The header is packed like this:
header = struct.pack(structFileHeader,
stringFileHeader,
 self.extract_version, self.reserved,
self.flag_bits,
 self.compress_type, dostime, dosdate, CRC,
 compress_size, file_size,
 len(self.filename), len(self.extra))

the header is:

[Dbg]>>> header
'PK\x03\x04\x14\x00\x00\x00\x00\x00\xd0\xa9x2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00-\x00\x00\x00'

and here are the parts that made it up:

[Dbg]>>> structFileHeader, stringFileHeader,
self.extract_version, self.reserved,
self.flag_bits,self.compress_type, dostime, dosdate,
CRC, compress_size, file_size, len(self.filename),
len(self.extra)
('<4s2B4HlLL2H', 'PK\x03\x04', 20, 0, 0, 0, 43472,
12920, 0, 0, 0, 45, 0)


here's the pieces of the 

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-30 21:27

Message:
Logged In: YES 
user_id=38388

The problem is not the data in the file, but the fact that
your filename is probably a Unicode object which fails to
concatenate with the header (which clearly isn't ASCII :-).

I have no idea whether ZIP files support anything other than
ASCII filenames. If you have a reference, please let us know.

If your filename only contains ASCII characters, you should
be able to open the file correctly by first encoding the
filename to ASCII: filename.encode('ascii').
Perhaps zipfile.py should do that for you ?!


--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 20:39

Message:
Logged In: YES 
user_id=593130

Your report ends with 'here's the pieces of the'.  Was something 
cut off?  If you meant to attach a file, try again.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1168427 ] Possible windows+python bug

[SourceForge.net]

Bugs item #1168427, was opened at 2005-03-22 10:38
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:37

Message:
Logged In: YES 
user_id=593130

Do you get the same problem with either of the current releases 
(2.3.5 and/or 2.4.1)?

--

Comment By: logistix (logistix)
Date: 2005-03-23 21:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1172581 ] "cmp" should be "key" in sort doc

[SourceForge.net]

Bugs item #1172581, was opened at 2005-03-29 10:02
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 13:03

Message:
Logged In: YES 
user_id=593130

Ignore previous comment about 'old url'.  Did not 
notice 'www.python' versus 'doc.python'.  It seems 
that 'www.python.org/doc/current' and 'docs.python.org' are 
aliased prefixes leading to the 'current' docs.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 12:41

Message:
Logged In: YES 
user_id=593130

This has been fixed in the 2.4.1 doc released today
http://docs.python.org/lib/typesseq-mutable.html

(The old url with  /doc/current added no longer works for me).

Please close as 'fixed' if you can.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'

[SourceForge.net]

Bugs item #1173407, was opened at 2005-03-30 10:42
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 15:46

Message:
Logged In: YES 
user_id=80475

Sorry.  Am closing this to eliminate noise from the tracker.
 The grammar nit arguable and inconsequential (because it is
not in the main documentation and is readable as-ias).

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1168135 ] Python 2.5a0 Tutorial errors and observations

[SourceForge.net]

Bugs item #1168135, was opened at 2005-03-22 01:58
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael R Bax (mrbax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.5a0 Tutorial errors and observations

Initial Comment:
Please find attached my updated list of errors and 
observations in response to Python 2.5a0.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 16:01

Message:
Logged In: YES 
user_id=593130

Subject to reading that particular version (.5a0), I generally 
agree with your suggestions.  Here are some specific comments 
on your comments.  Feel free to incorporate them into a revised 
suggestion list if you wish.

---
Your first correction is wrong.  -ly adverbs are never hyphenated 
(Chicago Manual of Style, Table 6.1, for instance).

---
3.1.2
>>> word[:1] = 'Splat'
-- This is trying to assign 5 letters to one?

Slice assignment is replacement, not overwriting.  This is 
replacing 1 byte with 5, which *is* valid, and perhaps the point 
being made.  Perhaps you would recommend another change to 
be clearer?

---
##5.1.3
##Combining these two special cases, we see that "map(None, 
list1, list2)" is a convenient way of turning a pair of lists into a list 
of pairs
#   -- Shouldn't one rather use zip()?

I would agree that 'convenient' should be removed and a note 
added that this has been superceded by zip unless one wants 
the different behavior of extending shorter sequences.

--
5.1.3
filter(function, sequence)" returns a sequence (of the same type, 
if possible)
-- How could this ever be impossible?

I suppose a broken class, but then what would filter do?  If 
filter 'works' for all builtins, I agree that we should just say so.  
Perhaps 'returns a sequence of the same type (for all builtins 
and sensible user classes)' -- if that is true


5.2
There is a way to remove an item from a list given its index 
instead of its value: the del statement. 
-- How is this different to pop?

pop, builtin on top of del, also saves and returns the deleted value 
so it can be bound to something, which takes longer.  ie
def pop(self, i):
  ret = self[i]
  del self[i]
  return ret


5.3
Sequence unpacking requires that the list of variables on the left 
have the same number of elements as the length of the sequence
-- requires that the list of variables on the left has 
(grammar)
-- requires the list of variables on the left to have 
(alternate)

Since the code sequence on the left is not a Python list but only 
a common-meaning list, I think even better would be
"Sequence unpacking requires that the number of variables on 
the left be the same as the length of the sequence on the right"

--
5.7
Comparisons may be combined by the Boolean operators and 
and or
-- combined using the (style)

In general, the return value of a short-circuit operator, when 
used as a general value and not as a Boolean, is the last 
evaluated argument. 
-- rewrite: When used as a general value and not as a 
Boolean, the return value of a short-circuit operator is the last 
evaluated argument.

I would personally be a bit more radical here.  As has been said 
often on c.l.p in response to newby misconceptions about 'and' 
and 'or', they are not operators, in the sense of syntactically 
abbreviating function calls, but flow-control keywords 
abbreviating if-else constructs.  Saying so in the tutorial 
might 'short-circuit' some of the misconceptions.

-
9
a derived class can override any methods of its base class or 
classes, a method can call the method of a base class with the 
same name.
-- classes, and a method (last phrase in a list)

There are no special constructors or destructors.
-- What about __init__, or is that a "normal" 
constructor?

The special method __new__ constructs (and initializes 
immutables) (so why isn't it a 'special constructor'?), __init__ 
initializes,  But as I remember, the quoted sentence does seem 
confusing.

---
9.2
Otherwise, all variables found outside of the innermost scope are 
read-only.
-- Explain what happens when you try to assign to a 
read-only variable?

You create a new local of the same name and will not be able to 
read the masked variable.


9.8
raise Class, instance
-- What's the point?  In the example thereafter, these 
three have the same effect:
raise c()
raise B, c()

raise instance
-- wasn't this "new form" covered in 8.5 (raise MyClass
(2*2))?

I personally agree that the tutorial should emphasize the newest 
form (rais

[ python-Bugs-1168135 ] Python 2.5a0 Tutorial errors and observations

[SourceForge.net]

Bugs item #1168135, was opened at 2005-03-22 01:58
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168135&group_id=5470

Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael R Bax (mrbax)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Python 2.5a0 Tutorial errors and observations

Initial Comment:
Please find attached my updated list of errors and 
observations in response to Python 2.5a0.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 16:01

Message:
Logged In: YES 
user_id=593130

Subject to reading that particular version (.5a0), I generally 
agree with your suggestions.  Here are some specific comments 
on your comments.  Feel free to incorporate them into a revised 
suggestion list if you wish.

---
Your first correction is wrong.  -ly adverbs are never hyphenated 
(Chicago Manual of Style, Table 6.1, for instance).

---
3.1.2
>>> word[:1] = 'Splat'
-- This is trying to assign 5 letters to one?

Slice assignment is replacement, not overwriting.  This is 
replacing 1 byte with 5, which *is* valid, and perhaps the point 
being made.  Perhaps you would recommend another change to 
be clearer?

---
##5.1.3
##Combining these two special cases, we see that "map(None, 
list1, list2)" is a convenient way of turning a pair of lists into a list 
of pairs
#   -- Shouldn't one rather use zip()?

I would agree that 'convenient' should be removed and a note 
added that this has been superceded by zip unless one wants 
the different behavior of extending shorter sequences.

--
5.1.3
filter(function, sequence)" returns a sequence (of the same type, 
if possible)
-- How could this ever be impossible?

I suppose a broken class, but then what would filter do?  If 
filter 'works' for all builtins, I agree that we should just say so.  
Perhaps 'returns a sequence of the same type (for all builtins 
and sensible user classes)' -- if that is true


5.2
There is a way to remove an item from a list given its index 
instead of its value: the del statement. 
-- How is this different to pop?

pop, builtin on top of del, also saves and returns the deleted value 
so it can be bound to something, which takes longer.  ie
def pop(self, i):
  ret = self[i]
  del self[i]
  return ret


5.3
Sequence unpacking requires that the list of variables on the left 
have the same number of elements as the length of the sequence
-- requires that the list of variables on the left has 
(grammar)
-- requires the list of variables on the left to have 
(alternate)

Since the code sequence on the left is not a Python list but only 
a common-meaning list, I think even better would be
"Sequence unpacking requires that the number of variables on 
the left be the same as the length of the sequence on the right"

--
5.7
Comparisons may be combined by the Boolean operators and 
and or
-- combined using the (style)

In general, the return value of a short-circuit operator, when 
used as a general value and not as a Boolean, is the last 
evaluated argument. 
-- rewrite: When used as a general value and not as a 
Boolean, the return value of a short-circuit operator is the last 
evaluated argument.

I would personally be a bit more radical here.  As has been said 
often on c.l.p in response to newby misconceptions about 'and' 
and 'or', they are not operators, in the sense of syntactically 
abbreviating function calls, but flow-control keywords 
abbreviating if-else constructs.  Saying so in the tutorial 
might 'short-circuit' some of the misconceptions.

-
9
a derived class can override any methods of its base class or 
classes, a method can call the method of a base class with the 
same name.
-- classes, and a method (last phrase in a list)

There are no special constructors or destructors.
-- What about __init__, or is that a "normal" 
constructor?

The special method __new__ constructs (and initializes 
immutables) (so why isn't it a 'special constructor'?), __init__ 
initializes,  But as I remember, the quoted sentence does seem 
confusing.

---
9.2
Otherwise, all variables found outside of the innermost scope are 
read-only.
-- Explain what happens when you try to assign to a 
read-only variable?

You create a new local of the same name and will not be able to 
read the masked variable.


9.8
raise Class, instance
-- What's the point?  In the example thereafter, these 
three have the same effect:
raise c()
raise B, c()

raise instance
-- wasn't this "new form" covered in 8.5 (raise MyClass
(2*2))?

I personally agree that the tutorial should emphasize the newest

[ python-Bugs-1167300 ] Error "exec"ing python code

[SourceForge.net]

Bugs item #1167300, was opened at 2005-03-21 00:35
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Seefeld (stefan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error "exec"ing python code

Initial Comment:
I'm trying to 'exec'ing the following code:

class Foo: pass
class Bar:
f = Foo

The error appears when using 'exec f in {}, {}':

>>> f = ''.join(open('/home/stefan/t.py').readlines())
>>> exec f in {}, {}
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 2, in ?
  File "", line 3, in Bar
NameError: name 'Foo' is not defined

I tested on python 2.3 and python 2.4, both show the same
behavior.

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 16:11

Message:
Logged In: YES 
user_id=593130

I got a similar NameError in 2.2.1, so this is not due to a recent 
change.

--

Comment By: Michael Chermside (mcherm)
Date: 2005-03-30 07:40

Message:
Logged In: YES 
user_id=99874

I can confirm this... it appears that things which are set
in the global scope within an "exec ... in {}, {}" are not
then correctly accessed in the global scope when being read.
The following two examples illustrate the problem:

>>> exec """... x = 3
... def f():
... global x
... print x
... f()
... """ in {}, {}
3

... and again without the global definition:

>>> exec """... x = 3
... def f():
... print x
... f()
... """ in {}, {}
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 4, in ?
  File "", line 3, in f
NameError: global name 'x' is not defined

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167300&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1170766 ] weakref.proxy incorrect behaviour

[SourceForge.net]

Bugs item #1170766, was opened at 2005-03-25 16:54
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 6
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-29 08:39

Message:
Logged In: YES 
user_id=6656

Also see bug #1075356 (which is very minor, but might as
well get fixed at the same time).

--

Comment By: Armin Rigo (arigo)
Date: 2005-03-29 08:23

Message:
Logged In: YES 
user_id=4771

The following type slots appear to be missing in the proxy types:

* nb_(inplace_){floor,true}_divide
* sq_repeat, sq_concat, sq_item, sq_ass_item, sq_inplace_concat, 
sq_inplace_repeat (which are needed for operator.repeat(), operator.concat(), 
etc. to work)
* tp_as_buffer
* tp_richcompare (tp_compare alone is not enough)
* tp_descr_get, tp_descr_set (for proxies to descriptors...)
* nb_coerce (though it seems that only an explicit call to coerce() can show 
that this is missing; implicit coercion is done correctly in other operators)
* nb_oct, nb_hex

As far as I can tell, there is no existing operator that is broken in the same 
way that nb_nonzero was.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-27 06:17

Message:
Logged In: YES 
user_id=80475

Fixed the __nonzero__ problem for Py2.5 and will backport to
Py2.4.  See Objects/weakrefobject.c 1.21.

Leaviing this report open until the rest of the module can
be checked and fixed.



--

Comment By: Armin Rigo (arigo)
Date: 2005-03-26 09:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying 
object's nb_nonzero slot instead of going through the general PyObject_IsTrue() 
mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in 
addition to tp_compare.  In fact, we should review the code to check if 
ProxyType knows about the most recent type slots...

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1168427 ] Possible windows+python bug

[SourceForge.net]

Bugs item #1168427, was opened at 2005-03-22 16:38
Message generated for change (Comment added) made by holo9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


--

>Comment By: holo9 (holo9)
Date: 2005-03-30 23:15

Message:
Logged In: YES 
user_id=1244385

I tested this on Python 2.3.4. But there is no problem in 
Python. This bug could be reproduced in C, for example. The 
main problem is in Windows built-in firewall. For explanation 
take a look at:

http://seclist.org/lists/bugtraq/2005/Mar/0409.html

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 21:37

Message:
Logged In: YES 
user_id=593130

Do you get the same problem with either of the current releases 
(2.3.5 and/or 2.4.1)?

--

Comment By: logistix (logistix)
Date: 2005-03-24 03:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173637 ] quit should quit

[SourceForge.net]

Bugs item #1173637, was opened at 2005-03-30 16:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Chaput (mchaput)
Assigned to: Nobody/Anonymous (nobody)
Summary: quit should quit

Initial Comment:
When the user types "quit" in the interpreter, instead
of quitting the program gives him or her a lecture on
the "proper" way to quit.

This is very obnoxious.

Since the interpreter obviously understands the "quit"
command, it should just quit, dammit.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'

[SourceForge.net]

Bugs item #1173407, was opened at 2005-03-30 15:42
Message generated for change (Comment added) made by gyrof
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

--

>Comment By: gyrof (gyrof)
Date: 2005-03-30 21:51

Message:
Logged In: YES 
user_id=1249584

It is a very minor issue, but the change is not arguable
from the perspective of correct English grammar.

If I submit a diff, will it (eventually) be reviewed or applied?

-gyro

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 20:46

Message:
Logged In: YES 
user_id=80475

Sorry.  Am closing this to eliminate noise from the tracker.
 The grammar nit arguable and inconsequential (because it is
not in the main documentation and is readable as-ias).

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 19:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'

[SourceForge.net]

Bugs item #1173407, was opened at 2005-03-30 10:42
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

--

>Comment By: Tim Peters (tim_one)
Date: 2005-03-30 17:01

Message:
Logged In: YES 
user_id=31435

I mentally replaced "data is" by "data are", and disliked how 
it read then.  So, no, I won't apply such a patch.  English 
grammar changes over time to match what careful English 
speakers actually use, so I'll view this is a crusade to stamp 
out effete elitism -- "data are" my ass .

--

Comment By: gyrof (gyrof)
Date: 2005-03-30 16:51

Message:
Logged In: YES 
user_id=1249584

It is a very minor issue, but the change is not arguable
from the perspective of correct English grammar.

If I submit a diff, will it (eventually) be reviewed or applied?

-gyro

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 15:46

Message:
Logged In: YES 
user_id=80475

Sorry.  Am closing this to eliminate noise from the tracker.
 The grammar nit arguable and inconsequential (because it is
not in the main documentation and is readable as-ias).

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173637 ] quit should quit

[SourceForge.net]

Bugs item #1173637, was opened at 2005-03-30 16:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Chaput (mchaput)
Assigned to: Nobody/Anonymous (nobody)
Summary: quit should quit

Initial Comment:
When the user types "quit" in the interpreter, instead
of quitting the program gives him or her a lecture on
the "proper" way to quit.

This is very obnoxious.

Since the interpreter obviously understands the "quit"
command, it should just quit, dammit.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 17:11

Message:
Logged In: YES 
user_id=80475

I concur!

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173637&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173407 ] very minor doc bug in 'listsort.txt'

[SourceForge.net]

Bugs item #1173407, was opened at 2005-03-30 15:42
Message generated for change (Comment added) made by gyrof
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: gyrof (gyrof)
Assigned to: Nobody/Anonymous (nobody)
Summary: very minor doc bug in 'listsort.txt'

Initial Comment:
Tim Peter's explanation of 'timsort' in the file
'listsort.txt' is just excellent. 
I would recommend, however, that all occurrences of
'data is' be replaced by 'data are'.

Just a minor nit.

-gyro

--

>Comment By: gyrof (gyrof)
Date: 2005-03-30 22:24

Message:
Logged In: YES 
user_id=1249584

Fair enough. I should have known that Mr. Peters would have
considered this already. 

Just-trying-to-make-Python-docs-more-appealing-to-pedants-like-me'ly
yours,
gyro

--

Comment By: Tim Peters (tim_one)
Date: 2005-03-30 22:01

Message:
Logged In: YES 
user_id=31435

I mentally replaced "data is" by "data are", and disliked how 
it read then.  So, no, I won't apply such a patch.  English 
grammar changes over time to match what careful English 
speakers actually use, so I'll view this is a crusade to stamp 
out effete elitism -- "data are" my ass .

--

Comment By: gyrof (gyrof)
Date: 2005-03-30 21:51

Message:
Logged In: YES 
user_id=1249584

It is a very minor issue, but the change is not arguable
from the perspective of correct English grammar.

If I submit a diff, will it (eventually) be reviewed or applied?

-gyro

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-30 20:46

Message:
Logged In: YES 
user_id=80475

Sorry.  Am closing this to eliminate noise from the tracker.
 The grammar nit arguable and inconsequential (because it is
not in the main documentation and is readable as-ias).

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 19:06

Message:
Logged In: YES 
user_id=593130

While I agree that 'data are' when 'data' is used in isolation, I can 
see combinations such as 'list data' being equivalent to 'dataset', 
which 'is'.  So I would have to see examples of context to be sure 
I agreed with your recommendation.

In any case, listsort.txt is an optional implementation note and not 
part of the official reference docs (and not accessible that I know 
of via docs.python.org).  Hence, a fix, even if agreed to, would 
have very low priority unless Tim or a doc maven got 'bugged' by 
it.  Are you willing to make a revised file and a diff that would 
verify that only appropriate changes were made?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173407&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1168427 ] Possible windows+python bug

[SourceForge.net]

Bugs item #1168427, was opened at 2005-03-22 10:38
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 21:04

Message:
Logged In: YES 
user_id=593130

If there is no problem in Python itself, then perhaps you could 
close this.

--

Comment By: holo9 (holo9)
Date: 2005-03-30 16:15

Message:
Logged In: YES 
user_id=1244385

I tested this on Python 2.3.4. But there is no problem in 
Python. This bug could be reproduced in C, for example. The 
main problem is in Windows built-in firewall. For explanation 
take a look at:

http://seclist.org/lists/bugtraq/2005/Mar/0409.html

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 14:37

Message:
Logged In: YES 
user_id=593130

Do you get the same problem with either of the current releases 
(2.3.5 and/or 2.4.1)?

--

Comment By: logistix (logistix)
Date: 2005-03-23 21:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1173773 ] multiple broken links in profiler docs

[SourceForge.net]

Bugs item #1173773, was opened at 2005-03-30 18:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173773&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: multiple broken links in profiler docs

Initial Comment:
I'm looking at  
http://www.python.org/doc/current/lib/lib.html

and multiple links in profiler section seem to be broken:

10.1 Introduction...  (Error 404)
http://www.python.org/doc/current/lib/node434.html

10.2 How is this profiler different: (Error 404)
http://www.python.org/doc/current/lib/node435.html
 
10.3. What's is deterministic... (leads to wrong page)
http://www.python.org/doc/current/lib/node437.html

10.8 Extensions... (Error 404)
http://www.python.org/doc/current/lib/node442.html

10.10.1 Command Line Interface (leads to wrong page)
http://www.python.org/doc/current/lib/node448.html

10.10.2  Examples (Error 404)
http://www.python.org/doc/current/lib/node449.html

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1173773&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1170311 ] zipfile UnicodeDecodeError

[SourceForge.net]

Bugs item #1170311, was opened at 2005-03-25 02:51
Message generated for change (Comment added) made by adamx97
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: adam davis (adamx97)
Assigned to: Nobody/Anonymous (nobody)
Summary: zipfile UnicodeDecodeError

Initial Comment:
I think this is the same as #  705295, which may have
been prematurely closed.

I think the error is dependent on the data or time.

File "C:\Python24\lib\zipfile.py", line 166, in FileHeader
return header + self.filename + self.extra
UnicodeDecodeError: 'ascii' codec can't decode byte
0xd0 in position 10: ordinal not in range(128)

The header is packed like this:
header = struct.pack(structFileHeader,
stringFileHeader,
 self.extract_version, self.reserved,
self.flag_bits,
 self.compress_type, dostime, dosdate, CRC,
 compress_size, file_size,
 len(self.filename), len(self.extra))

the header is:

[Dbg]>>> header
'PK\x03\x04\x14\x00\x00\x00\x00\x00\xd0\xa9x2\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00-\x00\x00\x00'

and here are the parts that made it up:

[Dbg]>>> structFileHeader, stringFileHeader,
self.extract_version, self.reserved,
self.flag_bits,self.compress_type, dostime, dosdate,
CRC, compress_size, file_size, len(self.filename),
len(self.extra)
('<4s2B4HlLL2H', 'PK\x03\x04', 20, 0, 0, 0, 43472,
12920, 0, 0, 0, 45, 0)


here's the pieces of the 

--

>Comment By: adam davis (adamx97)
Date: 2005-03-31 03:51

Message:
Logged In: YES 
user_id=175166

The "here's the pieces of the" was an accident, you can
ignore it.

My filename was pure ascii, something like
"[EMAIL PROTECTED]"

It seems to me the problem is that the header isn't
decodable.  0xd0 is  208, which is > 128.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-03-30 19:27

Message:
Logged In: YES 
user_id=38388

The problem is not the data in the file, but the fact that
your filename is probably a Unicode object which fails to
concatenate with the header (which clearly isn't ASCII :-).

I have no idea whether ZIP files support anything other than
ASCII filenames. If you have a reference, please let us know.

If your filename only contains ASCII characters, you should
be able to open the file correctly by first encoding the
filename to ASCII: filename.encode('ascii').
Perhaps zipfile.py should do that for you ?!


--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 18:39

Message:
Logged In: YES 
user_id=593130

Your report ends with 'here's the pieces of the'.  Was something 
cut off?  If you meant to attach a file, try again.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170311&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1168427 ] Possible windows+python bug

[SourceForge.net]

Bugs item #1168427, was opened at 2005-03-22 16:38
Message generated for change (Settings changed) made by holo9
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470

Category: Windows
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: holo9 (holo9)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible windows+python bug

Initial Comment:
This bug is produced on WindowsXP SP1 (OSVer : 
5_1_2600) with Python2.3 installed.

Start Python and type (of course x.x.x.x should be 
replaced with IP address):

import socket
s=socket.socket(socket.AF_INET,socket.SOCK_RAW,4)
s.sendto("",("x.x.x.x",0))

Press ENTER and your win box should crash immediately.
On my test after restart windows returned BCCode : d1.

By the way, IP protocol 0x04 is "IP over IP", and I 
could send such datagrams month ago with Python 
(although Microsoft has crippled some protocols).
Now, this is maybe specific to this configuration, or 
it could be due to some driver (BCCode: d1 is specific 
for drivers related problems). It needs further 
testing on different configurations.
Note that the problem doesn't appears when string in 
sendto() function is not empty.


--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-31 04:04

Message:
Logged In: YES 
user_id=593130

If there is no problem in Python itself, then perhaps you could 
close this.

--

Comment By: holo9 (holo9)
Date: 2005-03-30 23:15

Message:
Logged In: YES 
user_id=1244385

I tested this on Python 2.3.4. But there is no problem in 
Python. This bug could be reproduced in C, for example. The 
main problem is in Windows built-in firewall. For explanation 
take a look at:

http://seclist.org/lists/bugtraq/2005/Mar/0409.html

--

Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-30 21:37

Message:
Logged In: YES 
user_id=593130

Do you get the same problem with either of the current releases 
(2.3.5 and/or 2.4.1)?

--

Comment By: logistix (logistix)
Date: 2005-03-24 03:18

Message:
Logged In: YES 
user_id=699438

Running your reproducable on XP SP2 (with real IP) returns
"socket.error: (10022, 'Invalid argument')" for me without a
hard crash.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168427&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1163563 ] Sub threads execute in restricted mode

[SourceForge.net]

Bugs item #1163563, was opened at 2005-03-15 03:56
Message generated for change (Comment added) made by goatpunch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470

Category: Threads
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: anothermax (yetanothermax)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sub threads execute in restricted mode

Initial Comment:
I'm using the JEP product which allows integration
of Java with Python (see http://jepp.sourceforge.net) via
starting a Python interpreter in the same process as the 
JVM.
This integrates with python via the C interface, allowing 
the user to 'eval' python code (amongst other features).

It seems that since Python 2.3.5 any threads (using the 
threading module) created via code that has been 
evaluated through the jep.eval() interface (i.e.Python C 
interface )are executed in restricted mode and cannot, 
for example, create files. Code that is just evaled (i.e not 
in a subthread) thread has no restrictions.

The error reported is:
IOError: file() constructor not accessible in restricted 
mode

(see http://sourceforge.net/forum/forum.php?
thread_id=1247793&forum_id=376782) - I've given a JEP 
specific example here.

There seems to be a similar problem with mod_python
(see 
http://www.modpython.org/pipermail/mod_python/2005-
January/017129.html)

Reading through the release notes for Python 2.3.5
I see:
 Bug #754449: threading.Thread will no longer mask 
exceptions raised during interpreter shutdown with 
another exception caused by attempting to output the 
initial exception. This fix also includes a backport of rev. 
1.41 from HEAD. 

This might be the problem as it seems to involve the 
porting of 2.4 threading code back to the 2.3 tree.

I've attached a Java file which shows the problem when 
using JEP.
The error output is:
Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Python24\Lib\threading.py", line 442, in 
__bootstrap
  File "", line 5, in run
IOError: file() constructor not accessible in restricted 
mode

2.4.1c1 (#63, Mar 10 2005, 10:36:41) [MSC v.1310 32 
bit (Intel)]
Creating file from main thread...
Done
Creating file from sub thread...
Done


--

Comment By: Alan Davies (goatpunch)
Date: 2005-03-31 01:24

Message:
Logged In: YES 
user_id=967140

The same problem definately does occur with mod_python, 
I've found it to occur with Python 2.3.5 and 2.4 on Win32:

http://www.modpython.org/pipermail/mod_python/2005-
March/017802.html

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163563&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com