[issue1311] os.path.exists(os.devnull) regression on windows

[David Kågedal]

David Kågedal added the comment:

I tried it on two different machines, and got two different answers:

conan$ /cygdrive/c/Python25/python -c 'import os.path; print
os.path.exists("nul")'
False
conan$ /cygdrive/c/Python24/python -c 'import os.path; print
os.path.exists("nul")'
False

conan$ /cygdrive/c/Python24/python -c 'import os; print os.stat("nul")'
Traceback (most recent call last):
  File "", line 1, in ?
OSError: [Errno 22] Invalid argument: 'nul'
conan$ /cygdrive/c/Python25/python -c 'import os; print os.stat("nul")'
Traceback (most recent call last):
  File "", line 1, in 
WindowsError: [Error 87] The parameter is incorrect: 'nul'


titti$ /cygdrive/c/Python24/python -c 'import os.path; print
os.path.exists("nul")'
True
titti$ /cygdrive/c/Python25/python -c 'import os.path; print
os.path.exists("nul")'
False

titti$ /cygdrive/c/Python24/python -c 'import os; print os.stat("nul")'
(33206, 0L, 3, 1, 0, 0, 0L, -1, -1, -1)
titti$ /cygdrive/c/Python25/python -c 'import os; print
os.stat("nul")'Traceback (most recent call last):
  File "", line 1, in 
WindowsError: [Error 87] The parameter is incorrect: 'nul'

I ran it from a cygwin prompt, but the pythons are native.

So you are correct that it doesn't work as I expected in Python 2.4
either on the "conan" host..  On "titti", there is a difference in how
os.path.exist works between 2.4 and 2.5. On "conan" there is actually
also a difference, but only in the exception raised by os.stat.

I don't know what the differences between these installation are.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1314] Patch for strftime problem on German Windows

[Christian Heimes]

New submission from Christian Heimes:

The patch fixes the failing unit tests for time and strptime on German
and probably other Windows installations.

-   ret = PyUnicode_FromStringAndSize(outbuf, buflen);
+   ret = PyUnicode_Decode(outbuf, buflen,
+  TZNAME_ENCODING, NULL);

--
components: Extension Modules
files: py3k_win_strftime.patch
messages: 56675
nosy: tiran
severity: normal
status: open
title: Patch for strftime problem on German Windows
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file8595/py3k_win_strftime.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Modules/timemodule.c
===
--- Modules/timemodule.c	(revision 58603)
+++ Modules/timemodule.c	(working copy)
@@ -528,7 +528,8 @@
 			   e.g. an empty format, or %Z when the timezone
 			   is unknown. */
 			PyObject *ret;
-			ret = PyUnicode_FromStringAndSize(outbuf, buflen);
+			ret = PyUnicode_Decode(outbuf, buflen, 
+	   TZNAME_ENCODING, NULL);
 			PyMem_Free(outbuf);
 			return ret;
 		}
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1298] Support for z/OS and EBCDIC.

[Jean-Yves MENGANT]

Jean-Yves MENGANT added the comment:

Let me provide my contribution to this discussion around this ZOS port
topic :
I initially made the Python 2.2 and 2.4 for ZOS platform and ask the
python community to link to my pages as a support to ZOS at that time 

Lauri get in touch with me couple of weeks ago asking if I was planning
to make a port of the 2.5 ; since I was waiting for 2.6 before
initiating a new port, He goes ahead and makes the 2.5 port happen now.

About how important is the ZOS system ; let me argue around that :  even
if ZOS is an IBM proprietary OS which
has been there for decades it will be there for a long time since it
occupies a very specific 'niche' on the os'es market 
And since IBM has heavily spoiled the migration path to Unix in order to
keep its revenues on it migrating those 
systems to plain vanilla unixes is a nightmare => Today every US or
European big company s having a ZOS sytem somewhere. 
Next even if ZOS is proprietary and EBCDIC it has a peasonable POSIX.5
compliant subsystem and a descent C/C++ compiler
which makes the port of python not too complex.

