There is one other issue that should get addressed, modules in limbo.
I'm concerned about the old email modules. They haven't been deprecated
and may stay around for a good while. However, some SF requests have
been passed over on the basis that the modules are supplanted and will
be phased out.
Raymond Hettinger wrote:
Instead, there should be a clear decision to deprecate or not. If that
entails a comp.lang.python.announce notice and comment period, so be it.
Once a decision is made, document it, add a warning, and wait.
Ok, that might be reasonable.
Once a couple versions pass, some us
> > Instead, there should be a clear decision to deprecate or not. If
that
> > entails a comp.lang.python.announce notice and comment period, so be
it.
> > Once a decision is made, document it, add a warning, and wait.
>
> Ok, that might be reasonable.
Please word the PEP accordingly.
> > Once
Christopher A. Craig wrote:
i needed to implement this myself and was thinking of storing the digits
of an integer in a list.
That's sort of what Python does except the "digits" are 15 bits,
not base 10. Doing it in base 10 would be a huge pain because of the
problems with base 10->base 2 conver
One other question occurred to me for "deprecate X in favour of Y" situations -
should the deprecation warning added to X point developers towards Y?
Also, should the PEP include example wordings for deprecation warnings, rather
than being completely freeform? Martin listed some information that
Gah, sorry folks. I really ought to pay more attention to that send line.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
__
On Tue, 2004-12-07 at 03:12, Raymond Hettinger wrote:
> I'm concerned about the old email modules. They haven't been deprecated
> and may stay around for a good while. However, some SF requests have
> been passed over on the basis that the modules are supplanted and will
> be phased out. I don'
On Tuesday 07 December 2004 04:46 am, Nick Coghlan wrote:
> One other question occurred to me for "deprecate X in favour of Y"
> situations - should the deprecation warning added to X point developers
> towards Y?
Not sure about the warning, but the documentation certainly should. When the
ma
[EMAIL PROTECTED] writes:
> Update of /cvsroot/python/python/dist/src/Lib/test
> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20531
>
> Modified Files:
> test_shutil.py
> Log Message:
> SF bug #1076467: don't run test_on_error as root, as the permission
> errors don't get provoked
While using Zope 2.7 with Python 2.4 we discovered some strange behaviour
of the security machinery.
I could track this down to some Zope code in cAccessControl.c where an
Unauthorized exception is
raised because of a call to PyInt_FromLong(1) which returns NULL. What
could be the reason that
su
Andreas Jung <[EMAIL PROTECTED]> writes:
> While using Zope 2.7 with Python 2.4 we discovered some strange
> behaviour of the security machinery.
> I could track this down to some Zope code in cAccessControl.c where an
> Unauthorized exception is
> raised because of a call to PyInt_FromLong(1) whi
Andreas Jung wrote:
While using Zope 2.7 with Python 2.4 we discovered some strange
behaviour of the security machinery.
I could track this down to some Zope code in cAccessControl.c where an
Unauthorized exception is
raised because of a call to PyInt_FromLong(1) which returns NULL. What
could b
[Andreas Jung]
> While using Zope 2.7
Do you mean 2.7, or do you mean 2.7.3, or ...?
> with Python 2.4 we discovered some strange behaviour
> of the security machinery.
> I could track this down to some Zope code in cAccessControl.c
> where an Unauthorized exception is raised because of a call to
[Jim Fulton]
> Ugh. Part of the problem is that all of those calls are unchecked,
> Dang us. If they were checked, then, who knows, we might have
> gotten informative exceptions.
They certainly "should" be checked, but as a pragmatic matter
PyInt_FromLong(1) can't fail -- Python allocates an int
Tim Peters wrote:
[Jim Fulton]
Ugh. Part of the problem is that all of those calls are unchecked,
Dang us. If they were checked, then, who knows, we might have
gotten informative exceptions.
They certainly "should" be checked, but as a pragmatic matter
PyInt_FromLong(1) can't fail -- Python alloc
[Tim]
>> ... but as a pragmatic matter PyInt_FromLong(1) can't fail --
[Jim]
> I know. I'm sure that's why we don't bother. But, obviously,
> it can fail.
I disagree -- it's not obvious at all. Looking at the code, it's far
more likely that Andreas misunderstood the cause of the failure than
th
On Tue, Dec 07, 2004 at 01:02:51PM -0500, Tim Peters wrote:
> pre-existing objects whenever possible. So, wrt:
> > I'd say the first step should be to add checks
> that's probably not going to help. I'd make it the fourth thing .
Is it possible that some other Python API call is raising an
excep
Sorry, false alarm :-( There assignment of the NULL occurs in the
if-clause of the
corresponding code (I have overseen the ASSIGN call):
if (! PyInt_Check(p))
{
if (PyDict_Check(p))
{
[A.M. Kuchling]
> Is it possible that some other Python API call is raising an
> exception, but a NULL return isn't being checked for, and
> PyInt_FromLong() happens to be the first bit of code that does 'if
> (PyErr_Occurred())'? Though from a quick glance at
> PyInt_FromLong() and the macros it
[Andreas Jung]
> Sorry, false alarm :-( There assignment of the NULL occurs in the
> if-clause of the corresponding code (I have overseen the ASSIGN
> call):
Thanks for the followup!
>if (! PyInt_Check(p))
> {
>if (PyDict_Check(p))
Tim Peters wrote:
[Andreas Jung]
Sorry, false alarm :-( There assignment of the NULL occurs in the
if-clause of the corresponding code (I have overseen the ASSIGN
call):
Thanks for the followup!
if (! PyInt_Check(p))
{
if (PyDict_Check(
>>> if (! PyInt_Check(p))
>>> {
>>> if (PyDict_Check(p))
>>> {
>>> if (PyString_Check(name) || PyUnicode_Check(name))
>>> {
>>> ASS
On Tue, Dec 07, 2004 at 02:54:50PM +, Michael Hudson wrote:
> Is that really the best way to check for root? It may be, I guess,
> but I'd have expected os.geteuid() to be more reliable...
Ah yes, I suppose it is. I'll change it tomorrow night if no Unix-guru
steps up with an alternative solu
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
As a (currently) casual user of Python, this is my view of the standard
library dilemma and its solution:
1. It is too small: I may someday want to use a module not yet added.
2. It is too big: I cannot keep every
24 matches
Mail list logo
