Re: [Python-Dev] Getting rid of unbound methods: patch available
M.-A. Lemburg wrote: Nick Coghlan wrote: Guido van Rossum wrote: What do people think? (My main motivation for this, as stated before, is that it adds complexity without much benefit.) I'm in favour, since it removes the "an unbound method is almost like a bare function, only not quite as useful" distinction. It would allow things like str.join(sep, seq) to work correctly for a Unicode separator. This won't work. Strings and Unicode are two different types, not subclasses of one another. My comment was based on misremembering how str.join actually works. It automatically flips to Unicode when it finds a Unicode string in the sequence - however, it doesn't do that for the separator, since that should already have been determined to be a string by the method lookup machinery. However, looking at the code for string_join suggests another possible issue with removing unbound methods. The function doesn't check the type of the first argument - it just assumes it is a PyStringObject. PyString_Join adds the typecheck that is normally performed by the method wrapper when str.join is invoked from Python. The issue is that, if the unbound method wrapper is removed, str.join(some_unicode_str, seq) will lead to PyString_AS_STRING being invoked on a PyUnicode object. Ditto for getting the arguments out of order, as in str.join(seq, separator). At the moment, the unbound method wrapper takes care of raising a TypeError in both of these cases. Without it, we get an unsafe PyString macro being applied to an arbitrary type. I wonder how many other C methods make the same assumption, and skip type checking on the 'self' argument? It certainly seems to be the standard approach in stringobject.c. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
Guido van Rossum wrote: [Guido] Apart from the tests that were testing the behavior of im_class, I found only a single piece of code in the standard library that used im_class of an unbound method object (the clever test in the pyclbr test). Uses of im_self and im_func were more widespread. Given the level of cleverness in the pyclbr test (and the fact that I wrote it myself) I'm not worried about widespread use of im_class on unbound methods. [Marc-Andre] I guess this depends on how you define widespread use. I'm using this feature a lot via the basemethod() function in mxTools for calling the base method of an overridden method in mixin classes (basemethod() predates super() and unlike the latter works for old-style classes). I'm not sure I understand how basemethod is supposed to work; I can't find docs for it using Google (only three hits for the query mxTools basemethod). How does it depend on im_class? It uses im_class to find the class defining the (unbound) method: def basemethod(object,method=None): """ Return the unbound method that is defined *after* method in the inheritance order of object with the same name as method (usually called base method or overridden method). object can be an instance, class or bound method. method, if given, may be a bound or unbound method. If it is not given, object must be bound method. Note: Unbound methods must be called with an instance as first argument. The function uses a cache to speed up processing. Changes done to the class structure after the first hit will not be noticed by the function. """ ... This is how it is used in mixin classes to call the base method of the overridden method in the inheritance tree (of old-style classes): class RequestListboxMixin: def __init__(self,name,viewname,viewdb,context=None,use_clipboard=0, size=None,width=None,monospaced=1,events=None): # Call base method mx.Tools.basemethod(self, RequestListboxMixin.__init__)\ (self,name,size,width,monospaced,None,events) ... Without .im_class for the unbound method, basemethod would seize to work since it uses this attribute to figure out the class object defining the overriding method. I can send you the code if you don't have egenix-mx-base installed somewhere (its in mx/Tools/Tools.py). What I don't understand in your reasoning is that you are talking about making an unbound method look more like a function. That's a strange interpretation. I'm getting rid of the unbound method object altogether. Well, you do have to assign some other type to the object that is returned by "myClass.myMethod" and as I understood your proposal, the returned object should be of the FunctionType. So from an application point of view, you are changing the type of an object. Unbound methods and bound methods are objects of the same type - the method object. Yeah I know that. :-) And it is one of the problems -- the two uses are quite distinct and yet it's the same object, which is confusing. Hmm, I have a hard time seeing how you can get rid off unbound methods while keeping bound methods - since both are the same type :-) By turning an unbound method into a function type, you break code that tests for MethodType in Python or does a PyMethod_Check() at C level. My expectation is that there is very little code like that. Almost all the code that I found doing that in the core Python code (none in C BTW) was in the test suite. I'm using PyMethod_Check() in mxProxy to automatically wrap methods of proxied object in order to prevent references to the object class or the object itself to slip by the proxy. Changing the type to function object and placing the class information into a function attribute would break this approach. Apart from that the type change (by itself) would not affect the eGenix code base. I would expect code in the following areas to make use of the type check: * language interface code (e.g. Java, .NET bridges) * security code that tries to implement object access control * RPC applications that use introspection to generate interface definitions (e.g. WSDL service definitions) * debugging tools (e.g. IDEs) Perhaps a few others could scan their code base as well ?! If you want to make methods look more like functions, the method object should become a subclass of the function object (function + added im_* attributes). Can't do that, since the (un)bound method object supports binding other callables besides functions. Is this feature used anywhere ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 10 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ _
Re: [Python-Dev] PEP 246: lossless and stateless
Hi Clark,
On Fri, Jan 14, 2005 at 12:41:32PM -0500, Clark C. Evans wrote:
> Imagine enhancing the stack-trace with additional information about
> what adaptations were made;
>
> Traceback (most recent call last):
>File "xxx", line 1, in foo
> Adapting x to File
>File "yyy", line 384, in bar
> Adapting x to FileName
>etc.
More thoughts should be devoted to this, because it would be very precious.
There should also be a way to know why a given call to adapt() returned an
unexpected object even if it didn't crash. Given the nature of the problem,
it seems not only "nice" but essential to have a good way to debug it.
> How can we express your thoughts so that they fit into a narrative
> describing how adapt() should and should not be used?
I'm attaching a longer, hopefully easier reformulation...
Armin
A view on adaptation
Adaptation is a tool to help exchange data between two pieces of code; a very
powerful tool, even. But it is easy to misunderstand its aim, and unlike other
features of a programming language, misusing adaptation will quickly lead into
intricate debugging nightmares. Here is the point of view on adaptation which
I defend, and which I believe should be kept in mind.
Let's take an example. You want to call a function in the Python standard
library to do something interesting, like pickling (saving) a number of
instances to a file with the ``pickle`` module. You might remember that there
is a function ``pickle.dump(obj, file)``, which saves the object ``obj`` to the
file ``file``, and another function ``pickle.load(file)`` which reads back the
object from ``file``. (Adaptation doesn't help you to figure this out; you
have to be at least a bit familiar with the standard library to know that this
feature exists.)
Let's take the example of ``pickle.load(file)``. Even if you remember about
it, you might still have to look up the documentation if you don't remember
exactly what kind of object ``file`` is supposed to be. Is it an open file
object, or a file name? All you know is that ``file`` is meant to somehow
"be", or "stand for", the file. Now there are at least two commonly used ways
to "stand for" a file: the file path as a string, or the file object directly.
Actually, it might even not be a file at all, but just a string containing the
already-loaded binary data. This gives a third alternative.
The point here is that the person who wrote the ``pickle.load(x)`` function
also knew that the argument was supposed to "stand for" a source of binary data
to read from, and he had to make a choice for one of the three common
representations: file path, file object, or raw data in a string. The "source
of binary data" is what both the author of the function and you would easily
agree on; the formal choice of representation is more arbitrary. This is where
adaptation is supposed to help. With properly setup adaptation, you can pass
to ``pickle.load()`` either a file name or a file object, or possibly anything
else that "reasonably stands for" an input file, and it will just work.
But to understand it more fully, we need to look a bit closer. Imagine
yourself as the author of functions like ``pickle.load()`` and
``pickle.dump()``. You decide if you want to use adaptation or not.
Adaptation should be used in this case, and ONLY in this kind of case: there is
some generally agreed concept on what a particular object -- typically an
argument of function -- should represent, but not on precisely HOW it should
represent it. If your function expects a "place to write the data to", it can
typically be an open file or just a file name; in this case, the function would
be defined like this::
def dump_data_into(target):
file = adapt(target, TargetAsFile)
file.write('hello')
with ``TargetAsFile`` being suitably defined -- i.e. having a correct
``__adapt__()`` special method -- so that the adaptation will accept either a
file or a string, and in the latter case open the named file for writing.
Surely, you think that ``TargetAsFile`` is a strange name for an interface if
you think about adaptation in term of interfaces. Well, for the purpose of
this argument, don't. Forget about interfaces. This special object
``TargetAsFile`` means not one but two things at once: that the input argument
``target`` represents the place into which data should be written; and that the
result ``file`` of the adaptation, as used within function itself, must be more
precisely a file object.
This two-level distinction is important to keep in mind, specially when
adapting built-in objects like strings and files. For example, the adaptation
that would be used in ``pickle.load(source)`` is more difficult to get right,
because there are two common ways that a string object can stand for a source
of data: either as the name of a file, or as raw binary data. It is not
Re: [Python-Dev] PEP 246: lossless and stateless
At 12:59 PM 1/18/05 +, Armin Rigo wrote: > How can we express your thoughts so that they fit into a narrative > describing how adapt() should and should not be used? I'm attaching a longer, hopefully easier reformulation... Well said! You've explained my "interface per use case" theory much better than I ever have. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] __str__ vs. __unicode__
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
---
class str2(str):
def __str__(self):
return "foo"
x = str2("bar")
print str(x)
class unicode2(unicode):
def __unicode__(self):
return u"foo"
x = unicode2(u"bar")
print unicode(x)
---
This outputs:
foo
bar
IMHO this should be fixed so that __unicode__() is used in the
second case too.
Bye,
Walter Dörwald
___
Python-Dev mailing list
Python-Dev@python.org
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/Python ceval.c, 2.420, 2.421
On Tue, 18 Jan 2005 07:56:19 -0800, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Update of /cvsroot/python/python/dist/src/Python > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv4034/Python > > Modified Files: > ceval.c > Log Message: > Change the name of the macro used by --with-tsc builds to the less > inscrutable READ_TIMESTAMP. An obvious improvement. Thanks! Jeremy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > Guido van Rossum wrote: a) Is Exception to be new-style? >>> >>>Probably not in 2.5; Martin and others have suggested that this could >>>introduce instability for users' existing exception classes. >> Really? I thought that was eventually decided to be a very small >> amount of code. > > I still think that only an experiment could decide: somebody should > come up with a patch that does that, and we will see what breaks. > > I still have the *feeling* that this has significant impact, but > I could not pin-point this to any specific problem I anticipate. Well, some code is certainly going to break such as this from warnings.py: assert isinstance(category, types.ClassType), "category must be a class" or this from traceback.py: if type(etype) == types.ClassType: stype = etype.__name__ else: stype = etype I hope to have a new patch (which makes PyExc_Exception new-style, but allows arbitrary old-style classes as exceptions) "soon". It may even pass bits of "make test" :) Cheers, mwh -- SPIDER: 'Scuse me. [scuttles off] ZAPHOD: One huge spider. FORD: Polite though. -- The Hitch-Hikers Guide to the Galaxy, Episode 11 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
[Timothy Delaney] > If im_func were set to the class where the function was defined, I could > definitely avoid the second part of the trawling (not sure about the > first yet, since I need to get at the function object). Instead of waiting for unbound methods to change their functionality, just create a metaclass that sticks the attribute you want on the function objects. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
[me] > > I'm not sure I understand how basemethod is supposed to work; I can't > > find docs for it using Google (only three hits for the query mxTools > > basemethod). How does it depend on im_class? [Marc-Andre] > It uses im_class to find the class defining the (unbound) method: > > def basemethod(object,method=None): > > """ Return the unbound method that is defined *after* method in the > inheritance order of object with the same name as method > (usually called base method or overridden method). > > object can be an instance, class or bound method. method, if > given, may be a bound or unbound method. If it is not given, > object must be bound method. > > Note: Unbound methods must be called with an instance as first > argument. > > The function uses a cache to speed up processing. Changes done > to the class structure after the first hit will not be noticed > by the function. > > """ > ... > > This is how it is used in mixin classes to call the base > method of the overridden method in the inheritance tree (of > old-style classes): > > class RequestListboxMixin: > > def __init__(self,name,viewname,viewdb,context=None,use_clipboard=0, > size=None,width=None,monospaced=1,events=None): > > # Call base method > mx.Tools.basemethod(self, RequestListboxMixin.__init__)\ > (self,name,size,width,monospaced,None,events) > > ... > > Without .im_class for the unbound method, basemethod would > cease to work since it uses this attribute to figure out > the class object defining the overriding method. Well, you could always do what Timothy Delaney's autosuper recipe does: crawl the class structure starting from object.__class__ until you find the requested method. Since you're using a cache the extra cost should be minimal. I realize that this requires you to issue a new release of mxTools to support this, but you probably want to do one anyway to support other 2.5 features. > Hmm, I have a hard time seeing how you can get rid > off unbound methods while keeping bound methods - since > both are the same type :-) Easy. There is a lot of code in the instance method type specifically to support the case where im_self is NULL. All that code can be deleted (once built-in exceptions stop using it). > I'm using PyMethod_Check() in mxProxy to automatically > wrap methods of proxied object in order to prevent references > to the object class or the object itself to slip by the > proxy. Changing the type to function object and placing > the class information into a function attribute would break > this approach. Apart from that the type change (by itself) > would not affect the eGenix code base. Isn't mxProxy a weak referencing scheme? Is it still useful given Python's own support for weak references? > I would expect code in the following areas to make use > of the type check: > * language interface code (e.g. Java, .NET bridges) Java doesn't have the concept of unbound methods, so I doubt it's useful there. Remember that as far as how you call it, the unbound method has no advantages over the function! > * security code that tries to implement object access control Security code should handle plain functions just as well as (un)bound methods anyway. > * RPC applications that use introspection to generate >interface definitions (e.g. WSDL service definitions) Why would those care about unbound methods? > * debugging tools (e.g. IDEs) Hopefuly those will use the filename + line number information in the function object. Remember, by the time the function is called, the (un)bound method object is unavailable. > >>If you want to make methods look more like functions, > >>the method object should become a subclass of the function > >>object (function + added im_* attributes). > > > > Can't do that, since the (un)bound method object supports binding > > other callables besides functions. > > Is this feature used anywhere ? Yes, by the built-in exception code. (It surprised me too; I think in modern days it would have been done using a custom descriptor.) BTW, decorators and other descriptors are one reason why approaches that insist on im_class being there will have a diminishing value in the future. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] __str__ vs. __unicode__
Walter Dörwald wrote:
__str__ and __unicode__ seem to behave differently. A __str__
overwrite in a str subclass is used when calling str(), a __unicode__
overwrite in a unicode subclass is *not* used when calling unicode():
---
class str2(str):
def __str__(self):
return "foo"
x = str2("bar")
print str(x)
class unicode2(unicode):
def __unicode__(self):
return u"foo"
x = unicode2(u"bar")
print unicode(x)
---
This outputs:
foo
bar
IMHO this should be fixed so that __unicode__() is used in the
second case too.
If you drop the base class for unicode, this already works.
This code in object.c:PyObject_Unicode() is responsible for
the sub-class version not doing what you'd expect:
if (PyUnicode_Check(v)) {
/* For a Unicode subtype that's not a Unicode object,
return a true Unicode object with the same data. */
return PyUnicode_FromUnicode(PyUnicode_AS_UNICODE(v),
PyUnicode_GET_SIZE(v));
}
So the question is whether conversion of a Unicode sub-type
to a true Unicode object should honor __unicode__ or not.
The same question can be asked for many other types, e.g.
floats (and __float__), integers (and __int__), etc.
>>> class float2(float):
... def __float__(self):
... return 3.141
...
>>> float(float2(1.23))
1.23
>>> class int2(int):
... def __int__(self):
... return 42
...
>>> int(int2(123))
123
I think we need general consensus on what the strategy
should be: honor these special hooks in conversions
to base types or not ?
Maybe the string case is the real problem ... :-)
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Jan 10 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
Michael Hudson <[EMAIL PROTECTED]> writes: > I hope to have a new patch (which makes PyExc_Exception new-style, but > allows arbitrary old-style classes as exceptions) "soon". It may even > pass bits of "make test" :) Done: http://www.python.org/sf/1104669 It passed 'make test' apart from failures I really don't think are my fault. I'll run "regrtest -uall" overnight... Cheers, mwh -- [1] If you're lost in the woods, just bury some fibre in the ground carrying data. Fairly soon a JCB will be along to cut it for you - follow the JCB back to civilsation/hitch a lift. -- Simon Burr, cam.misc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
Irmen de Jong wrote: Hello I've looked at one bug and a bunch of patches and added a comment to them: [...] [ 579435 ] Shadow Password Support Module Would be nice to have, I recently just couldn't do the user authentication that I wanted: based on the users' unix passwords I'm almost done with completing this thing. (including doc and unittest). However: 1- I can't add new files to this tracker item. Should I open a new patch and refer to it? 2- As shadow passwords can only be retrieved when you are root, is a unit test module even useful? 3- Should the order of the chapters in the documentation be preserved? I'd rather add spwd below pwd, but this pushes the other unix modules "1 down"... --Irmen ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
Irmen de Jong wrote: 1- I can't add new files to this tracker item. Should I open a new patch and refer to it? Depends on whether you want tracker admin access (i.e. become a SF python project member). If you do, you could attach patches to bug reports not written by you. 2- As shadow passwords can only be retrieved when you are root, is a unit test module even useful? Probably not. Alternatively, introduce a "root" resource, and make that test depend on the presence of the root resource. 3- Should the order of the chapters in the documentation be preserved? I'd rather add spwd below pwd, but this pushes the other unix modules "1 down"... You could make it a subsection (e.g. "spwd -- shadow passwords") Not sure whether this would be supported by the processing tools; if not, inserting the module in the middle might be acceptable. In any case, what is important is that the documentation is added - it can always be rearranged later. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
Irmen de Jong wrote: > 3- Should the order of the chapters in the documentation >be preserved? I'd rather add spwd below pwd, but >this pushes the other unix modules "1 down"... On Tuesday 18 January 2005 17:17, Martin v. Löwis wrote: > You could make it a subsection (e.g. "spwd -- shadow passwords") > Not sure whether this would be supported by the processing > tools; if not, inserting the module in the middle might be > acceptable. I see no reason not to insert it right after pwd module docs. The order of the sections is not a backward compatibility concern. :-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] Getting rid of unbound methods: patch available
Guido van Rossum wrote: > [Timothy Delaney] >> If im_func were set to the class where the function was defined, I >> could definitely avoid the second part of the trawling (not sure >> about the first yet, since I need to get at the function object). > > Instead of waiting for unbound methods to change their functionality, > just create a metaclass that sticks the attribute you want on the > function objects. Yep - that's one approach I've considered. I've also thought about modifying the code objects, which would mean I could grab the base class directly. It's definitely not the most compelling use case in the world ;) Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
Martin, Irmen de Jong wrote: 1- I can't add new files to this tracker item. Should I open a new patch and refer to it? Depends on whether you want tracker admin access (i.e. become a SF python project member). If you do, you could attach patches to bug reports not written by you. That sounds very convenient, thanks. Does the status of 'python project member' come with certain expectations that must be complied with ? ;-) 2- As shadow passwords can only be retrieved when you are root, is a unit test module even useful? Probably not. Alternatively, introduce a "root" resource, and make that test depend on the presence of the root resource. I'm not sure what this "resource" is actually. I have seen them pass on my screen when executing the regression tests (resource "network" is not enabled, etc) but never paid much attention to them. Are they used to select optional parts of the test suite that can only be run in certain conditions? In any case, what is important is that the documentation is added - it can always be rearranged later. I've copied and adapted the "pwd" module chapter. I'll try to have a complete patch ready tomorrow night. Bye, -Irmen. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
[Martin asks whether Irmen wants to be a tracker admin on SF] [Irmen de Jong] > That sounds very convenient, thanks. > Does the status of 'python project member' come with > certain expectations that must be complied with ? ;-) If you're using Python, you're already required to comply with all of Guido's demands, this would just make it more official. Kinda like the difference in sanctifying cohabitation with a marriage ceremony . OK, really, the minimum required of Python project members is that they pay some attention to Python-Dev. >>> 2- As shadow passwords can only be retrieved when >>>you are root, is a unit test module even useful? >> Probably not. Alternatively, introduce a "root" resource, >> and make that test depend on the presence of the root resource. > I'm not sure what this "resource" is actually. > I have seen them pass on my screen when executing the > regression tests (resource "network" is not enabled, etc) > but never paid much attention to them. > Are they used to select optional parts of the test suite > that can only be run in certain conditions? That's right, where "the condition" is precisely that you tell regrtest.py to enable a (one or more) named resource. There's no intelligence involved. "Resource names" are arbitrary, and can be passed to regrtest.py's -u argument. See regrtest's docstring for details. For example, to run the tests that require the network resource, pass "-u network". Then it will run network tests, and regardless of whether a network is actually available. Passing "-u all" makes it try to run all tests. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Patch review [ 684500 ] extending readline functionality
Patch review [ 684500 ] (extending readline functionality) This patch is a duplicate of patch [ 675551 ] (extending readline functionality), which was first submitted against stable python version 2.2.2. After the resubmitted patch [ 684500 ] against Python 2.3a1 was accepted (Modules/readline.c revision 2.73 and Doc/lib/libreadline.tex revision 1.16), the original patch [ 675551 ] was closed but patch [ 684500 ] was not. I have added a comment to patch [ 684500 ] that it can be closed. --Michiel. -- Michiel de Hoon, Assistant Professor University of Tokyo, Institute of Medical Science Human Genome Center 4-6-1 Shirokane-dai, Minato-ku Tokyo 108-8639 Japan http://bonsai.ims.u-tokyo.ac.jp/~mdehoon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Strange segfault in Python threads and linux kernel 2.6
G'day, I've Cc'ed this to zope-coders as it might affect other Zope developers and it had me stumped for ages. I couldn't find anything on it anywhere, so I figured it would be good to get something into google :-). We are developing a Zope2.7 application on Debian GNU/Linux that is using fop to generate pdf's from xml-fo data. fop is a java thing, and we are using popen2.Popen3(), non-blocking mode, and select loop to write/read stdin/stdout/stderr. This was all working fine. Then over the Christmas chaos, various things on my development system were apt-get updated, and I noticed that java/fop had started segfaulting. I tried running fop with the exact same input data from the command line; it worked. I wrote a python script that invoked fop in exactly the same way as we were invoking it inside zope; it worked. It only segfaulted when invoked inside Zope. I googled and tried everything... switched from j2re1.4 to kaffe, rolled back to a previous version of python, re-built Zope, upgraded Zope from 2.7.2 to 2.7.4, nothing helped. Then I went back from a linux 2.6.8 kernel to a 2.4.27 kernel; it worked! After googling around, I found references to recent attempts to resolve some signal handling problems in Python threads. There was one post that mentioned subtle differences between how Linux 2.4 and Linux 2.6 did signals to threads. So it seems this is a problem with Python threads and Linux kernel 2.6. The attached program demonstrates that it has nothing to do with Zope. Using it to run "fop-test /usr/bin/fop http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=971213>. Is this the same bug? Should I submit a new bug report? Is there any other way I can help resolve this? BTW, built in file objects really could use better non-blocking support... I've got a half-drafted PEP for it... anyone interested in it? -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ test-fop.py Description: application/python ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