>From a script standpoint there are today 3 available scripting languages
availables :
- REXX (the mike cowlishaw script language) , perl and python)

So keeping an accurate version of python on this platform makes sense as
well to increase the python language usage

Next I am still happy  to continue supporting the ZOS port and I
perfectly understand that fully integrating the ZOS idiosynchrasies 
into the Python main branch generates maintenability problems ... But
some of the submitted problems included into Lauri patch are not ZOS
specific and increase 
and simply increase the portability of the python Kernel  to EBCDIC
platform(ZOS and OS400) 

So finally my opinion here is the the problem can be splitted into two
parts :

1 General improvements patches which improves the Python kernel which
can be incorporated in the python kernel and which 
may not be to complicated to maintain on the main branch

2 ZOS idiosynchrasies (mainly located in making the autoconf/automake
and build scripts compliant with ZOS ); this can be done specifically by 
zos python specialists which have access to ZOS mainframe in order to be
able to test.

I am happy to continue to make the topic 2 availables on the ZOS python
port pages with the help of others contributors like Lauri and 
give them credit on the ZOS port page. So I propose to integrate lauri's
patch in the 2.5.1 current and provide a modified ZOS compliant 
source tar containing modified autoconf/automake and dynamic loading stuff

I Finally should emphazise on 2 complementary arguments : 

- The ZOS port has been used in industrial products(including the
company for which I work today) and contributes to promote 
the python language on important non unix platforms showing the extreme
portability of the language.
- Even the IBM Labs in Boulder(colorado) get in touch with me in order
to integrate the port in one of their project.

--
nosy: +JYMEN

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1286] fileinput, StringIO, and cStringIO do not support the with protocol

[Georg Brandl]

Georg Brandl added the comment:

Makes sense to me.

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg

[Derek Shockey]

Derek Shockey added the comment:

I'm really sorry I didn't notice this earlier, but RCPT has the same bug! 
This patch applies the same fix to that function as well.

Added file: http://bugs.python.org/file8597/smtpd-patch2.diff

__
Tracker <[EMAIL PROTECTED]>

__

smtpd-patch2.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1253] IDLE - Percolator overhaul

[Tal Einat]

Tal Einat added the comment:

The change required for Squeezer and ShellLogger is the separation of
the Tk Text specific logic into a subclass, which makes Percolator a
generally useful class. Along with the simple patch to Delegator.py
which allows delegation to callables, this change allows one to replace
a method with a Percolator instance.

I want to do this for EditorWindow.write, since both Squeezer and
ShellLogger need to hook onto this call somehow. Furthermore,
ShellLogger must catch this call before Squeezer does, since Squeezer
may change the output, but the original output should pass through
ShellLogger first.

Since there is no way to control the order in which extensions are
loaded, this constraint must be enforced by the extensions themselves.
Using the patched Percolator is the simplest way I could come up with to
support this. (IMHO adding a constraint solver for extensions at this
point would be overkill.)

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1315] Bug in pstats.print_callers

[Guido van Rossum]

Guido van Rossum added the comment:

This will get more attention if you suggest a patch...

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1256] subprocess Popen wait() function hangs when stdout is > 20480

[Raghuram Devarakonda]

Raghuram Devarakonda added the comment:

PIPE on POSIX are implemented using pipe system call so it will have all
the limitations of the system buffering that is used for implementing
pipes. The buffer size is system dependent. For example, on my Linux, I
hit the hang condition at 64K and not 20480 bytes (as is your case).
What basically happens is that the child fills up the pipe buffer and is
blocked until space is available. Since the parent in your test script
is not reading the bytes, space will never be freed up. 

I suggest that the bug is closed as invalid.

--
nosy: +draghuram

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1314] Patch for strftime problem on German Windows

[Martin v. Löwis]

Changes by Martin v. Löwis:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1298] Support for z/OS and EBCDIC.

[Martin v. Löwis]

Martin v. Löwis added the comment:

