RE: [Python-Dev] Rewriting PEP4
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. I don't think it is good to leave active modules as orphans. Raymond ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rewriting PEP4
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 useful action needs to take place. If the code is left in-place and the doc index is just re-arranged, then we would have been better off not doing anything at all. I disagree. The primary purpose (move developers to the alternative approach) is achieved as soon as the warning is added, and the documentation is deleted. Whether the module is actually deleted is of minor importance: it costs nothing to continue including it; disk space is cheap. The questions of dates was somewhat minor. I was unclear on the implication of, for example, "remove on 15Jan2005". Since Py2.5 won't go out for at least a year, does that mean that the work can't be done now while I have time instead of later when I don't. The only time the removal becomes visible is when a new version goes out the door. You could remove it now, but if we release Py2.5 in two months, you would have to put it back in. So if you don't have time then, maybe somebody else will. If nobody has time to remove the module, the next release will ship with it, again - no big issue. Further, if a version is going to have something removed, we should do it at the outset rather than just before a release goes out the door (to allow for early surfacing of any issues). That is true. If we really don't care whether it gets done, then we shouldn't bother in the first place. What do you mean by "bother"? Not put the deprecation warning in? We do want users to move to the new approach of doing something. However, two version are just not enough - it may take 10 or 20 years to remove a widely used feature (e.g. the string module). That it will take so long does not mean we should not start the process *now* - if we start the process in five years, it will *still* take 10 or 20 years. Just be patient. Regards, Martin ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Rewriting PEP4
> > 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 a couple versions pass, some useful action needs to take place. If > > the code is left in-place and the doc index is just re-arranged, then we > > would have been better off not doing anything at all. > > I disagree. The primary purpose (move developers to the alternative > approach) is achieved as soon as the warning is added, and the > documentation is deleted. Whether the module is actually deleted is > of minor importance: it costs nothing to continue including it; disk > space is cheap. That is reasonable. Please make that goal/assumption explicit in the PEP. > > The questions of dates was somewhat minor. I was unclear on the > > implication of, for example, "remove on 15Jan2005". Since Py2.5 won't > > go out for at least a year, does that mean that the work can't be done > > now while I have time instead of later when I don't. The only time the > > removal becomes visible is when a new version goes out the door. > > You could remove it now, but if we release Py2.5 in two months, you > would have to put it back in. So if you don't have time then, maybe > somebody else will. If nobody has time to remove the module, the next > release will ship with it, again - no big issue. Okay. Again, please say that in the PEP. > > Further, if a version is going to have something removed, we should do > > it at the outset rather than just before a release goes out the door (to > > allow for early surfacing of any issues). > > That is true. That should also be recommended in the PEP. > > If we really don't care whether it gets done, then we shouldn't bother > > in the first place. > > What do you mean by "bother"? Not put the deprecation warning in? We > do want users to move to the new approach of doing something. However, > two version are just not enough - it may take 10 or 20 years to remove > a widely used feature (e.g. the string module). That it will take so > long does not mean we should not start the process *now* - if we start > the process in five years, it will *still* take 10 or 20 years. Just > be patient. I see. That also may useful to include in the motivation section of the PEP. With these adjustments, I think the PEP will be fine. Also, be sure get rid of the mid-version undo (see Anthony's note) and to address the situation with Python books. I look forward to a revised draft. Raymond ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: long number multiplication
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 conversion. Indeed. Python's Decimal data type stores the digits in a list for ease of power of 10 multiplication & rounding (the precision rules means a *lot* of that goes on). However, it converts that list of digits to a long integer in order to do addition, multiplication or division. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rewriting PEP4
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 should be included, but it seems an example or two would make it easy to get right. E.g.: Unmaintained, with a maintained alternative: "Due to lack of maintenance, this module has been deprecated in favour of module Y and will be removed in Python 2.6 (see PEP 4 for information on the deprecation process)" Security problems, no alternative: "Due to security concerns, this module has been deprecated and will be removed in Python 2.6 (see PEP 4 for information on the deprecation process)" Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: long number multiplication
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 ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Rewriting PEP4
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't think it is good to leave active modules as > orphans. I would like to add deprecation warnings to some of the old email-related modules for Python 2.5, but I doubt we can remove any of them until Python 3.0 (or 2014, whichever comes first ). -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Rewriting PEP4
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 mapping from the old module to the new is not obvious and trivial, sufficient information should be included in the documentation for the old module to make it fairly easy to perform the conversion. (Placing this in the docs for the old module ensures that it goes away when the documentation for the old module goes away, and the docs for the new module need never be loaded with information about the old module.) > Also, should the PEP include example wordings for deprecation warnings, > rather than being completely freeform? Martin listed some information that > should be included, but it seems an example or two would make it easy to > get right. Examples would be good, though specific wording should not be proscribed. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Python-checkins] python/dist/src/Lib/test test_shutil.py, 1.10, 1.11
[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 that way. Also add a bunch of cross-references
> to bugs.
>
>
> Index: test_shutil.py
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/test/test_shutil.py,v
> retrieving revision 1.10
> retrieving revision 1.11
> diff -u -d -r1.10 -r1.11
> --- test_shutil.py23 Nov 2004 09:27:27 - 1.10
> +++ test_shutil.py6 Dec 2004 20:50:15 - 1.11
> @@ -16,7 +16,10 @@
> filename = tempfile.mktemp()
> self.assertRaises(OSError, shutil.rmtree, filename)
>
> -if hasattr(os, 'chmod') and sys.platform[:6] != 'cygwin':
> +# See bug #1071513 for why we don't run this on cygwin
> +# and bug #1076467 for why we don't run this as root.
> +if (hasattr(os, 'chmod') and sys.platform[:6] != 'cygwin'
> +and os.getenv('USER') != 'root'):
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...
Or is it os.getuid()? I always get confused by these functions...
Cheers,
mwh
--
CDATA is not an integration strategy.
-- from Twisted.Quotes
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
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 such a "stupid" call return NULL in a reproducable way? -aj ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
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) which returns NULL. What > could be the reason that > such a "stupid" call return NULL in a reproducable way? A memory scribble somewhere else? Possibly a DECREF too many somewhere? Is an exception set? Have you tried a debug build? Etc. Cheers, mwh -- All obscurity will buy you is time enough to contract venereal diseases. -- Tim Peters, python-dev ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
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 be the reason that such a "stupid" call return NULL in a reproducable way? 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. I'd say the first step should be to add checks. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
[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 > PyInt_FromLong(1) which returns NULL. What could be the > reason that such a "stupid" call return NULL in a reproducable > way? Any C function that returns a Python object can return NULL if malloc() says there's not enough memory to create a new object. PyInt_FromLong() actually allocates about 1KB at a time, and will return NULL if malloc() can't find that much. OTOH, 1KB isn't big, and PyInt_FromLong(1) specifically should be returning a shared reference to a pre-existing PyIntObject (a number of small integer objects are constructed at Python initialization time, and PyInt_FromLong() returns references to them instead of allocating new memory). So PyInt_FromLong(1) should have taken this path: v = small_ints[ival + NSMALLNEGINTS]; But if a wild store had stuffed NULL into 1's slot in the small_ints vector, the *next* line would have blown up with a NULL-pointer dereference before PyInt_FromLong() could have returned: Py_INCREF(v); return (PyObject *) v; So, in all, it appears impossible for PyInt_FromLong(1) to return NULL. If it's reproducible, run it under a debugger and step into the errant PyInt_FromLong(1) to see what's happening? Could be a compiler optimization bug (while rare, they have happened in Python). ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
[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 object for 1 (and for about 100 other popular little integers) when it starts up, and PyInt_FromLong() just returns a new reference to these 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 . ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
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 allocates an int object for 1 (and for about 100 other popular little integers) when it starts up, and PyInt_FromLong() just returns a new reference to these pre-existing objects whenever possible. I know. I'm sure that's why we don't bother. But, obviously, it can fail. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
[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
that PyInt_FromLong(1) actually returned NULL. If it did return NULL,
then it's got to be something as rare as bad code generation (for
reasons I explained earlier), or a non-standard compilation that
fiddled the NSMALLPOSINTS and/or NSMALLNEGINTS #defines to insane
values.
This is the entire expected path in PyInt_FromLong(1):
PyObject *
PyInt_FromLong(long ival)
{
register PyIntObject *v;
#if NSMALLNEGINTS + NSMALLPOSINTS > 0
if (-NSMALLNEGINTS <= ival && ival < NSMALLPOSINTS) {
v = small_ints[ival + NSMALLNEGINTS];
Py_INCREF(v);
#ifdef COUNT_ALLOCS
if (ival >= 0)
quick_int_allocs++;
else
quick_neg_int_allocs++;
#endif
return (PyObject *) v;
}
#endif
It's not possible for that to return NULL -- even if small_ints[] got
corrupted, so that v == NULL, the Py_INCREF(v) would have blown up
before the function could have returned.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
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 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 uses, I don't see any references to PyErr_Occurred()... --amk ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
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))
{
if (PyString_Check(name) ||
PyUnicode_Check(name))
{
ASSIGN(p, PyObject_GetItem(p, name));
^^
if (p == NULL) {
puts("PyObject returned NULL");
PyErr_Clear();
}
}
else
p = PyInt_FromLong((long)1);
...doing some further investigations on that.
-aj
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
[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 uses, I don't see any > references to PyErr_Occurred()... A long stare wouldn't uncover any either . This isn't it. That 1 is passed as an argument is important too, which cuts out all but the simplest path thru this code. The (current Zope 2.7 branch) source for cAccessControl.c contains six calls to PyInt_FromLong(). Five of them pass the literal 1. The other passes a variable with value -1, 0, or 1. So regardless of which of these Andreas is talking about, it's going thru PyInt_FromLong's fast path. ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
[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))
> {
>if (PyString_Check(name) ||
> PyUnicode_Check(name))
> {
>ASSIGN(p, PyObject_GetItem(p, name));
>^^
>
>if (p == NULL) {
>puts("PyObject returned NULL");
> PyErr_Clear();
>}
> }
>else
> p = PyInt_FromLong((long)1);
>
> ...doing some further investigations on that.
I note that all of this is nested inside another "if (p) {...}" block.
That implies the "p = PyInt_FromLong((long)1);" line is at least a
memory leak: it overwrites p without decref'ing p first.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
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(p))
{
if (PyString_Check(name) ||
PyUnicode_Check(name))
{
ASSIGN(p, PyObject_GetItem(p, name));
^^
if (p == NULL) {
puts("PyObject returned NULL");
PyErr_Clear();
}
}
else
p = PyInt_FromLong((long)1);
...doing some further investigations on that.
I note that all of this is nested inside another "if (p) {...}" block.
That implies the "p = PyInt_FromLong((long)1);" line is at least a
memory leak: it overwrites p without decref'ing p first.
The ASSIGN macro DECREFs it's first argument if it is non-NULL.
It loosly models a Python assignment, assuming that it owns the
reference to the second argument.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED] Python Powered!
CTO (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python 2.4] PyInt_FromLong returning NULL
>>> if (! PyInt_Check(p))
>>> {
>>> if (PyDict_Check(p))
>>> {
>>> if (PyString_Check(name) || PyUnicode_Check(name))
>>> {
>>> ASSIGN(p, PyObject_GetItem(p, name));
>>> ^^
>>>
>>> if (p == NULL) {
>>> puts("PyObject returned NULL");
>>> PyErr_Clear();
>>> }
>>> }
>>> else
>>> p = PyInt_FromLong((long)1);
>>>
[Tim]
>> I note that all of this is nested inside another "if (p) {...}" block.
>> That implies the "p = PyInt_FromLong((long)1);" line is at least a
>> memory leak: it overwrites p without decref'ing p first.
[Jim]
> The ASSIGN macro DECREFs it's first argument if it is non-NULL.
>
> It loosly models a Python assignment, assuming that it owns the
> reference to the second argument.
ASSIGN isn't executed on the path in question. I really can't follow
nesting with that indentation style. Reformatting in Python style
makes it obvious to me:
if (p) {
if (! PyInt_Check(p)) {
if (PyDict_Check(p)) {
if (PyString_Check(name) || PyUnicode_Check(name)) {
ASSIGN(p, PyObject_GetItem(p, name));
if (p == NULL)
PyErr_Clear();
}
else
p = PyInt_FromLong(1);
}
else {
ASSIGN(p, callfunction2(p, name, value));
if (p == NULL)
goto err;
}
}
}
"p = PyInt_FromLong(1)" is in an ``else`` block. The only ASSIGN
before it is in that ``else`` block's disjoint ``if`` block.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Lib/test test_shutil.py, 1.10, 1.11
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 solution. > Or is it os.getuid()? I always get confused by these functions... Based on my reading of the difference between geteuid and getuid, I'd go for geteuid. Cheers, Johannes ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Rewriting PEP4
""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 everything in mind at once and cannot remember, without referring back to the lib manual or pydev, which modules are currently or slated to become deprecated. 3. I do not wish to have other people's code broken,or books made obsolete, without sufficient reason (ie, the code is actively dangerous versus merely broken or superceded). My preferred solution is to apply the 'out of sight, out of mind' principle. 1. Move obsolete modules to a separate directory (lib_old sounds fine) and put that directory in pythonpath. When I ran Python (1.3) from a 20 meg disk, I would have preferred complete removal, but with 60+ gigs, the small extra space is no longer an issue. If someone needs the space or wants to guarantee non-use of old modules, deleting lib_old is easy enough. 2. Remove the docs for obsolete modules from the main part of the current lib reference. Sub-choices for legacy chapters are either complete removal or segregation into a separate document or apppendix to current one. Terry J. Reedy ___ Python-Dev mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
