Mailman 3 February 2013 - Python-ideas

Re: [Python-ideas] PEP for enum library type?
by Guido van Rossum Feb. 14, 2013

Feb. 14, 2013

After all the defenses I still don't like Tim's proposed syntax. Color me Barry. On Tue, Feb 12, 2013 at 11:54 AM, Tim Delaney <tim.delaney(a)aptare.com> wrote: > On 13 February 2013 06:13, Guido van Rossum <guido(a)python.org> wrote: >> >> So with Tim's implementation, what happens here: >> >> class Color(Enum): >> RED, GREEN, BLUE >> if sys.platform == 'win32': >> MAGENTA >> >> and you happen to have no "import sys" … [View More]

13 31

another enum implementation
by Ethan Furman Feb. 13, 2013

Feb. 13, 2013

I realize this isn't going very far, but I would still appreciate feedback. :) The code is here: https://bitbucket.org/stoneleaf/enum It is based on ideas from Michael Foord, Antoine Pitrou, and (eventually) Ted Delaney. Enum only accepts upper-case names as enum candidates; all enum values must be the same: either 'sequence' (0, 1, 2, etc) or 'flag' (1, 2, 4, etc.) or 'unique' (north, south, east, west, etc.); and extending via subclassing is possible. Sample code: class Color(Enum)… [View More]

3 5

constant/enum type in stdlib
by Joao S. O. Bueno Feb. 12, 2013

Feb. 12, 2013

This idea is not new - but it is stalled - Last I remember it came around in Python-devel in 2010, in this thread: http://mail.python.org/pipermail/python-dev/2010-November/thread.html#105967 There is an even older PEP (PEP 354) that was rejected just for not being enough interest at the time - And it was not dismissed at all - to the contrary the last e-mail in the thread is a message from the BDLF for it to **be** ! The discussion happened in a bad moment as Python was mostly freature … [View More]

23 80

PEP 3156 / Tulip: stopping the loop while in run_until_complete
by Saúl Ibarra Corretgé Feb. 11, 2013

Feb. 11, 2013

Hi, While analyzing some code I came across the following situation: - User calls run_until_complete for some Task - The task itself calls loop.stop() at some point - run_until_complete raises TimeoutError Here is a very simple example: https://gist.github.com/saghul/4754117 Something seems a bit off here. While one could argue that stopping the loop while run_until_complete is ongoing, getting a TimeoutError doesn't feel right. I think we should detect that the loop was stopped but the … [View More]

2 11

PEP 3156 / Tulip: Synchronization primitives
by Nikolay Kim Feb. 8, 2013

Feb. 8, 2013

I think Tulip should have synchronization primitives by default. Here is my motivation: 1. it is more convenient to use locking primitive with existing semantics rather than tulip magic. crawl.py example could use semaphore instead of tasks.wait with timeout 0. 2. while it seems easy to implement semaphore with tulip, it still requires deep understanding of tulips control flow. i had 2 not very obvious bugs in my semaphore implementation: a) release() could be called from different … [View More]

4 3

libuv based eventloop for tulip experiment
by Saúl Ibarra Corretgé Feb. 7, 2013

Feb. 7, 2013

Hi all! I haven't been able to keep up with all the tulip development on the mailing list (hopefully I will now!) so please excuse me if something I mention has already been discussed. For those who may not know it, libuv is the platform layer library for nodejs, which implements a uniform interface on top of epoll, kqueue, event ports and iocp. I wrote Python bindings [1] for it a while ago, and I was very excited to see Tulip, so I thought I'd give this a try. Here [2] is the source … [View More]

4 15

PEP 3156/Tulip: Extensible EventLoop interface
by Ben Darnell Feb. 7, 2013

Feb. 7, 2013

