[Python-Dev] Re: PEP 642: Constraint Pattern Syntax for Structural Pattern Matching

I think using symbols like ? and == in patterns looks stylistically ugly, and unintuitive, albeit more explicit. I, too, would rather have pattern matching more explicit, but it shouldn't need to be so ugly (yes, I know, ugly is a subjective term, so be it). I would propose that, opposite to

[Python-Dev] Re: Pattern matching reborn: PEP 622 is dead, long live PEP 634, 635, 636

It's true that asyncio.wait provides the tools that you need, but it's a bit clunky to use correctly. Maybe would be something along the lines of: -- queue1 = asyncio.Queue() queue2 = asyncio.Queue() ... get1 = asyncio.create_task(queue1.get()) get2 = asyncio.create_task(queue2.get()) await

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, 17 Jul 2020 at 12:26, wrote: > Hello everyone, > > I'm sorry if my proposition has already being said, or even withdrawn, > but I think that capture variables shouldn't be as implicit as they > are now. I didn't see any mention of capture variable patterns in > the rejected ideas. So

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Fri, 10 Jul 2020 at 10:33, Glenn Linderman wrote: > On 7/10/2020 1:21 AM, Stefano Borini wrote: > > Just my 2 cents, I find it kind of annoying that the whole structure > > requires two levels of indentation to actually reach the operational > > code. > > This would be a first in python. > >

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

*facepalm* this is right there in the PEP, already, as one possible alternative. Apologies for the noise. :-/ On Wed, 8 Jul 2020 at 19:27, Gustavo Carneiro wrote: > > > On Wed, 8 Jul 2020 at 16:05, Guido van Rossum wrote: > >> Today I’m happy (and a little trepidatious) to

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On Wed, 8 Jul 2020 at 16:05, Guido van Rossum wrote: > Today I’m happy (and a little trepidatious) to announce the next > version of PEP 622, Pattern Matching. As authors we welcome Daniel F > Moisset in our midst. Daniel wrote a lot of the new text in this > version, which introduces the

[Python-Dev] Re: PEP 620: Hide implementation details from the C API

On Wed, 24 Jun 2020 at 17:22, Victor Stinner wrote: [...] > The question becomes: how to promote the limited C API? Should it > become the default, rather than an opt-in option? > It would be interesting to find out what is the performance impact of using limited C API, vs normal API, on some

Re: [Python-Dev] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

On Thu, 14 Feb 2019 at 15:52, Victor Stinner wrote: > Le jeu. 14 févr. 2019 à 14:38, Matthias Klose a écrit : > > Debian's concern about pointing python to python3 is that it will break > software > > after an upgrade. The current state seems is still the same that Debian > doesn't > > want to

Re: [Python-Dev] PEP 572: intended scope of assignment expression

On Thu, 5 Jul 2018 at 13:43, Victor Stinner wrote: > Hi, > > My work (*) in the "Assignment expression and coding style: the while > True case" thread helped me to understand something about the > *intended* scope. > > While technically, assignment expressions keep the same scoping rules > than

Re: [Python-Dev] A more flexible task creation

On Fri, 15 Jun 2018 at 09:18, Michel Desmoulin wrote: > > > > > The strict API compatibility requirements of core Python stdlib, coupled > > with the very long feature release life-cycles of Python, make me think > > this sort of thing perhaps is better built in an utility library on top > > of

Re: [Python-Dev] A more flexible task creation

On Thu, 14 Jun 2018 at 17:40, Tin Tvrtković wrote: > Hi, > > I've been using asyncio a lot lately and have encountered this problem > several times. Imagine you want to do a lot of queries against a database, > spawning 1 tasks in parallel will probably cause a lot of them to fail. > What

Re: [Python-Dev] PEP 572: Why not := as standard assignment operator?

On 26 April 2018 at 16:18, Chris Angelico wrote: > On Thu, Apr 26, 2018 at 11:13 PM, Martin Teichmann > wrote: > > Hi list, > > > > when reading PEP 572 I actually liked it a lot - I think it's actually > > a cool idea. I think it's actually that cool

