[ python-Bugs-1475009 ] Document os.path.join oddity on Windows

[SourceForge.net]

Bugs item #1475009, was opened at 2006-04-23 16:08
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=1475009&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Document os.path.join oddity on Windows

Initial Comment:
Please document that on windows
os.path.join("m:\\noo", "\\woo") => '\\woo'

>From reading the code I see that this is intetional,
however it need to be documented.


--

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

[ python-Bugs-1475080 ] example code in what's new/sqlite3 docs

[SourceForge.net]

Bugs item #1475080, was opened at 2006-04-23 12:51
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=1475080&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: James Pryor (jpryor68)
Assigned to: Nobody/Anonymous (nobody)
Summary: example code in what's new/sqlite3 docs

Initial Comment:
The documentation at


contains the following example code:


# Never do this -- insecure!
symbol = 'IBM'
c.execute("... where symbol = '%s'" % symbol)

# Do this instead
t = (symbol,)
c.execute('select * from stocks where symbol=?', ('IBM',))


The second block should instead read:


# Do this instead
t = ('IBM',)
c.execute('select * from stocks where symbol=?', t)



--

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

[ python-Bugs-1475009 ] Document os.path.join oddity on Windows

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: Document os.path.join oddity on Windows

Initial Comment:
Please document that on windows
os.path.join("m:\\noo", "\\woo") => '\\woo'

>From reading the code I see that this is intetional,
however it need to be documented.


--

>Comment By: Tim Peters (tim_one)
Date: 2006-04-23 13:38

Message:
Logged In: YES 
user_id=31435

Noting that there's nothing special about Windows here:

>>> import posixpath
>>> posixpath.join('/noo', '/woo')
'/woo'


--

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

[ python-Bugs-1475162 ] Tkinter hangs in test_tcl

[SourceForge.net]

Bugs item #1475162, was opened at 2006-04-23 23:34
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=1475162&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Wouters (twouters)
Assigned to: Martin v. Löwis (loewis)
Summary: Tkinter hangs in test_tcl

Initial Comment:

For a while now, I've noticed test_tcl locking up when
trying to refleaktest it. I was able to reproduce it
quite simply:

import Tkinter, os
if "DISPLAY" in os.environ: del os.environ["DISPLAY"]
tcl = Tkinter.Tcl()
try: tcl.loadtk()
except Exception, e: print e
tcl.loadtk()

Or using _tkinter directly:

import _tkinter, os
if "DISPLAY" in os.environ: del os.environ["DISPLAY"]
tk = _tkinter.create(None, "test", "Tk", 0, 1, 0)
try: tk.loadtk()
except: pass
tk.loadtk()

In either case, the second loadtk never finishes.

It seems that, on my platform at least, Tk_Init()
doesn't like being called twice even when the first
call resulted in an error. That's Tcl and Tk 8.4.12.
Tkapp_Init() (which is the Tkinter part that calls
Tk_Init()) does its best to guard against calling
Tk_Init() twice when the first call was succesful, but
it doesn't remember failure cases. I don't know enough
about Tcl/Tk or Tkinter to know how this is best handled.


--

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

[ python-Bugs-1472173 ] interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian

[SourceForge.net]

Bugs item #1472173, was opened at 2006-04-18 11:20
Message generated for change (Comment added) made by twouters
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1472173&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Installation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: kxroberto (kxroberto)
Assigned to: Nobody/Anonymous (nobody)
Summary: interactive: no cursors ctrl-a/e... in 2.5a1/linux/debian

Initial Comment:

cursors , ctrl-a ctrl-e ... not recognized? worked with
previous pythons