Jean-Yves, please understand that no amount of discussion can likely
change Guido's or my view on this patch. We both fully understand the
relevance of OS/390, and *still* reject it, for the reasons discussed.

Besides, integration into 2.5.1 is not possible, as it would violate our
maintenance policy of not integrating new features into bug fix (2.x.y)
releases. Integrating it into 2.6 might be possibly technically, but
could be a waste of time since 2.x will shortly (i.e. within a few
years) reach the end of its life. I doubt that the patch as it stands
will work correctly on 3.x (as *that* stands).

As you seem to be proposing that supporting EBCDIC will be "easy", just
try to port the patch to 3.x to see how this assumption is wrong. In
Python 3.x, Python source code *cannot* be interpreted as EBCDIC,
without an encoding declaration, since the language specification says
that the source code is UTF-8; there is no room for platform-specific
derivations from that default. Also consider Guido's discussion of the
networking code; unless you can report that httplib and ftplib work
correctly, I doubt that the port is really complete.

So I think the only choice is to maintain this port outside of the
Python source tree, for a few more years. If you plan to contribute it
again to the Python core some day, please keep track of all the
individual contributors, as we will then require copyright agreements
from everyone.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1311] os.path.exists(os.devnull) regression on windows

[Kevin Dwyer]

Kevin Dwyer added the comment:

I tried this under Python 2.3.3, 2.5.1 (native) and 2.3.4 (cygwin).  The
operating system is Windows 2000 SP4.

C:\Python23>python
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC v.1200 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> print os.path.exists('nul')
True

C:\Python25>python
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> print os.path.exists('nul')
False

$ python
Python 2.3.4 (#1, Jun 13 2004, 11:21:03)
[GCC 3.3.1 (cygming special)] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os.path
>>> print os.path.exists('nul')
True

So there does seem to be a change in behaviour at 2.5.

--
nosy: +kdwyer

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1316] fix a few PyInt_Check vs PyLong_Check problems

[Georg Brandl]

New submission from Georg Brandl:

This fixes a few places where PyInt_Check and PyLong_Check are used
redundantly, and where the checks must be changed now that there's only
PyLong.

--
assignee: gvanrossum
files: long_check.diff
keywords: patch, py3k
messages: 56685
nosy: georg.brandl, gvanrossum
severity: normal
status: open
title: fix a few PyInt_Check vs PyLong_Check problems
versions: Python 3.0
Added file: http://bugs.python.org/file8598/long_check.diff

__
Tracker <[EMAIL PROTECTED]>

__

long_check.diff
Description: PGP signature
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1303] adapt str8 constructor to bytes constructor

[Georg Brandl]

Georg Brandl added the comment:

Okay, somebody seems to have started this, so I won't interfere for now.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1316] fix a few PyInt_Check vs PyLong_Check problems

[Guido van Rossum]

Guido van Rossum added the comment:

Please check in and close -- thanks for finding these!

--
assignee: gvanrossum -> georg.brandl
resolution:  -> accepted

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1317] smtplib.SMTP docs

[Fred L. Drake, Jr.]

New submission from Fred L. Drake, Jr.:

The docstring for the smtplib.SMTP class includes descriptions of some
instance attributes that are not covered by the documentation:

  does_esmtp
  ehlo_resp
  esmtp_features
  helo_resp

If these are intended as part of the public interface, they should be
documented in the .tex/.rst documentation, otherwise their descriptions
should be in a comment instead of a docstring.  (helo_resp is mentioned
in Misc/HISTORY, if that actually means anything.)

--
components: Documentation
messages: 56688
nosy: fdrake
severity: normal
status: open
title: smtplib.SMTP docs
type: rfe
versions: Python 2.5, Python 2.6, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1316] fix a few PyInt_Check vs PyLong_Check problems

[Georg Brandl]

Georg Brandl added the comment:

Committed r58617.

--
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 58618.

There better not be any others. :-)

Neal, can you add this to 2.5.2 and then close?

--
assignee: gvanrossum -> nnorwitz
status: closed -> open

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1312] doctest EXCEPTION_RE can't handle preceding output