Re: [Python-Dev] Proposal: go back to enabling DeprecationWarning by default

Big +1 to turning warnings on by default again. When this behaviour first started, first I was surprised, then annoyed that warnings were being suppressed. For a few years I learned to have `export PYTHONWARNINGS=default` in my .bashrc. But eventually, the warnings in 3rd-party Python modules

Re: [Python-Dev] PEP 557: Data Classes

On 12 October 2017 at 11:20, Steve Holden wrote: > On Thu, Oct 12, 2017 at 9:20 AM, Mike Miller > wrote: > >> >> On 2017-10-12 00:36, Stéfane Fermigier wrote: >> >>> "An object that is not defined by its attributes, but rather by a thread >>> of

Re: [Python-Dev] PEP 557: Data Classes

Hi, it is not clear whether anything is done to total_cost: def total_cost(self) -> float: Does this become a property automatically, or is it still a method call? To that end, some examples of *using* a data class, not just defining one, would be helpful. If it remains a normal method, why

Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub

On 10 December 2016 at 13:49, M.-A. Lemburg wrote: [...] > Regardless of the name, it'll be interesting to see whether > there's demand for such a fork. Without a website, binaries > to download, documentation, etc. it's still in the very early > stages. > IMHO, whether or not

Re: [Python-Dev] PEP 8 updated on whether to break before or after a binary update

On 15 April 2016 at 18:03, Victor Stinner wrote: > Hum. > > if (width == 0 > and height == 0 > and color == 'red' > and emphasis == 'strong' > or highlight > 100): > raise ValueError("sorry, you lose")

Re: [Python-Dev] asyncio: how to interrupt an async def w/ finally: ( e.g. Condition.wait() )

I tried to reproduce the problem you describe, but failed. Here's my test program (forgive the awful tab indentation, long story): -- import asyncio async def foo(): print("resource acquire") try: await asyncio.sleep(100) finally: print("resource release") async def main(): task =

Re: [Python-Dev] Make stacklevel=2 by default in warnings.warn()

On 20 September 2015 at 07:55, Nathaniel Smith wrote: > On Sat, Sep 19, 2015 at 11:44 PM, Serhiy Storchaka > wrote: > > For now the default value of the stacklevel parameter in warnings.warn() > is > > 1. But in most cases stacklevel=2 is required, sometimes

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

