Re: [Python-Dev] Let's get rid of unbound methods
On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: >In my blog I wrote: > > Let's get rid of unbound methods. When class C defines a method f, C.f > should just return the function object, not an unbound method that > behaves almost, but not quite, the same as that function object. The > extra type checking on the first argument that unbound methods are > supposed to provide is not useful in practice (I can't remember that > it ever caught a bug in my code) and sometimes you have to work around > it; it complicates function attribute access; and the overloading of > unbound and bound methods on the same object type is confusing. Also, > the type checking offered is wrong, because it checks for subclassing > rather than for duck typing. > This would make pickling (or any serialization mechanism) of `Class.method' based on name next to impossible. Right now, with the appropriate support, this works: >>> import pickle >>> class Foo: ... def bar(self): pass ... >>> pickle.loads(pickle.dumps(Foo.bar)) >>> I don't see how it could if Foo.bar were just a function object. Jp ___ 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] Let's get rid of unbound methods
On Tue, 04 Jan 2005 20:02:06 GMT, Jp Calderone <[EMAIL PROTECTED]> wrote: >On Tue, 4 Jan 2005 10:28:03 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: > >In my blog I wrote: > > > > Let's get rid of unbound methods. When class C defines a method f, C.f > > should just return the function object, not an unbound method that > > behaves almost, but not quite, the same as that function object. The > > extra type checking on the first argument that unbound methods are > > supposed to provide is not useful in practice (I can't remember that > > it ever caught a bug in my code) and sometimes you have to work around > > it; it complicates function attribute access; and the overloading of > > unbound and bound methods on the same object type is confusing. Also, > > the type checking offered is wrong, because it checks for subclassing > > rather than for duck typing. > > > > This would make pickling (or any serialization mechanism) of > `Class.method' based on name next to impossible. Right now, with > the appropriate support, this works: It occurs to me that perhaps I was not clear enough here. What I mean is that it is possible to serialize unbound methods currently, because they refer to both their own name, the name of their class object, and thus indirectly to the module in which they are defined. If looking up a method on a class object instead returns a function, then the class is no longer knowable, and most likely the function will not have a unique name which can be used to allow a reference to it to be serialized. In particular, I don't see how one will be able to write something equivalent to this: import new, copy_reg, types def pickleMethod(method): return unpickleMethod, (method.im_func.__name__, method.im_self, method.im_class) def unpickleMethod(im_name, im_self, im_class): unbound = getattr(im_class, im_name) if im_self is None: return unbound return new.instancemethod(unbound.im_func, im_self, im_class) copy_reg.pickle(types.MethodType, pickleMethod, unpickleMethod) But perhaps I am just overlooking the obvious. Jp ___ 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] Let's get rid of unbound methods
On Tue, 4 Jan 2005 12:18:15 -0800, Guido van Rossum <[EMAIL PROTECTED]> wrote: >[me] > > > Actually, unbound builtin methods are a different type than bound > > > builtin methods: > > [Jim] > > Of course, but conceptually they are similar. You would still > > encounter the concept if you got an unbound builtin method. > > Well, these are all just implementation details. They really are all > just callables. > > [Jp] > > This would make pickling (or any serialization mechanism) of > > `Class.method' based on name next to impossible. Right now, with > > the appropriate support, this works: > > > > >>> import pickle > > >>> class Foo: > > ... def bar(self): pass > > ... > > >>> pickle.loads(pickle.dumps(Foo.bar)) > > > > >>> > > > > I don't see how it could if Foo.bar were just a function object. > > Is this a purely theoretical objection or are you actually aware of > anyone doing this? Anyway, that approach is pretty limited -- how > would you do it for static and class methods, or methods wrapped by > other decorators? It's not a feature I often depend on, however I have made use of it on occassion. Twisted's supports serializing unbound methods this way, primarily to enhance the useability of tap files (a feature whereby an application is configured by constructing a Python object graph and then pickled to a file to later be loaded and run). "Objection" may be too strong a word for my stance here, I just wanted to point out another potentially incompatible behavior change. I can't think of any software which I cam currently developing or maintaining which benefits from this feature, it just seems unfortunate to further complicate the already unpleasant business of serialization. Jp ___ 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] PATCH/RFC for AF_NETLINK support
On Tue, 11 Jan 2005 08:54:42 +0100, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >Philippe Biondi wrote: > > I've done a small patch to use linux AF_NETLINK sockets (see below). > > Please comment! > > I have a high-level comment - python-dev is normally the wrong place > for patches; please submit them to sf.net/projects/python instead. > > Apart from that, the patch looks fine. > > > Is there a reason for recvmsg() and sendmsg() not to be implemented > > yet in socketmodule ? > > I'm not sure what you mean by "implemented": these functions are > implemented by the operating system, not in the socketmodule. > > If you ask "why are they not exposed to Python yet?": There has been no > need to do so, so far. What do I get with recvmsg that I cannot get with > recv/recvfrom just as well? Everything that recvmsg() does. recv() and recvfrom() give you "regular" bytes - data sent to the socket using send() or sendto(). recvmsg() gives you messages - data sent to the socket using sendmsg(). There is no way to receive messages by using recv() or recvfrom() (and no way to send them using send() or sendto()). Inversely, I believe send() and recv() can be implemented in terms of sendmsg() and recvmsg(). Perhaps we should get rid of socket.send() and socket.recv()? Other things that sendmsg() and recvmsg() can do include passing file descriptors, receiving notice of OOB TCP data, peek at bytes from the kernel's buffer without actually reading them, and implement scatter/gather IO functions (although you'd probably just want to wrap and use writev() and readv() instead). Jp ___ 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] PATCH/RFC for AF_NETLINK support
On Tue, 11 Jan 2005 01:32:52 +, David Wilson <[EMAIL PROTECTED]> wrote: >On Mon, Jan 10, 2005 at 05:17:49PM +0100, Philippe Biondi wrote: > > > I've done a small patch to use linux AF_NETLINK sockets (see below). > > Please comment! > > As of 2.6.10, a very useful new netlink family was merged - > NETLINK_KOBJECT_UEVENT. I'd imagine quite a lot of interest from Python > developers for NETLINK support will come from this new interface in the > coming years. > > [snip] > > I would like to see (optional?) support for this before your patch is > merged. I have a long-term interest in a Python-based service control / > init replacement / system management application, for use in specialised > environments. I could definately use this. :) Useful indeed, but I'm not sure why basic NETLINK support should be held up for it? Jp ___ 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] properties with decorators (was: code blocks using 'for' loops and generators)
On Thu, 17 Mar 2005 09:01:27 -0800, Josiah Carlson <[EMAIL PROTECTED]> wrote: > > Nick Coghlan <[EMAIL PROTECTED]> wrote: > > > > Josiah Carlson wrote: > > > > > > [snip] > > > > > > I think properties are the most used case where this kind of thing would > > > be nice. Though the only thing that I've ever had a gripe with > > > properties is that I didn't like the trailing property() call - which is > > > why I wrote a property helper decorator (a use can be seen in [1]). But > > > my needs are small, so maybe this kind of thing isn't sufficient for > > > those who write hundreds of properties. > > [snip] > > > > I'm still trying to decide if the following is an elegant solution to > > defining > > properties, or a horrible abuse of function decorators: > > [snip example] > > The only issue is that you are left with a closure afterwards, no big > deal, unless you've got hundreds of thousands of examples of this. I > like your method anyways. No closed over variables, actually. So no closure. > > - Josiah > Jp ___ 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] @decoration of classes
On Sat, 26 Mar 2005 22:49:33 +0100, Eric Nieuwland <[EMAIL PROTECTED]> wrote: >On 26 mrt 2005, at 21:36, Josiah Carlson wrote: > > Eric Nieuwland <[EMAIL PROTECTED]> wrote: > >> Given the ideas so far, would it possible to: > >> > >> def meta(cls): > >>... > >> > >> @meta > >> class X(...): > >>... > > > > It is not implemented in Python 2.4. From what I understand, making it > > happen in Python 2.5 would not be terribly difficult. The question is > > about a "compelling use case". Is there a use where this syntax is > > significantly better, easier, etc., than an equivalent metaclass? > > Would > > people use the above syntax if it were available? > > > > What would you use the above syntax to do? > > Well, I can imagine using > > @meta(MyMetaClass) > class MyClass(...): > ... > > instead of > > class MyClass(...): > __metaclass__ = MyMetaClass > ... > > Somehow, it seems more aesthetic to me. This doesn't quite work the same, though. The former creates a new instance of ClassType, then (presumably) rips it apart and passes the pieces to MyMetaClass. The latter just passes the pieces to MyMetaClass unassembled. I can imagine cases where the class creation would fail during the first step of the former process, so I don't think this is actually a use-case for class decorators. Jp ___ 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] Security capabilities in Python
On Sat, 9 Apr 2005 00:13:40 -0500 (CDT), Ka-Ping Yee <[EMAIL PROTECTED]> wrote: >On Fri, 8 Apr 2005, Eyal Lotem wrote: > > I would like to experiment with security based on Python references as > > security capabilities. > > This is an interesting and worthwhile thought. Several people > (including myself) have talked about the possibility of doing > this in the past. I believe the two problems you mention can be > addressed without modifying the Python core. > > > * There is no way to create secure proxies because there are no > > private attributes. > > Attributes are not private, but local variables are. If you use > lexical scoping to restrict variable access (as one would in > Scheme, E, etc.) you can create secure proxies. See below. > > > * Lots of Python objects are reachable unnecessarily breaking the > > principle of least privelege (i.e: object.__subclasses__() etc.) > > True. However, Python's restricted execution mode prevents access > to these attributes, allowing you to enforce encapsulation. (At > least, that is part of the intent of restricted execution mode, > though currently we do not make official guarantees about it.) > Replacing __builtins__ activates restricted execution mode. > > Here is a simple facet function. > > def facet(target, allowed_attrs): > class Facet: > def __repr__(self): > return '' % (allowed_attrs, target) > def __getattr__(self, name): > if name in allowed_attrs: > return getattr(target, name) > raise NameError(name) > return Facet() > > def restrict(): > global __builtins__ > __builtins__ = __builtins__.__dict__.copy() > > # Here's an example. > > list = [1, 2, 3] > immutable_facet = facet(list, ['__getitem__', '__len__', '__iter__']) > > # Here's another example. > > class Counter: > def __init__(self): > self.n = 0 > > def increment(self): > self.n += 1 > > def value(self): > return self.n > > counter = Counter() > readonly_facet = facet(counter, ['value']) > > If i've done this correctly, it should be impossible to alter the > contents of the list or the counter, given only the immutable_facet > or the readonly_facet, after restrict() has been called. > > (Try it out and let me know if you can poke holes in it...) > > The upshot of all this is that i think you can do secure programming > in Python if you just use a different style. Unfortunately, this > style is incompatible with the way classes are usually written in > Python, which means you can't safely use much of the standard library, > but i believe the language itself is not fatally flawed. > Does using the gc module to bypass this security count? If so: [EMAIL PROTECTED]:~$ python -i facet.py >>> import gc >>> c = readonly_facet.__getattr__.func_closure[1] >>> r = gc.get_referents(c)[0] >>> r.n = 'hax0r3d' >>> readonly_facet.value() 'hax0r3d' >>> This is the easiest way of which I know to bypass the use of cells as a security mechanism. I believe there are other more involved (and fragile, probably) ways, though. Jp ___ 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] PEP 340: Else clause for block statements
On Mon, 02 May 2005 07:46:31 -0600, Shane Hathaway <[EMAIL PROTECTED]> wrote:
>Anders J. Munch wrote:
>> in opening('file1') as f1:
>> ...
>> in opening('file2') as f2:
>> ...
>> except IOError:
>> print "file1 not available, I'll try again later"
>>
>> I rather like this version, because it is patently clear what should
>> happen if there is no except-clause: The exception propagates
>> normally.
>
>My eyes would expect the exception handler to also catch IOErrors
>generated inside the block statement body. My eyes would be deceiving
>me, of course, but Python isn't currently so subtle and it probably
>shouldn't be.
>
>You could also do this with a suitable iterator.
>
>def opening_or_skipping(fn):
>try:
>f = open(fn)
>except IOError:
>print "file1 not available, I'll try again later"
>else:
>try:
>yield f
>finally:
>f.close()
I don't think this version is really of much use. It requires that you
implement a different iterator for each kind of error handling you want to do.
Avoiding multiple different implementations is supposed to be one of the main
selling points of this feature.
Jp
___
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] PEP 340: Deterministic Finalisation (new PEP draft, either a competitor or update to PEP 340)
On Sun, 08 May 2005 14:16:40 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: >Ron Adam wrote: >> I agree, re-using or extending 'for' doesn't seem like a good idea to me. > >I agree that re-using a straight 'for' loop is out, due to performance and >compatibility issues with applying finalisation semantics to all such iterative >loops (there's a reason the PEP redraft doesn't suggest this). > >However, it makes sense to me that a "for loop with finalisation" should >actually *be* a 'for' loop - just with some extra syntax to indicate that the >iterator is finalised at the end of the loop. > >An option other than the one in my PEP draft would be to put 'del' at the end >of >the line instead of before EXPR: > > for [VAR in] EXPR [del]: > BLOCK1 > else: > BLOCK2 > >However, as you say, 'del' isn't great for the purpose, but I was trying to >avoid introduding yet another keyword. An obvious alternative is to use >'finally' instead: > > for [finally] [VAR in] EXPR: > BLOCK1 > else: > BLOCK2 > >It still doesn't read all that well, but at least the word more accurately >reflects the semantics involved. If such a construct is to be introduced, the ideal spelling would seem to be: for [VAR in] EXPR: BLOCK1 finally: BLOCK2 Jp ___ 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] Wishlist: dowhile
On Mon, 13 Jun 2005 01:25:51 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >At 09:01 PM 6/12/2005 -0700, Guido van Rossum wrote: >>If we have to do this, PEP 315 has my +0. >> >>It is Pythonically minimal and the motivation rings true: I've often >>written code like this in the past: >> >> line = f.readline() >> while line: >> >> line = f.readline() >> >>But these days we do that using "for line in f". > >Block-copying a file with read() has the same pattern (e.g. in shutil), but >you can't make it a for loop. Anything can be a for loop. for chunk in iter(lambda: f1.read(CHUNK_SIZE), ''): f2.write(chunk) Jp ___ 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] reducing self.x=x; self.y=y; self.z=z boilerplate code
On Fri, 01 Jul 2005 19:22:20 -0400, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: >At 03:59 PM 7/1/2005 -0700, Ralf W. Grosse-Kunstleve wrote: > [snip] > >This extends to any number of arguments: > > class grouping: > def __init__(self, x, y, z): > self.__dict__.update(locals()) > del self.self If you use vars(self).update(locals()), it even looks halfway pleasant ;) I'm not sure what python-dev's current opinion of vars(obj) is though (I'm hoping someone'll tell me). Of course, both of these fall over for __slots__'ful classes. It'd be nice if there were a general way to deal with attributes of an instance, regardless of the implementation details of its memory layout. Jp ___ 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] Pythonic concurrency - cooperative MT
On Fri, 30 Sep 2005 17:26:27 +0200, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > >Hi, > >> I've never heard >> someone complain that the GIL is in the way for these types of apps. > >I've never said so either. >I was just saying that it can be useful to mix cooperative threading and >preemptive threading in the same app, i.e. have different domains of >cooperative threading which are preemptively scheduled by the OS. That >has nothing to do with the GIL, I think (but I don't know much in Python >internals). > >For instance the mix between Twisted and GUI event loops is a very >common topic on the twisted mailing-list, because people have trouble >getting it right inside a single system thread. The Twisted people have >started advocating something called the ThreadedSelectReactor, which I >haven't looked at but whose name suggests that some operations are >performed in a helper system thread. > "Advocating" might be putting it too strongly :) "Experimenting with" describes the current state of things most accurately. The problem it aims to solve is integration with cooperative threading systems which don't work very well. An example of such a loop is the wx event loop. Whenever a modal dialog is displayed or a menu is activated, wx's loop stops cooerating. The only way we've found thus far to avoid this is to run wx in a separate thread, so even when it stops cooperating, network code can still get scheduled. Jp ___ 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] C.E.R. Thoughts
On Sat, 8 Oct 2005 20:04:13 -0400, jamesr <[EMAIL PROTECTED]> wrote: >Congragulations heartily given. I missed the ternary op in c... Way to >go! clean and easy and now i can do: > >if ((sys.argv[1] =='debug') if len(sys.argv) > 1 else False): > pass > >and check variables IF AND ONLY if they exist, in a single line! if len(sys.argv) > 1 and sys.argv[1] == 'debug': ... usually-wouldn't-but-can't-pass-it-up-ly y'rs, Jp ___ 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