The event loop interface in PEP 3156 has an extensibility problem. It seems likely that it will have a method like listen_udp() by the time it's done, but suppose that doesn't make it into the first official release. Third-party event loop implementations may want to provide UDP support as an extension, but the most consistent way to provide that extension is by adding new methods on the event loop object, where various extensions risk conflicting with each other or with new methods that … [View More]become standardized later. The PEP specifies the add_reader family of methods in part so that core protocol implementations can be shared across all EventLoop implementations that support these methods. However, if those transports are implemented in a common base class (like Twisted's PosixReactorBase), there is no way for third-party transports to take advantage of a similar structure. I'd like to make it possible for transports to be developed independent of a particular EventLoop implementation in a way that is consistent with the way the core transports work. (This is a bigger concern for tulip than it is for twisted because twisted can update PosixReactorBase more frequently than the stdlib can change) I propose turning the interface around so that transport creation uses static functions that take the event loop as an argument, with a double-dispatch mechanism to allow the event loop to provide the actual implementation when it can: def create_connection(protocol_factory, host, port, event_loop=None): if event_loop is None: event_loop = get_event_loop() # Note the use of a fully-qualified name in the registry impl = event_loop.get_implementation('tulip.create_connection') return impl(protocol_factory, host, port) New third-party transports could provide fallbacks for event loops that don't have their own implementations: if impl is None: # These supports_*() functions are placeholders for a to-be-determined introspection interface. if supports_fd_interface(event_loop): return posix_udp_implementation(*args) elif supports_iocp_interface(event_loop): return iocp_udp_implementation(*args) else: raise Exception("This transport is not supported on this event loop") Or they could plug into the event loop's implementation registry: LibUVEventLoop.register_implementation('mymodule.listen_udp', libuv_udp_implementation) This does introduce a little magic (is there any precedent for this kind of multiple-dispatch in the standard library?), but I like the way it keeps the event loop interface from getting too big and monolithic. Third-party transports can avoid naming conflicts without looking fundamentally different from standard ones, and there's a clean path from doing something that's platform-specific (e.g. with add_reader and friends) to supporting multiple event loops to full standardization. -Ben [View Less]

10 30

PEP 3156 / Tulip: Remove 'when' from Handler
by Saúl Ibarra Corretgé Feb. 5, 2013

Feb. 5, 2013

Hi, While working on some changes for rose (an eventloop for tulip based on libuv) I realized the Handler class is a bit too coupled to the event loop implementation currently present in Tulip. pyuv (and pyev, and probably others) provide timers already, so there is no need to implement them "manually" and keep a heap with them. This basically means that Handler objects will always have the 'when' value set to None, and the comparison functions don't really apply, moreover __eq__ would … [View More]

2 2

Extend module objects to support properties
by Larry Hastings Feb. 4, 2013

Feb. 4, 2013

Properties are a wonderful facility. But they only work on conventional objects. Specifically, they *don't* work on module objects. It would be nice to extend module objects so properties worked there too. For example, Victor Stinner's currently proposed PEP 433 adds two new methods to the sys module: sys.getdefaultcloexc() and sys.setdefaultcloexc(). What are we, Java? Surely this would be much nicer as a property, sys.defaultcloexc. //arry/

10 20

Specification of procedures to store cryptographic secrets
by desnacked＠riseup.net Feb. 4, 2013

Feb. 4, 2013

Some hours ago I sent an email to python-crypto asking how to securely wipe cryptographic secrets from memory: http://mail.python.org/pipermail/python-crypto/2013-February/001170.html Antoine said that cryptographic secret wiping could be achieved if one uses bytearrays carefully and then overwrites their contents after use. I agree that this sounds reasonable, but I think it would be even better if that was a documented property of bytearrays. If that property of bytearrays was specified in … [View More]

7 7

for line in input with open(path) as input...
by Shane Green Feb. 3, 2013

Feb. 3, 2013

with open(path) as input: for line in input: do(line) Using with to create reference to opened file returned by open() so it could temporarily be assigned to input for the sole purpose of iterating its contents never sat very well with me. * The context manager returned by open() exists only to create the context and return reference "input"; * the context and code block created by the "with" only exists for inner "for" loop's code block to execute in. Now, given … [View More]

8 14

Re: [Python-ideas] for line in input with open(path) as input...
by Shane Green Feb. 2, 2013

Feb. 2, 2013

*From:* Serhiy Storchaka <storchaka(a)gmail.com> *Date:* February 2, 2013 5:50 AM *To:* python-ideas(a)python.org *Subject:* [Python-ideas] for line in input with open(path) as input... When should iterwith() call __exit__()? *From:* Shane Green <shane(a)umbrellacode.com> *Date:* February 2, 2013 5:55 AM *To:* Serhiy Storchaka <storchaka(a)gmail.com> *CC:* python-ideas(a)python.org *Subject:* [Python-ideas] for line in input with open(path) as input... iterwith() doesn't … [View More]

1 0

Re: [Python-ideas] PEP 3156: getting the socket or peer name from the transport
by Antoine Pitrou Feb. 1, 2013

Feb. 1, 2013

Le dimanche 27 janvier 2013 à 14:12 +0200, Yuval Greenfield a écrit : > On Sun, Jan 27, 2013 at 1:21 PM, Antoine Pitrou <solipsis(a)pitrou.net> > wrote: > > Most protocols should be written independent of transport. > But it seems to > > me that a user might write an entire app as a "protocol". > > > Well, such an assumption can fall flat. For example, > certificate > checking in HTTPS … [View More]

4 9

Definition Symmetry
by Jason Keene Feb. 1, 2013

Feb. 1, 2013

Why do function definitions require parens? >>> class MyClass: ... pass ... >>> def my_func: File "<stdin>", line 1 def my_func: ^ SyntaxError: invalid syntax This seems to me to break a symmetry with class definitions. I assume this is just a hold off from C, perhaps there is a non-historical reason tho. I believe in the past we've forced parens in list comprehensions to create a symmetry between comprehensions/generator expressions. Why not for this?

12 16