James Y Knight [EMAIL PROTECTED] writes:
On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote:
Several of these files are licensed under GPL:
aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh
ltconfig missing
Are you sure? The copies of aclocal.m4 and config-ml.in both
Thomas Heller wrote:
Is it a problem to have these files in the Python source code?
I would think so, yes. Including them in the Python distribution,
without licensing the entire Python distribution under GPL, would be
a GPL violation.
The actual libffi appears to have a fairly liberal license
On Jan 19, 2006, at 4:24 PM, Thomas Heller wrote:
Several of these files are licensed under GPL:
aclocal.m4 config-ml.in config.guess config.sub depcomp ltcf-c.sh
ltconfig missing
Are you sure? The copies of aclocal.m4 and config-ml.in both disagree
with you. aclocal seems to have a
Martin v. Löwis [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
On 1/16/06, Thomas Heller [EMAIL PROTECTED] wrote:
It looks like we need a pronouncement now.
Sorry. It appeared to me that there was general agreement to using a
strongly worded warning in the docs, so I tuned out of the
Martin v. Löwis [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
On the other hand it breaks one of the most fundamental Python
guidelines: if you get a core dump (segfault etc.) it's a bug in
Python or in a 3rd party extension, not in *your* Python code. An
exception would have to be made
Thomas Heller [EMAIL PROTECTED] writes:
It looks like we need a pronouncement now.
+1
I am a lurker in this list. I maintain ctypes for Debian and I would love to
see it in core python. Debian now includes ctypes for 10 Linux architectures
and kFreeBSD. The only missing significant
On 1/16/06, Thomas Heller [EMAIL PROTECTED] wrote:
It looks like we need a pronouncement now.
Sorry. It appeared to me that there was general agreement to using a
strongly worded warning in the docs, so I tuned out of the rest of the
discussion. So for the record, I'm fine with that.
--
--Guido
Guido van Rossum wrote:
On 1/16/06, Thomas Heller [EMAIL PROTECTED] wrote:
It looks like we need a pronouncement now.
Sorry. It appeared to me that there was general agreement to using a
strongly worded warning in the docs, so I tuned out of the rest of the
discussion. So for the record,
Delaney, Timothy (Tim) [EMAIL PROTECTED] writes:
Martin v. Löwis wrote:
So as for dealing with it somehow: I would make ctypes a dynamically
loaded module (ctypes.pyd), so administrators could remove it, and
I could also make it a separate option in the Windows installer,
so administrators
Martin v. Löwis [EMAIL PROTECTED] writes:
Guido van Rossum wrote:
On the other hand it breaks one of the most fundamental Python
guidelines: if you get a core dump (segfault etc.) it's a bug in
Python or in a 3rd party extension, not in *your* Python code. An
exception would have to be made
Thomas Heller wrote:
Sounds good, although it should be noted that ctypes is a package now,
with a ctypes.wrap subpackage (contains the code generator), a
ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X),
and ctypes.test subpackage whcih contains several test modules.
Martin v. Löwis [EMAIL PROTECTED] writes:
Thomas Heller wrote:
Sounds good, although it should be noted that ctypes is a package now,
with a ctypes.wrap subpackage (contains the code generator), a
ctypes.macholib subpackage (contains Bob Ippolitos macholib for OS X),
and ctypes.test
On Wed, 2006-01-11 at 07:59 +0100, Thomas Heller wrote:
Another possibility would be to emit a warning when the module (dl or
ctypes, if included) is imported.
warnings.warn(Incorrect usage of this module may crash Python,
RuntimeWarning, stacklevel=2)
BTW, although I'm
On Wed, Jan 11, 2006 at 07:59:50AM -0500, Barry Warsaw wrote:
BTW, although I'm pretty sure the answer is no (at least, I hope it
is), is anyone aware of a situation where the mere importation of a
module can cause Python to crash?
Well, I assume you aren't importing any 'hostile' code, nor
On Wed, 2006-01-11 at 14:54 +0100, Thomas Wouters wrote:
On Wed, Jan 11, 2006 at 07:59:50AM -0500, Barry Warsaw wrote:
BTW, although I'm pretty sure the answer is no (at least, I hope it
is), is anyone aware of a situation where the mere importation of a
module can cause Python to crash?
Guido van Rossum [EMAIL PROTECTED] writes:
On 1/10/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Sorry, I missed the point I was aiming at, I guess. I wasn't aiming for
fixable bugs; I see these things as, with great effort, holding up your foot
at an awkward angle so that it ends up right at
On Wed, Jan 11, 2006 at 02:54:40PM +0100, Thomas Wouters wrote:
The pickle vulnerability came up last year, when someone on #python was
subclassing a builtin type (string or dict, I think the latter) that was
using a magical invocation of (IIRC) __new__ on unpickle. The subclassed
__new__
On 11-jan-2006, at 7:59, Thomas Heller wrote:
I'm of the opinion that having a big red
warning at the top of the module documentation that this is a
contributed module, and incorrect use could cause segmentation
faults/crashes, etc would be sufficient.
Works for me.
Another possibility
On Wed, Jan 11, 2006 at 07:59:03AM +0100, Thomas Heller wrote:
Another possibility would be to emit a warning when the module (dl or
ctypes, if included) is imported.
warnings.warn(Incorrect usage of this module may crash Python,
RuntimeWarning, stacklevel=2)
Arrgggh! No!!
Martin v. Löwis wrote:
So as for dealing with it somehow: I would make ctypes a dynamically
loaded module (ctypes.pyd), so administrators could remove it, and
I could also make it a separate option in the Windows installer,
so administrators could reject to install it.
I like this solution.
On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
On the one hand I agree that this is a useful module, popular, mature etc.
On the other hand it breaks one of the most fundamental Python
guidelines: if
Guido van Rossum wrote:
On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
On the one hand I agree that this is a useful module, popular, mature
etc.
On the other hand it breaks one of the most
Delaney, Timothy (Tim) wrote:
Guido van Rossum wrote:
On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
On the one hand I agree that this is a useful module, popular, mature
etc.
On the other
On 1/10/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
On the one hand I agree that this is a useful module,
Guido van Rossum wrote:
As was pointed out on c.l.py, the `dl` module suffers the exact same
problem (I don't know myself, as I've never used it). There are no
warnings about this in the `dl` module documentation.
Good point. I think there should be such warnings though.
Added
On Tue, Jan 10, 2006 at 01:14:13PM -0800, Guido van Rossum wrote:
On the other hand it breaks one of the most fundamental Python
guidelines: if you get a core dump (segfault etc.) it's a bug in
Python or in a 3rd party extension, not in *your* Python code. An
exception would have to be made
On 1/10/06, Thomas Wouters [EMAIL PROTECTED] wrote:
Aside from 'dl', what was also pointed out in c.l.py was the crashability of
Python in general, even from pure Python code:
centurion:~ python .
Segmentation fault
This I think ought to be fixed; it's just (I presume) the parser
stumbling
Tim I'm of the opinion that having a big red warning at the top of the
Tim module documentation ...
Do we have semantic markup to support that?
ducks
Skip
___
Python-Dev mailing list
Python-Dev@python.org
[Guido]
I'm not saying it's uncrashable. I'm saying that if you crash it, it's
a bug unless proven harebrained.
+1 QOTW
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Thomas Wouters [EMAIL PROTECTED] wrote:
centurion:~ python .
Segmentation fault
[...]
sys.setrecursionlimit(130)
f = lambda f:f(f)
f(f)
Segmentation fault
There's more, all from Python itself. And sure, well, don't do that then
is a perfectly valid response to most of these
On Tue, Jan 10, 2006 at 03:57:28PM -0800, Josiah Carlson wrote:
As always, I'm sure that reasonable patches which work around such
segfaulting cases will be acceptable, though remember that it may not be
clear how to work around them.
Sorry, I missed the point I was aiming at, I guess. I
On 11-jan-2006, at 0:57, Josiah Carlson wrote:
On a platform which doesn't see the current path as a readable
file, you
get Access is denied. on the redirection attempt.
On my osx box using python 2.4.2:
$ cat .
cat: stdin: Is a directory
$ python .
Bus error
And finally:
$ python -c
Guido van Rossum [EMAIL PROTECTED] writes:
On 1/10/06, Delaney, Timothy (Tim) [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 1/10/06, Thomas Heller [EMAIL PROTECTED] wrote:
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
On the one hand
Won't ctypes completely replace dl? dl provides only a small subset
of the functionality of ctypes and is very restricted in the set of
argument types allowed.
Neil
___
Python-Dev mailing list
Python-Dev@python.org
On 1/10/06, Thomas Wouters [EMAIL PROTECTED] wrote:
centurion:~ python .
Segmentation fault
I fixed that in Oct in head and 2.4 branch. Although Skip filed a bug
since Py_FatalError() is called which generates a core dump in debug
builds at least. http://python.org/sf/1353504
I'm not sure
35 matches
Mail list logo
