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
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
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
"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,
"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,
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 t
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.
--
--Gui
> 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 arc
"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
"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.t
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:
> 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
"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,
>> s
"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 sol
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 for any code that uses ctypes, as it
> is
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! N
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.
>
> An
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__
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
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 t
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, n
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 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 no
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
http://mail.python.org/mailman/li
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 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:
$ py
Guido> I'm not sure what makes those particular examples less than real
Guido> bugs. Users *will* trip over these things.
Feel free to hack away at:
http://wiki.python.org/moin/CrashingPython
I have no idea where (if at all) it should be linked from elsewhere on the
wiki.
Skip
___
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 the business end of your
> primed and lit
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 wa
Thomas Wouters <[EMAIL PROTECTED]> wrote:
> centurion:~ > python < .
> Segmentation fault
>
> [...]
> >>> sys.setrecursionlimit(1<<30)
> >>> 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 res
[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:
http://mail.py
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?
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
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
s
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 mad
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 docum
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 usef
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.
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
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:
I would like to suggest to include ctypes into core Python, starting
with the 2.5 release.
ctypes is nearing the 1.0 release, and works on Windows, OS X, linux,
possibly other platforms (provided that the processor is supported by
libffi), and just recently even on Windows CE.
ctypes does not dep
40 matches
Mail list logo