vs:/usr/src/Python-2.5a1# make altinstall
...
vs:/usr/src/Python-2.5a1# python2.5
Python 2.5a1 (r25a1:43589, Apr 15 2006, 21:51:42)
[GCC 3.3.5 (Debian 1:3.3.5-13)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> abcd^E^A^[[1~^[[4~




--

>Comment By: Thomas Wouters (twouters)
Date: 2006-04-24 00:49

Message:
Logged In: YES 
user_id=34209

Closing as fixed then :)



--

Comment By: kxroberto (kxroberto)
Date: 2006-04-19 11:11

Message:
Logged In: YES 
user_id=972995

oops, is ok after:

apt-get install libreadline5-dev


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2006-04-19 06:16

Message:
Logged In: YES 
user_id=33168

Hmmm, it's possible some of the configure magic changed.  It
might have been inadvertant.  Can you attach your
config.log?   When you did a ./configure it should have
printed out some things about readline and searching for it.
 That might help you diagnose the problem.

--

Comment By: Michael Hudson (mwh)
Date: 2006-04-18 11:32

Message:
Logged In: YES 
user_id=6656

You might need to install readline-devel or some such package.  I don't think 
anything has changed in python here...

--

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

[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Matt Fleming (splitscreen)
>Assigned to: Georg Brandl (gbrandl)
Summary: Python does not check for POSIX compliant open() modes

Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().

According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.

This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.

--

>Comment By: Tim Peters (tim_one)
Date: 2006-04-23 21:19

Message:
Logged In: YES 
user_id=31435

This is still ;-) fine with me.  There doesn't seem to be a
test in fileobject2.diff.  WRT the docs, "must either be"
should say "must be one of" instead ("either" is proper for
two choices, but there are three).  It should state that
this requirement is new in Python 2.5; in LaTeX, something like

\versionchanged[Restriction on first letter of mode string
introduced]{2.5}

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-12 06:14

Message:
Logged In: YES 
user_id=1126061

Yeah, your patch looks much better.

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-06 04:15

Message:
Logged In: YES 
user_id=849994

splitscreen: your patch was incomplete and could have
overwritten memory.

tim_one: Attaching new patch implementing what I proposed in
my comment below.

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 16:59

Message:
Logged In: YES 
user_id=1126061

Ok, uploading latest patch, not quite sure I've hit the mark
here.

Please review.


--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 15:43

Message:
Logged In: YES 
user_id=849994

Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 14:32

Message:
Logged In: YES 
user_id=1126061

Ignore my question, it's for "universal newlines", right? 

Have I understood your proposal correctly in that you want
to remove the 'U' from the mode? 

--

Comment By: Matt Fleming (splitscreen)
Date: 2006-04-01 09:14

Message:
Logged In: YES 
user_id=1126061

That seems sensible. What does a mode containing 'U' mean
anyway?

--

Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 02:08

Message:
Logged In: YES 
user_id=849994

Instead of this patch, I'd rather like check_the_mode to

* remove any 'U' from the mode string
* if 'U' was found:
  * error out if the new string begins with 'w' or 'a'
  * add a 'r' and 'b' if it isn't already given
* if not:
  * error out if the string doesn't begin with 'w', 'r', 'a'

What do you think of it?

--

Comment By: Tim Peters (tim_one)
Date: 2006-03-31 13:03

Message:
Logged In: YES 
user_id=31435

There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed.  I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").

All that said, I'm in favor of this patch ;-).  However, if
it goes in two things are needed:

1. The error message should be more informative, like

   PyErr_Format(PyExc_ValueError, "mode argument must "
 "begin with 'w', 'r', or 'a', not '%.200s'", mode);

2. The Python docs should change to match (i.e., the
   manual should document this new restriction on mode
   strings).

WRT the test case, it's more natural to write, e.g.,

TESTFN in s

than

s.find(TESTFN) != -1

--

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

[ python-Bugs-1293741 ] doctest runner cannot handle non-ascii characters

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: GRISEL (ogrisel)
>Assigned to: Nobody/Anonymous (nobody)
Summary: doctest runner cannot handle non-ascii characters 

Initial Comment:
The doctest module fails when the expected result
string has non-ascii charcaters even if the # -*-
coding: XXX -*- line is properly set.

The enclosed code sample produce the following error:

Traceback (most recent call last):
  File "test_iso-8859-15.py", line 41, in ?
_test()
  File "test_iso-8859-15.py", line 26, in _test
tried, failed = runner.run(t)
  File "/usr/lib/python2.4/doctest.py", line 1376, in run
return self.__run(test, compileflags, out)
  File "/usr/lib/python2.4/doctest.py", line 1259, in __run
if check(example.want, got, self.optionflags):
  File "/usr/lib/python2.4/doctest.py", line 1475, in
check_output
if got == want:
UnicodeDecodeError: 'ascii' codec can't decode byte
0xe9 in position 8: ordinal not in range(128)



--

>Comment By: Tim Peters (tim_one)
Date: 2006-04-23 21:21

Message:
Logged In: YES 
user_id=31435

Unassigned myself -- don't know enough about encodings.

--

Comment By: Bjorn Tillenius (bjoti)
Date: 2006-02-16 06:41

Message:
Logged In: YES 
user_id=1032069

I'm quite sure that you can use non-ASCII characters in 
your doctest, given that it's a unicode string. So if you 
make your docstring a unicode string, it should work. That 
is:

u"""Docstring containing non-ASCII characters.
...
"""


--

Comment By: GRISEL (ogrisel)
Date: 2005-09-18 06:25

Message:
Logged In: YES 
user_id=795041

Unfortunateny that patch does not fix my problem. The patch
at bug #1080727 fixes the problem for doctests written in
external reST files (testfile and DocFileTest functions). My
problem is related to internal docstring encoding (testmod
for instance). However, Bjorn Tillenius says:
"""
If one writes doctests within documentation strings of
classes and
functions, it's possible to use non-ASCII characters since
one can
specify the encoding used in the source file.
"""
So according to him, docstrings' doctests with non-ascii
characters should work by default. So maybe my system setup
is somewhat broken. Could somebody please confirm/infirm
this by running the attached sample script on his system?

My system config:
[EMAIL PROTECTED] (on linux)
python 2.4.1 with:  sys.getdefaultencoding() == 'ascii' 
and locale.getpreferredencoding() == 'ISO-8859-15'
$ file test_iso-8859-15.py
test_iso-8859-15.py: ISO-8859 English text


--

Comment By: Tim Peters (tim_one)
Date: 2005-09-17 13:42

Message:
Logged In: YES 
user_id=31435

Please try the patch at

http://www.python.org/sf/1080727

and report back on whether it solves your problem (attaching 
comments to the patch report would be most useful).

--

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

[ python-Bugs-777597 ] socketmodule.c connection handling incorect on windows

[SourceForge.net]

Bugs item #777597, was opened at 2003-07-25 11:01
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777597&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth Bushell (garth42)
>Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c connection handling incorect on windows

Initial Comment:
The socketmodule.c code does not handle connection
refused correctly. This is due to a different of
operation on windows of select. The offending code is
in internal_connect in the MS_WINDOWS ifdef. The code
in should test  exceptfds to check for connecttion
refused. If this is so itshould call
getsockopt(SOL_SOCKET, SO_ERROR,..) to get the error
status. (Source microsoft Platform SDK)
The suggested fix is shown below (untested)

#ifdef MS_WINDOWS

f (s->sock_timeout > 0.0) {
if (res < 0 && WSAGetLastError() == WSAEWOULDBLOCK) {
/* This is a mess.  Best solution: trust select */
fd_set exfds;
struct timeval tv;
tv.tv_sec = (int)s->sock_timeout;
tv.tv_usec = (int)((s->sock_timeout - tv.tv_sec) * 1e6);
FD_ZERO(&exfds);
FD_SET(s->sock_fd, &exfds);
/* Platform SDK says so */
res = select(s->sock_fd+1, NULL, NULL, &exfds, &tv);
if (res > 0) { 
if( FD_ISSET( &exfds ) ) {
/* Get the real reason */

getsockopt(s->sock_fd,SOL_SOCKET,SO_ERROR,(char*)&res,sizeof(res));
} else {
/* God knows how we got here */
res = 0;
}
} else if( res == 0 ) {
res = WSAEWOULDBLOCK;
} else
{ 
/* Not sure we should return the erro from select? */
res =  WSAGetLastError();
}
}
} else if (res < 0)
res = WSAGetLastError();

#else

--

>Comment By: Tim Peters (tim_one)
Date: 2006-04-23 21:26

Message:
Logged In: YES 
user_id=31435

Unassigned myself (no particular competence here, and short
on time).

--

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-08 04:48

Message:
Logged In: YES 
user_id=32863

http://python.org/sf/965036 has been updated with a fixed
and tested patch. Could somebody review and apply it? Thanks!


--

Comment By: Troels Walsted Hansen (troels)
Date: 2004-06-02 09:59

Message:
Logged In: YES 
user_id=32863

I have turned Garth's code into a patch versus Python 2.3.4.
I don't believe the fix is correct and complete, but it
should serve as a starting point. Patch is in
http://python.org/sf/965036


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-07-28 18:00

Message:
Logged In: YES 
user_id=33168

Garth could you produce a patch against 2.3c2 with your
selected change and test it?  It would help us a lot as we
are all very overloaded.  Thanks.

--

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

[ python-Bugs-1337990 ] doctest mishandles exceptions raised within generators

[SourceForge.net]

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Wegener (twegener)
>Assigned to: Nobody/Anonymous (nobody)
Summary: doctest mishandles exceptions raised within generators

Initial Comment:
If a generator raises an exception while iterating over it, doctest 
will only register the exception output, and will miss output that 
occurred during previous loop iterations.

The following code clarifies and reproduces the problem:
(also included as an attachment)

"""Reproduce bug with exceptions in a generator in doctest tests.

This bug has been seen to occur in:

Linux (RH9):
Python 2.4.1
Python 2.3.5
Python 2.2.2 (using from __future__ import generators)

Windows XP:
Python 2.4.2
Python 2.3.5

"""

def error_generator():
"""Yield 0 to 2 and then try and raise an exception.

>>> for j in error_generator():
...print j
0
1
2
Traceback (most recent call last):
Exception: Contrived exception for sake of example

"""
# Note: This is obviously a contrived example of generator use.
for i in range(3):
yield i

if 1:
raise Exception("Contrived exception for sake of example")

raise StopIteration


if __name__ == '__main__':
# Run the doctest tests.
import sys
import doctest
doctest.testmod(sys.modules['__main__'])

print
print 'What should have happened...'
for j in error_generator():
print j



--

>Comment By: Tim Peters (tim_one)
Date: 2006-04-23 22:13

Message:
Logged In: YES 
user_id=31435

doctest doesn't support mixing "expected normal output" with
an exception, regardless of how such a thing may arise.  For
example, this one-liner can't work either as a doctest:

>>> print 'hi', 1/0
hi
Traceback (most recent call last):
  File "", line 1, in 
ZeroDivisionError: integer division or modulo by zero

So there's nothing specific to generators in this, rather
it's a doctest limitation.  The docs do say, wrt testing
exceptions:

"""
No problem, provided that the traceback is the only output
produced by the example:  just paste in the traceback.
"""

In any case, it wasn't intended that doctest support this,
and the docs do try to communicate that.  I added text
spelling out the other half (if there's expected output in
addition to the traceback, problem ;-)), in rev 45677 on the
trunk and rev 45678 on the 2.4 branch, and am closing this
report as a doc bug.

Edward Loper tried supporting this, as a new feature, before
2.4 was released, but it so grossly complicated the docs and
the implementation that we agreed to drop it.  So you could
 re-open this as a feature request, but it's unlikely to change.


--

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