[Guido van Rossum]

Changes by Guido van Rossum:


--
assignee:  -> tim_one
nosy: +tim_one

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1314] Patch for strftime problem on German Windows

[Guido van Rossum]

Guido van Rossum added the comment:

Committed revision 58619.

--
assignee:  -> gvanrossum
nosy: +gvanrossum
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1755179] Deadlocks with fork() and multithreading

[Facundo Batista]

Changes by Facundo Batista:


--
assignee:  -> facundobatista
nosy: +facundobatista

_
Tracker <[EMAIL PROTECTED]>

_
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1311] os.path.exists(os.devnull) regression on windows

[Kevin Dwyer]

Kevin Dwyer added the comment:

Ok, it seems that Python 2.5 implements two new functions
Py_GetFileAttributesExA and Py_GetFileAttributesExW in posixmodule.c
within the #ifdef MS_WINDOWS block that may return
ERROR_INVALID_PARAMETER to os.stat, which will percolate WindowsError up
to os.exists():

In both functions we find:

static BOOL WINAPI
Py_GetFileAttributesExA(LPCSTR pszFile, 
   GET_FILEEX_INFO_LEVELS level,
   LPVOID pv)
{
BOOL result;
LPWIN32_FILE_ATTRIBUTE_DATA pfad = pv;
/* First try to use the system's implementation, if that is
   available and either succeeds to gives an error other than
   that it isn't implemented. */
check_gfax();
if (gfaxa) {
result = gfaxa(pszFile, level, pv);
if (result || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED)
return result;
}
/* It's either not present, or not implemented.
   Emulate using FindFirstFile. */
if (level != GetFileExInfoStandard) {
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
...


static BOOL WINAPI
Py_GetFileAttributesExW(LPCWSTR pszFile, 
   GET_FILEEX_INFO_LEVELS level,
   LPVOID pv)
{
BOOL result;
LPWIN32_FILE_ATTRIBUTE_DATA pfad = pv;
/* First try to use the system's implementation, if that is
   available and either succeeds to gives an error other than
   that it isn't implemented. */
check_gfax();
if (gfaxa) {
result = gfaxw(pszFile, level, pv);
if (result || GetLastError() != ERROR_CALL_NOT_IMPLEMENTED)
return result;
}
/* It's either not present, or not implemented.
   Emulate using FindFirstFile. */
if (level != GetFileExInfoStandard) {
SetLastError(ERROR_INVALID_PARAMETER);
return FALSE;
...

I'm neither a C nor a win32api programmer - can anyone explain the
purpose of this code?

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1318] Remove os.tmpnam() and os.tempnam() [patch]

[Christian Heimes]

New submission from Christian Heimes:

I couldn't stand the compiler warnings any more. :)

The patch removes os.tmpnam() and os.tempnam() from the posix module. It
also updates the docs and tests. TMP_MAX is kept for the tempfile
module. I haven't figured out how to remove the defines from pyconfig.h.
I guess they are always added by autoconf/automake.

--
components: Documentation, Extension Modules
files: py3k_remove_os_tmpnam.patch
messages: 56693
nosy: tiran
severity: normal
status: open
title: Remove os.tmpnam() and os.tempnam() [patch]
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file8599/py3k_remove_os_tmpnam.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Misc/NEWS
===
--- Misc/NEWS	(revision 58619)
+++ Misc/NEWS	(working copy)
@@ -39,7 +39,10 @@
   argument was being ignored if __loader__ is defined and forcing the source to
   be UTF-8.
 
+- The `os.tmpnam()` and `os.tempnam()` methods have been removed in favor
+  of the tempfile module. Both methods were vulnerable to symlink attacks.
 
+
 What's New in Python 3.0a1?
 ==
 
Index: Doc/library/os.rst
===
--- Doc/library/os.rst	(revision 58619)
+++ Doc/library/os.rst	(working copy)
@@ -1077,53 +1077,6 @@
Create a symbolic link pointing to *src* named *dst*. Availability: Unix.
 
 
-.. function:: tempnam([dir[, prefix]])
-
-   Return a unique path name that is reasonable for creating a temporary file.
-   This will be an absolute path that names a potential directory entry in the
-   directory *dir* or a common location for temporary files if *dir* is omitted or
-   ``None``.  If given and not ``None``, *prefix* is used to provide a short prefix
-   to the filename.  Applications are responsible for properly creating and
-   managing files created using paths returned by :func:`tempnam`; no automatic
-   cleanup is provided. On Unix, the environment variable :envvar:`TMPDIR`
-   overrides *dir*, while on Windows the :envvar:`TMP` is used.  The specific
-   behavior of this function depends on the C library implementation; some aspects
-   are underspecified in system documentation.
-
-   .. warning::
-
-  Use of :func:`tempnam` is vulnerable to symlink attacks; consider using
-  :func:`tmpfile` (section :ref:`os-newstreams`) instead.
-
-   Availability: Macintosh, Unix, Windows.
-
-
-.. function:: tmpnam()
-
-   Return a unique path name that is reasonable for creating a temporary file.
-   This will be an absolute path that names a potential directory entry in a common
-   location for temporary files.  Applications are responsible for properly
-   creating and managing files created using paths returned by :func:`tmpnam`; no
-   automatic cleanup is provided.
-
-   .. warning::
-
-  Use of :func:`tmpnam` is vulnerable to symlink attacks; consider using
-  :func:`tmpfile` (section :ref:`os-newstreams`) instead.
-
-   Availability: Unix, Windows.  This function probably shouldn't be used on
-   Windows, though: Microsoft's implementation of :func:`tmpnam` always creates a
-   name in the root directory of the current drive, and that's generally a poor
-   location for a temp file (depending on privileges, you may not even be able to
-   open a file using this name).
-
-
-.. data:: TMP_MAX
-
-   The maximum number of unique names that :func:`tmpnam` will generate before
-   reusing names.
-
-
 .. function:: unlink(path)
 
Remove the file *path*.  This is the same function as :func:`remove`; the
Index: Lib/test/test_os.py
===
--- Lib/test/test_os.py	(revision 58619)
+++ Lib/test/test_os.py	(working copy)
@@ -8,9 +8,6 @@
 import sys
 from test import test_support
 
-warnings.filterwarnings("ignore", "tempnam", RuntimeWarning, __name__)
-warnings.filterwarnings("ignore", "tmpnam", RuntimeWarning, __name__)
-
 # Tests creating TESTFN
 class FileTests(unittest.TestCase):
 def setUp(self):
@@ -42,20 +39,6 @@
 open(name, "w")
 self.files.append(name)
 
-def test_tempnam(self):
-if not hasattr(os, "tempnam"):
-return
-warnings.filterwarnings("ignore", "tempnam", RuntimeWarning,
-r"test_os$")
-self.check_tempfile(os.tempnam())
-
-name = os.tempnam(test_support.TESTFN)
-self.check_tempfile(name)
-
-name = os.tempnam(test_support.TESTFN, "pfx")
-self.assertEqual(os.path.basename(name)[:3], "pfx")
-self.check_tempfile(name)
-
 def test_tmpfile(self):
 if not hasattr(os, "tmpfile"):
 return
@@ -66,34 +49,6 @@
 fp.close()
 self.assertEquals(s, b"foobar")
 
-def test_tmpnam(self):
-import sys
-if not ha

[issue1318] Remove os.tmpnam() and os.tempnam() [patch]

[Guido van Rossum]

Guido van Rossum added the comment:

Martin, why do we need to keep these when we already have tempfile.py? 
I don't see that they solve any particular POSIX compatibility
requirement.  And they *are* unsafe.  (Admitted, sometimes there's no
alternative -- even tempfile.py still provides unsafe APIs by necessity.)

--
nosy: +gvanrossum

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1319] py3k: fixes for test_ctypes

[Amaury Forgeot d'Arc]

New submission from Amaury Forgeot d'Arc:

Updates to ctypes for python 3.0 to make the tests pass.

Notable changes are:
- return bytes instead of str8
- integers in range(256) are accepted as "one char string":
libc.strchr("abcdef", 98) is now valid.
- directly use the wide-char version of the win32 function LoadLibrary.

Tested on WinXP, with Visual Studio Express 2005.

--
components: Interpreter Core
files: ctypes.diff
messages: 56696
nosy: amaury.forgeotdarc
severity: normal
status: open
title: py3k: fixes for test_ctypes
versions: Python 3.0
Added file: http://bugs.python.org/file8600/ctypes.diff

__
Tracker <[EMAIL PROTECTED]>

__

ctypes.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1318] Remove os.tmpnam() and os.tempnam() [patch]

[Christian Heimes]

Christian Heimes added the comment:

First, you are right. It's not a compiler but a linker warning.

I don't see the point in keeping the methods. They are dangerous to use,
warned upon for a long time and they have a sane replacement that does a
far better job.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1320] PCBuild8 Solution Support Changes

[Joseph Armbruster]

New submission from Joseph Armbruster:

The following observations were made of the PCBuild8 solution:

1  pyproject.vsprops was missing usermacros for tcltk / msi
2  no vcproj for ssl module like the PCBuild solution has
3  _msi project did not havea valid includedir
4  _tkinter did not have a valid includedir


Suggested Changes:


1  I would like to suggest adding macros such as the following to the
pyproject.vsprops.  These could then be referenced throughout the
associated projects.




Reasoning: To continue to promote pyproject.vsprops as being an
almost-one-stop-shop for setting relative locations of third party
libraries.  This can be done in the following way:

- tcltkDir could be used to add a valid includedir to the _tkinter project
- msinstDir could be used to add a valid includedir to the _msi project.


2  no vcproj for ssl module like the PCBuild solution has

See: pcbuild8_for_ssl.patch... The only thing left to do is add the
associated _ssl project to the vsproj.

Reasoning: To let their be a way to build the ssl module.

Note: I suppose there could have been good reason for not putting in the
_ssl module, since it uses a support .bat / .py to build (but that's for
better people to decide)


3 If 1 is satisfied, a standard includedir variable could be added


4 If 1 is satisfied, a standard includedir variable could be added


I am hesitant to submit a full patch for all of these here, since it may
be decided that some of these be treated as separate issues.  If a full
patch is desired I can submit one.

--
components: Build, Windows
files: pcbuild8_for_ssl.patch
messages: 56698
nosy: JosephArmbruster
severity: normal
status: open
title: PCBuild8 Solution Support Changes
versions: Python 2.6
Added file: http://bugs.python.org/file8601/pcbuild8_for_ssl.patch

__
Tracker <[EMAIL PROTECTED]>

__

pcbuild8_for_ssl.patch
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1307] smtpd.SMTPServer throws exception on MAIL command with no arg

[Neal Norwitz]

Neal Norwitz added the comment:

Committed revision 58625. (2.5)

--
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1318] Remove os.tmpnam() and os.tempnam() [patch]

[Martin v. Löwis]

Martin v. Löwis added the comment:

Removing them because there is a replacement already is a better reason
than removing them because they give (bogus) warnings, so I'm -0 now.

As you say, tempfile is not any better from a security point of view in
the cases where tmpnam or tempnam would be used (e.g. if you want a
child process create a file whose name you specify).

Whether the tempfile.py implementation is actually better than the one
in the C library, I cannot tell (hence the -0: I don't know whether
tempfile.py or the C library wrapper should be removed). One issue I
just noticed is that tempfile.mkstemp promise of not inheriting the file
descriptor is bogus in the presence of threads and race conditions.

If the rationale for the patch is to eliminate duplication, then
os.tmpfile should be removed as well.

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1319] py3k: fixes for test_ctypes

[Martin v. Löwis]

Martin v. Löwis added the comment:

Thomas, can you take a look? If not, please unassign.

--
assignee:  -> theller
keywords: +patch
nosy: +loewis, theller

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com