On 5 September 2015 at 09:44, haypo s wrote: > 2015-09-05 5:01 GMT+02:00 Guido van Rossum : > > And I'm ready to accept it. I'll wait until Tuesday night (Monday's a > > holiday in the US) in case anything unforeseen comes up, but this is > really > >

Re: [Python-Dev] PEP 498: Literal String Interpolation is ready for pronouncement

Why not allow string concatenation without plus sign only if/when the implementation becomes optimised to allow compile time concatenation? This makes it crystal clear whether the concatenation is compile time or runtime. If we allow it now, it's hard to tell without looking at the CPython source

Re: [Python-Dev] provisional status for asyncio

I think this is a packaging problem. In an ideal world, Python would ship some version of asyncio, but you would also be able to pip install a newer version into your virtual environment, and it would override the version in stdlib. As it stands now, however, if you pip install another version

Re: [Python-Dev] provisional status for asyncio

On 28 August 2015 at 17:11, Yury Selivanov yselivanov...@gmail.com wrote: On 2015-08-28 11:44 AM, Brett Cannon wrote: Unfortunately, separating it from the standard library is something that I don't think we can do so late in the 3.5 release candidates process. Ultimately

Re: [Python-Dev] PEP 492: async/await in Python; version 4

On 1 May 2015 at 16:31, Guido van Rossum gu...@python.org wrote: On Fri, May 1, 2015 at 5:50 AM, Stefan Behnel stefan...@behnel.de wrote: Yury Selivanov schrieb am 30.04.2015 um 03:30: 1. Terminology: - *native coroutine* term is used for async def functions. When I read native, I think

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

On 21 April 2015 at 11:56, Rob Cliffe rob.cli...@btinternet.com wrote: On 21/04/2015 10:33, Cory Benfield wrote: On 21 April 2015 at 10:10, Chris Angelico ros...@gmail.com ros...@gmail.com wrote: At this point, you may want to just stop caring about the exact type. Part of the point of

Re: [Python-Dev] Requesting pronouncement on PEP 463: Exception-catching expressions

On 12 March 2014 15:21, Brett Cannon br...@python.org wrote: On Wed, Mar 12, 2014 at 11:16 AM, Chris Angelico ros...@gmail.com wrote: On Thu, Mar 13, 2014 at 2:14 AM, Brett Cannon br...@python.org wrote: While I'm +0 on the idea, I'm -1 on the syntax; I just don't like having a

Re: [Python-Dev] python 3 niggle: None 1 raises TypeError

On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None return a TypeError in comparisons, since it makes many typical data operations fail, e.g. I don't

Re: [Python-Dev] python 3 niggle: None 1 raises TypeError

On 17 February 2014 11:43, M.-A. Lemburg m...@egenix.com wrote: On 17.02.2014 12:23, Gustavo Carneiro wrote: On 17 February 2014 11:14, M.-A. Lemburg m...@egenix.com wrote: On 15.02.2014 07:03, Stephen J. Turnbull wrote: M.-A. Lemburg writes: IMO, it was a mistake to have None

Re: [Python-Dev] python 3 niggle: None 1 raises TypeError

On 17 February 2014 12:30, M.-A. Lemburg m...@egenix.com wrote: On 17.02.2014 13:19, Serhiy Storchaka wrote: 17.02.14 13:56, M.-A. Lemburg написав(ла): Yes, but that's not the point. Unlike strings or other mixed types that you cannot compare, None is used as placeholder in data processing

Re: [Python-Dev] News from asyncio

On 27 January 2014 10:55, Victor Stinner victor.stin...@gmail.com wrote: 2014-01-27 Antoine Pitrou solip...@pitrou.net: On Mon, 27 Jan 2014 10:45:37 +0100 Victor Stinner victor.stin...@gmail.com wrote: - Tulip #111: StreamReader.readexactly() now raises an IncompleteReadError if the

Re: [Python-Dev] Python 3 as a Default in Linux Distros

On Wed, Jul 24, 2013 at 6:04 PM, Terry Reedy tjre...@udel.edu wrote: On 7/24/2013 5:12 AM, Bohuslav Kabrda wrote: Hi all, in recent days, there has been a discussion on fedora-devel (see thread [1]) about moving to Python 3 as a default. Default-shift is a known natural language

Re: [Python-Dev] stat module in C -- what to do with stat.py?

On Fri, Jun 21, 2013 at 8:20 PM, Steven D'Aprano st...@pearwood.infowrote: On 21/06/13 01:35, Benjamin Peterson wrote: 2013/6/20 Charles-François Natali cf.nat...@gmail.com: 2013/6/20 Thomas Wouters tho...@python.org: If the .py file is going to be wrong or incomplete, why would we want to

Re: [Python-Dev] PEP 443 - request for pronouncement

On Fri, May 31, 2013 at 11:34 AM, Łukasz Langa luk...@langa.pl wrote: On 31 maj 2013, at 12:18, Gustavo Carneiro gjcarne...@gmail.com wrote: It is not clear from the PEP (up until the end of the User API section at least) when, if ever, is this implementation of fun ever called. I mean

Re: [Python-Dev] PEP 443 - request for pronouncement

Sorry, maybe I am too late to comment on this, but, @singledispatch ... def fun(arg, verbose=False): ... if verbose: ... print(Let me just say,, end= ) ... print(arg) It is not clear from the PEP (up until the end of the User API section at least) when, if ever, is

[Python-Dev] OSError.errno = exception hierarchy?

Apologies if this has already been discussed. I was expecting that by now, python 3.0, the following code: # clean the target dir import errno try: shutil.rmtree(trace_output_path) except OSError, ex: if ex.errno not

Re: [Python-Dev] OSError.errno = exception hierarchy?

(cross-posting back to python-dev to finalize discussions) 2009/4/2 Guido van Rossum gu...@python.org [...] The problem you report: try: ... except OSWinError: ... except OSLinError: ... Would be solved if both OSWinError and OSLinError were always defined in

Re: [Python-Dev] PEP 3142: Add a while clause to generator expressions

2009/1/19 Vitor Bosshard algor...@yahoo.com - Mensaje original De: Gerald Britton gerald.brit...@gmail.com Para: Terry Reedy tjre...@udel.edu CC: python-dev@python.org Enviado: lunes, 19 de enero, 2009 15:03:47 Asunto: Re: [Python-Dev] PEP 3142: Add a while clause to

Re: [Python-Dev] Python under valgrind

2008/11/28 Hrvoje Niksic [EMAIL PROTECTED] A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. Reading up on Misc/README.valgrind only seems to describe why uninitialized reads should occur, not invalid ones. For example:

Re: [Python-Dev] Problems with the new super()

2008/5/1 Facundo Batista [EMAIL PROTECTED]: 2008/5/1, Georg Brandl [EMAIL PROTECTED]: There may be more implications and surprising behavior surrounding this. I know that the implementation is a compromise, but I'd rather see a super() whose full semantics can be explained to

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 10/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: Adam I are now on #python-dev. Can you join? I think we successfully resolved this. Adam Olsen will produce a patch that allows one to specify a single file descriptor to which a zero byte will be written by the C-level signal

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 11/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: On Dec 10, 2007 4:07 PM, Gustavo Carneiro [EMAIL PROTECTED] wrote: On 10/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: Adam I are now on #python-dev. Can you join? I think we successfully resolved this. Adam Olsen

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 08/12/2007, Johan Dahlin [EMAIL PROTECTED] wrote: Guido van Rossum wrote: Adam, perhaps at some point (Monday?) we could get together on #python-dev and interact in real time on this issue. Probably even better on the phone. This offer is open to anyone who is serious about getting

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 08/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: On Dec 8, 2007 3:58 AM, Gustavo Carneiro [EMAIL PROTECTED] wrote: Not only that, but pygtk is a generic module; What does generic mean in this context? Surely not that it applies to other libraries than GTK? Well, actually

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

the select()/poll() system call is entered will not be noticed until the select()/poll() call completes). Sorry, I misattributed this; Gustavo Carneiro pointed this out earlier in this thread. BTW, in the referenced post (also by Gustavo), I found this: According to [1], all python needs

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 08/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: On Dec 8, 2007 9:57 AM, Gustavo Carneiro [EMAIL PROTECTED] wrote: On 08/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: On Dec 8, 2007 3:58 AM, Gustavo Carneiro [EMAIL PROTECTED] wrote: Not only that, but pygtk is a generic

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 09/12/2007, Guido van Rossum [EMAIL PROTECTED] wrote: On Dec 8, 2007 3:57 PM, Adam Olsen [EMAIL PROTECTED] wrote: On Dec 8, 2007 4:28 PM, Guido van Rossum [EMAIL PROTECTED] wrote: On Dec 8, 2007 2:36 PM, Adam Olsen [EMAIL PROTECTED] wrote: On Dec 8, 2007 2:56 PM, [EMAIL

Re: [Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).

On 07/12/2007, Sean Reifschneider [EMAIL PROTECTED] wrote: On Thu, Dec 06, 2007 at 10:55:12PM -0700, Adam Olsen wrote: That's pretty much what issue1564547 does. I think there's two marks Good point, I hadn't seen that before. * Using poll and fd's is pretty platform specific for what

Re: [Python-Dev] for loop with if filter

On 16/11/2007, Benji York [EMAIL PROTECTED] wrote: Gustavo Carneiro wrote: I am finding myself often doing for loops over a subset of a list, like: for r in results: if r.numNodes != numNodes: continue # do something with r It would

[Python-Dev] for loop with if filter

I am finding myself often doing for loops over a subset of a list, like: for r in results: if r.numNodes != numNodes: continue # do something with r It would be nice if the plain for loop was as flexible as list comprehensions and allowed an

Re: [Python-Dev] GC Changes

On 02/10/2007, Adam Olsen [EMAIL PROTECTED] wrote: On 10/1/07, Greg Ewing [EMAIL PROTECTED] wrote: Justin Tulloss wrote: Would somebody care to give me a brief overview on how the current gc module interacts with the interpreter The cyclic GC kicks in when memory is running low.

Re: [Python-Dev] GC Changes

On 02/10/2007, Hrvoje Nikšić [EMAIL PROTECTED] wrote: On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote: Correct. And that reminds me of the limitation of the the Python GC: it doesn't take into account how much memory is being indirectly retained by a Python Object. Like

Re: [Python-Dev] GC Changes

On 01/10/2007, Justin Tulloss [EMAIL PROTECTED] wrote: Hello, I've been doing some tests on removing the GIL, and it's becoming clear that some basic changes to the garbage collector may be needed in order for this to happen efficiently. Reference counting as it stands today is not very

Re: [Python-Dev] working with Python threads from C extension module?

On 08/09/2007, Bill Janssen [EMAIL PROTECTED] wrote: Be convoluted yourself and do this: #define PySSL_BEGIN_ALLOW_THREADS { if (_ssl_locks) { Py_BEGIN_ALLOW_THREADS #define PySSL_END_ALLOW_THREADS Py_END_ALLOW_THREADS } } (Untested, but I think it should work.) Yes, that had

[Python-Dev] Python 2.6 BaseException.message deprecation, really needed?

In PyGObject we want to use a 'message' attribute in an exception defined by us. The name 'message' comes from a C API, therefore we would like to keep it for easier mapping between C and Python APIs. Why does Python have to deprecate this attribute? .../gobject/option.py:187:

Re: [Python-Dev] Instance variable access and descriptors

While you're at it, it would be nice to fix this ugly asymmetry I found in descriptors. It seems that descriptor's __get__ is called even when accessed from a class rather than instance, but __set__ is only invoked from instances, never from classes: class Descr(object): def __get__(self,

Re: [Python-Dev] Fwd: Instance variable access and descriptors

I have to agree with you. If removing support for self.__dict__['propertyname'] (where propertyname is also the name of a descriptor) is the price to pay for significant speedup, so be it. People doing that are asking for trouble anyway! On 10/06/07, Eyal Lotem [EMAIL PROTECTED] wrote: On

Re: [Python-Dev] New Super PEP

On 29/04/07, James Y Knight [EMAIL PROTECTED] wrote: On Apr 28, 2007, at 10:43 PM, Calvin Spealman wrote: Abstract The PEP defines the proposal to enhance the super builtin to work implicitly upon the class within which it is used and upon the instance the current function was

Re: [Python-Dev] Python 3000 PEP: Postfix type declarations

On 4/1/07, Georg Brandl [EMAIL PROTECTED] wrote: [...] Example === This is the standard ``os.path.normpath`` function, converted to type declaration syntax:: def normpathƛ(path✎)✎: Normalize path, eliminating double slashes, etc. if path✎ == '': return

Re: [Python-Dev] Python 3000 PEP: Postfix type declarations

On 4/1/07, Gustavo Carneiro [EMAIL PROTECTED] wrote: On 4/1/07, Georg Brandl [EMAIL PROTECTED] wrote: [...] Example === This is the standard ``os.path.normpath`` function, converted to type declaration syntax:: def normpathƛ(path✎)✎: Normalize path, eliminating

Re: [Python-Dev] Rationale for NamedTemporaryFile?

On 3/21/07, Scott Dial [EMAIL PROTECTED] wrote: Greg Ewing wrote: A tangential question -- why are TemporaryFile and NamedTemporaryFile named in TitleCase, when they're functions and not classes? I wondered the same. At first draft of my email I wrote class operating under the assumption

Re: [Python-Dev] pydoc II

On 3/11/07, Laurent Gautier [EMAIL PROTECTED] wrote:[...] A prototype is being worked on, and I have been looking at code and/or functionalities in pydoc, epydoc, pydoctor, and ipython (for the interactive console), and there a lot of nice things in all these efforts. The name of the game is

Re: [Python-Dev] New syntax for 'dynamic' attribute access

On 2/11/07, Ben North [EMAIL PROTECTED] wrote: Hi, A few days ago I posted to python-ideas with a suggestion for some new Python syntax, which would allow easier access to object attributes where the attribute name is known only at run-time. For example: setattr(self, method_name,

Re: [Python-Dev] Problem with signals in a single threaded application

On 1/24/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Gustavo Carneiro schrieb: What about http://www.python.org/sf/1564547 ? It tries to solve a different problem, but I think it also fixes this one; at least as much as possible with the braindead unix signal programming interface

Re: [Python-Dev] Problem with signals in a single threaded application

On 1/24/07, Martin v. Löwis [EMAIL PROTECTED] wrote: Ulisses Furquim schrieb: I've read some threads about signals in the archives and I was under the impression signals should work reliably on single-threaded applications. Am I right? I've thought about a way to fix this, but I don't know

Re: [Python-Dev] Polling with Pending Calls?

This patch may interest you: http://www.python.org/sf/1564547 Not sure it completely solves your case, but it's at least close to your problem. On 12/4/06, Tony Nelson [EMAIL PROTECTED] wrote: I think I have a need to handle *nix signals through polling in a library. It looks like chaining

Re: [Python-Dev] Signals, threads, blocking C functions

- http://www.python.org/sf/1564547 -- Gustavo J. A. M. Carneiro The universe is always one step beyond logic. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

Re: [Python-Dev] Grammar change in classdef

On 9/16/06, Talin [EMAIL PROTECTED] wrote: Nick Coghlan wrote: As for the reason: it makes it possible to use the same style for classes without bases as is used for functions without arguments. Prior to this change, there was a sharp break in the class syntax, such that if you got rid

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote: On 9/12/06, Gustavo Carneiro [EMAIL PROTECTED] wrote: On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote: My previous mention of using a *single* flag may survive corruption simply because we can tolerate false positives. Signal handlers would

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/12/06, Adam Olsen [EMAIL PROTECTED] wrote: On 9/12/06, Greg Ewing [EMAIL PROTECTED] wrote: Adam Olsen wrote: That brings you back to how you access the flags variable. The existing signal handler sets a flag, doesn't it? So it couldn't be any more broken than the current

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/11/06, Adam Olsen [EMAIL PROTECTED] wrote: Now on to my new proposal. I do still use write(). If you can't accept that I think we should rip signals out entirely, just let them kill the process. Not a reliable feature of any OS. We create a single pipe and use it for all signals. We

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/9/06, Jan Kanis [EMAIL PROTECTED] wrote: At the risk of waking up a thread that was already declared dead, but perhaps this is usefull. So, what happens is pythons signal handler sets a flag and registrers a callback. Then the main thread should check the flag and make the callback to

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/9/06, Adam Olsen [EMAIL PROTECTED] wrote: On 9/8/06, Adam Olsen [EMAIL PROTECTED] wrote: Ensuring modifications to that array are atomic would be tricky, but I think it would be doable if we use a read-copy-update approach (with two alternating signal handler functions). Not sure how

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/9/06, Nick Maclaren [EMAIL PROTECTED] wrote: I was hoping to have stopped, but here are a few comments. I agree with Jan Kanis. That is the way to tackle this one. Alas, it doesn't work in practice, as I already replied. [...] Despite the implication, the code of Py_AddPendingCall is

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/5/06, Adam Olsen [EMAIL PROTECTED] wrote: On 9/4/06, Gustavo Carneiro [EMAIL PROTECTED] wrote: Now, we've had this API for a long time already (at least 2.5 years). I'm pretty sure it works well enough on most *nix systems. Event if it works 99% of the times, it's way better than

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/4/06, Nick Maclaren [EMAIL PROTECTED] wrote: Gustavo Carneiro [EMAIL PROTECTED] wrote: I am now thinking of something along these lines: typedef void (*PyPendingCallNotify)(void *user_data); PyAPI_FUNC(void) Py_AddPendingCallNotify(PyPendingCallNotify callback, void *user_data

Re: [Python-Dev] Signals, threads, blocking C functions

In GLib we have a child watch notification feature that relies on the following signal handler: static void g_child_watch_signal_handler (int signum) { child_watch_count ++; if (child_watch_init_state == CHILD_WATCH_INITIALIZED_THREADED) { write (child_watch_wake_up_pipe[1], B,

[Python-Dev] Signals, threads, blocking C functions

We have to resort to timeouts in pygtk in order to catch unix signals in threaded mode. The reason is this. We call gtk_main() (mainloop function) which blocks forever. Suppose there are threads in the program; then any thread can receive a signal (e.g. SIGINT). Python catches the signal, but

Re: [Python-Dev] Signals, threads, blocking C functions

On 9/2/06, Nick Maclaren [EMAIL PROTECTED] wrote: According to [1], all python needs to do to avoid this problem is block all signals in all but the main thread; then we can guarantee signal handlers are always called from the main thread, and pygtk doesn't need a timeout. 1) That page is

Re: [Python-Dev] PyObject_CallFunction and 'N' format char

On 6/25/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Gustavo Carneiro wrote: However, PyObject_CallFunction does _not_ consume such an object reference, contrary to what I believed for years. Why do you say that? It certainly does. Yes it does. I could almost swear it didn't last

[Python-Dev] PyObject_CallFunction and 'N' format char

Sorry this is slightly offtopic, but I think it's important... According to recent experiments tracking down a memory leak, it seems that PyObject_CallFunction(func, N, object) and PyObject_CallFunction(func, O, object) are doing exactly the same thing. However, documentation says The C

Re: [Python-Dev] Shared libs on Linux (Was: test failures in test_ctypes (HEAD))

On 5/3/06, Thomas Heller [EMAIL PROTECTED] wrote: [Crossposting to both python-dev and ctypes-users, please respond to the listthat seems most appropriate]Guido van Rossum wrote: File /home/guido/projects/python/trunk/Lib/ctypes/__init__.py, line 288, in __init__ self._handle =

Re: [Python-Dev] Dropping __init__.py requirement for subpackages

, and I hope people find this a compelling argument in favour of eliminating the need for __init__.py. Regards,Gustavo Carneiro. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http

Re: [Python-Dev] Dropping __init__.py requirement for subpackages

On 4/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:Gustavo Carneiro [EMAIL PROTECTED] writes: Now the problem.Suppose you have the source package python-foo-bar, which installs $pythondir/foo/__init__.py and $pythondir/foo/bar.py.This would

Re: [Python-Dev] Dropping __init__.py requirement for subpackages

On 4/27/06, Thomas Wouters [EMAIL PROTECTED] wrote: On 4/27/06, Gustavo Carneiro [EMAIL PROTECTED] wrote: On 4/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 03:48 PM 4/27/2006 +0200, Bernhard Herzog wrote:Gustavo Carneiro [EMAIL PROTECTED] writes: Now the problem.Suppose you have

Re: [Python-Dev] Dropping __init__.py requirement for subpackages

On 4/27/06, Thomas Wouters [EMAIL PROTECTED] wrote: On 4/27/06, Gustavo Carneiro [EMAIL PROTECTED] wrote: Besides, Guido's original proposal is not a fix for your problem, either; he only proposes to change the requirement for *sub*packages. It *is* a solution for my problem. I don't need

Re: [Python-Dev] adding Construct to the standard library?

why include Construct?* the struct module is very nice, but very limited and non-pythonic as well * pure python (no platform/security issues) IMHO this is a drawback. More on this below. * lots of people need to parse and build binary data structures, it's not an esoteric library * license: public

Re: [Python-Dev] Class decorators

On 3/29/06, Phillip J. Eby [EMAIL PROTECTED] wrote: At 11:35 PM 3/28/2006 -0500, Fred L. Drake, Jr. wrote:For Zope 3, we have decorators that work with the component architecture (I'msure Phillip is familiar with these).They're used with functions toindicate that the function adapts a particular