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
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] 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] 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: do something 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] 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] 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] 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 'Facet %r on %r' % (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] 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] 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)) unbound method 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)) unbound method 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
