Re: [Python-Dev] futures API

On Sun, Dec 12, 2010 at 12:36 PM, Brian Quinlan wrote: > > On Dec 11, 2010, at 6:33 PM, Nick Coghlan wrote: > >> On Sun, Dec 12, 2010 at 6:53 AM, Brian Quinlan wrote: >>> >>> Is it still unclear why it is there? Maybe you could propose some >>> additional >>> documentation. >> >> Did you get my q

Re: [Python-Dev] futures API

On Dec 11, 2010, at 6:33 PM, Nick Coghlan wrote: On Sun, Dec 12, 2010 at 6:53 AM, Brian Quinlan wrote: Is it still unclear why it is there? Maybe you could propose some additional documentation. Did you get my question the other day as to whether a weakref.WeakKeySet might be a better ch

Re: [Python-Dev] futures API

--- El sáb, 11/12/10, Brian Quinlan escribió: > > On Dec 11, 2010, at 6:44 AM, Thomas Nagy wrote: > > > --- El vie, 10/12/10, Brian Quinlan escribió: > >> On Dec 10, 2010, at 10:51 AM, Thomas Nagy wrote: > >>> --- El vie, 10/12/10, Brian Quinlan > escribió: > On Dec 10, 2010, at 5:36 AM, Tho

Re: [Python-Dev] futures API

On Sun, Dec 12, 2010 at 6:53 AM, Brian Quinlan wrote: > Is it still unclear why it is there? Maybe you could propose some additional > documentation. Did you get my question the other day as to whether a weakref.WeakKeySet might be a better choice? I believe you would be able to get rid of the pe

Re: [Python-Dev] Format factories (was Re: sWAPcASE Was: transform() and untransform() methods, and the codec registry)

On Sun, Dec 12, 2010 at 5:21 AM, Brett Cannon wrote: > But is this worth it since once you write it you won't be changing it > again, suggesting that taking the time to look up the formatting rules > isn't that much harder and wouldn't burden us w/ writing such > functions and trying to come up wi

Re: [Python-Dev] futures API

Brian Quinlan wrote: On Dec 11, 2010, at 6:44 AM, Thomas Nagy wrote: I have also observed a minor performance degradation with the executor replacement (3 seconds for 5000 work items). The amount of work items processed by unit of time does not seem to be a straight line: http://www.freehac

Re: [Python-Dev] porting python.org

Am 11.12.2010 22:28, schrieb Terry Reedy: > On 12/11/2010 12:19 PM, Georg Brandl wrote: >> Am 11.12.2010 11:36, schrieb Prashant Kumar: >>> I was wondering if we could contribute in porting of python.org >>> website over to python3k. > > I think this is an excellent idea. It w

Re: [Python-Dev] Status of PEP 3143?

Ben Finney writes: > Done now (http://svn.python.org/projects/peps/trunk/>, revision > 87170). Thanks to Georg Brandl for applying the change on my behalf. -- \ “As the most participatory form of mass speech yet developed, | `\the Internet deserves the highest protection from gove

Re: [Python-Dev] porting python.org

On 12/11/2010 12:19 PM, Georg Brandl wrote: Am 11.12.2010 11:36, schrieb Prashant Kumar: I was wondering if we could contribute in porting of python.org website over to python3k. I think this is an excellent idea. It will test Python3 and the modules and external packages

Re: [Python-Dev] API for the new sysconfig module

On Dec 11, 2010, at 9:21 AM, Nick Coghlan wrote: > On Sun, Dec 12, 2010 at 12:17 AM, Antoine Pitrou wrote: >> On Sat, 11 Dec 2010 12:55:25 +1000 >> Nick Coghlan wrote: >> >>> On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy wrote: On 12/10/2010 4:59 PM, R. David Murray wrote: > Li

Re: [Python-Dev] Status of PEP 3143?

Benjamin Peterson writes: > 2010/12/8 Ben Finney : > > So it's not abandoned, but I don't know which version should be the > > current target. What change should I make to the PEP in such a case? > > Put 3.3 or 3.x if you're thinking really long term. :) Done now (http://svn.python.org/projects/

Re: [Python-Dev] futures API

On Dec 11, 2010, at 6:44 AM, Thomas Nagy wrote: --- El vie, 10/12/10, Brian Quinlan escribió: On Dec 10, 2010, at 10:51 AM, Thomas Nagy wrote: --- El vie, 10/12/10, Brian Quinlan escribió: On Dec 10, 2010, at 5:36 AM, Thomas Nagy wrote: I have a process running for a long time, and which

Re: [Python-Dev] Format factories (was Re: sWAPcASE Was: transform() and untransform() methods, and the codec registry)

On Sat, Dec 11, 2010 at 11:21 AM, Brett Cannon wrote: > On Thu, Dec 9, 2010 at 16:26, Nick Coghlan wrote: >> On Fri, Dec 10, 2010 at 9:29 AM, Antoine Pitrou wrote: >>> On Thu, 09 Dec 2010 18:10:38 -0500 >>> Eric Smith wrote: If we're looking to reduce the number of methods on str, I wouldn

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Fri, Dec 10, 2010 at 22:21, Vinay Sajip wrote: > Nick Coghlan gmail.com> writes: > > >> This could actually make a reasonably good basic for a "task oriented" >> subsection of the logging documentation. Something like: >> > > Good suggestion, I'll see what I can do. Just wanted to +1 on some

Re: [Python-Dev] Format factories (was Re: sWAPcASE Was: transform() and untransform() methods, and the codec registry)

On Thu, Dec 9, 2010 at 16:26, Nick Coghlan wrote: > On Fri, Dec 10, 2010 at 9:29 AM, Antoine Pitrou wrote: >> On Thu, 09 Dec 2010 18:10:38 -0500 >> Eric Smith wrote: >>> If we're looking to reduce the number of methods on str, I wouldn't mind >>> seeing center() and zfill() also go away, since t

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/11/2010 3:52 AM, Vinay Sajip wrote: I will try to incorporate more basic examples at the top of the documentation, but surely you don't want me to add more verbiage about basicConfig when your overall feeling is that there's too much documentation? I try not to post unless I feel there is

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Sun, Dec 12, 2010 at 3:24 AM, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/11/2010 04:28 AM, Vinay Sajip wrote: > >> Actually if we're to change things to print INFO to stdout and WARNING+ to >> stderr, > > ACK!  That would be an awful default -- stdout belongs

Re: [Python-Dev] porting python.org

Hi, On Sat, Dec 11, 2010 at 18:19, Georg Brandl wrote: >  Mako (http://www.makotemplates.org/) >  [Note that Mako requires setuptools to install out-of-the-box.  You can >   also just copy the lib/mako/ tree into your Python's site-packages >   directory if you prefer not to install setuptools.]

Re: [Python-Dev] Using logging in the stdlib and its unit tests

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/11/2010 04:28 AM, Vinay Sajip wrote: > Actually if we're to change things to print INFO to stdout and WARNING+ to > stderr, ACK! That would be an awful default -- stdout belongs to the application, not to "meta" stuff like logging, which shoul

Re: [Python-Dev] API for the new sysconfig module

On Sun, Dec 12, 2010 at 12:17 AM, Antoine Pitrou wrote: > On Sat, 11 Dec 2010 12:55:25 +1000 > Nick Coghlan wrote: > >> On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy wrote: >> > On 12/10/2010 4:59 PM, R. David Murray wrote: >> > >> >> Like Éric, I'm not sure what the implications of the existing

Re: [Python-Dev] porting python.org

Am 11.12.2010 11:36, schrieb Prashant Kumar: > I was wondering if we could contribute in porting of python.org > website over to python3k. If we can, what are the steps to > be taken and other necessary requirements? The SVN repository for python.org is currently not publicly a

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Sat, Dec 11, 2010 at 10:06 PM, Vinay Sajip wrote: > Nick Coghlan gmail.com> writes: > >> the logging module is a tool to track what is happening in a program, not a >> tool for providing a console based UI. > > That was certainly the thinking behind how it worked before my recent changes, > bu

Re: [Python-Dev] futures API

On 12/11/2010 9:44 AM, Thomas Nagy wrote: > The amount of work items processed by unit of time does not seem to be a > straight line: http://www.freehackers.org/~tnagy/runtime_futures_2.png . Out > of curiosity, what is the "_thread_references" for? > > The source file for the example is in: > h

Re: [Python-Dev] futures API

--- El vie, 10/12/10, Brian Quinlan escribió: > On Dec 10, 2010, at 10:51 AM, Thomas Nagy wrote: > > --- El vie, 10/12/10, Brian Quinlan escribió: > >> On Dec 10, 2010, at 5:36 AM, Thomas Nagy wrote: > >>> I have a process running for a long time, and > which > >> may use futures of different max_w

Re: [Python-Dev] API for the new sysconfig module

On Sat, 11 Dec 2010 12:55:25 +1000 Nick Coghlan wrote: > On Sat, Dec 11, 2010 at 12:44 PM, Terry Reedy wrote: > > On 12/10/2010 4:59 PM, R. David Murray wrote: > > > >> Like Éric, I'm not sure what the implications of the existing module > >> having been released in 2.7 and 3.2 beta are in terms

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Nick Coghlan gmail.com> writes: > the logging module is a tool to track what is happening in a program, not a > tool for providing a console based UI. That was certainly the thinking behind how it worked before my recent changes, but I completely accept that it wasn't helpful in the concurrent.f

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Glenn Linderman g.nevcal.com> writes: > the logger.  Does basicConfig give that control?  I don't know, the > first 8% of the logger documentation don't tell me that, they only > give me a canned example (actually 3) without explanation of its > full function.  Someday I'll read

[Python-Dev] porting python.org

I was wondering if we could contribute in porting of python.org website over to python3k. If we can, what are the steps to be taken and other necessary requirements? regards, prashant ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.o

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Sat, Dec 11, 2010 at 7:28 PM, Vinay Sajip wrote: > Nick Coghlan gmail.com> writes: > Actually if we're to change things to print INFO to stdout and WARNING+ to > stderr, I suspect our messages crossed paths in mid-stream, but I actually realised I was wrong on that front - the behaviour alrea

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/11/2010 1:07 AM, Nick Coghlan wrote: As Glenn mentioned later in the thread, the output of logging.info and logging.debug messages is*distinct* from an application's normal operational output that is emitted on stdout. So making it easy to emit such messages on stderr is the right thing to

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/11/2010 1:28 AM, Vinay Sajip wrote: Nick Coghlan gmail.com> writes: The "lazy" stream handler might be useful to make public in some way. For example, rather than hardcoding sys.stderr, it could take a callable that it uses to retrieve the stream. That kind of change can wait until 3.3 t

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On 12/11/2010 12:00 AM, Nick Coghlan wrote: On Sat, Dec 11, 2010 at 4:25 PM, Glenn Linderman wrote: On 12/10/2010 9:24 PM, Nick Coghlan wrote: This could actually make a reasonably good basic for a "task oriented" subsection of the logging documentation. Something like: Yep, agree. But sadly,

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Nick Coghlan gmail.com> writes: > The switching between percent, str.format and string.Template > formatting. It turns out that has been documented, but the table in > question is still written from a percent-style formatting point of > view. Oh, right - yes. I presume you mean the table in the

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Sat, Dec 11, 2010 at 3:06 PM, Nick Coghlan wrote: > However, the confusion that this setup will engender is that > encountered by Bill: by default, info() messages are silenced rather > than displayed on stdout. > > Notice that even the recommended "basicConfig" approach to resolving > this is

Re: [Python-Dev] Using logging in the stdlib and its unit tests

Glenn Linderman g.nevcal.com> writes: > Yep, agree.  But sadly, for each point, there may be multiple > options (your StreamHandler, but I'd want a FileHandler; your > separation of messages by level, my wanting them combined; etc.) That's partly why logging hasn't made much effort i

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Sat, Dec 11, 2010 at 4:18 PM, Vinay Sajip wrote: >> formatting (when the documentation for the new styles feature goes in >> would probably be an appropriate time to fix this). Similarly, the > > Sorry, what do you mean by "new styles feature"? The switching between percent, str.format and str

Re: [Python-Dev] API for the new sysconfig module

Sorry to get late in the discussion I am travelling. Nick resumes well the motivations behind sysconfig. I'll emphase that this module could hold more functions in the future that could be useful to other python implementations to abstract what is a python installation. E.g. more than paths and v

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Sat, Dec 11, 2010 at 6:00 PM, Nick Coghlan wrote: > What may make more sense than yet another global config mechanism, is > a module level "addHandler" helper function along the following lines: For a more readable version of that example, take a look at the copy I put up over on the Python Co

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Sat, Dec 11, 2010 at 4:25 PM, Glenn Linderman wrote: > On 12/10/2010 9:24 PM, Nick Coghlan wrote: > This could actually make a reasonably good basic for a "task oriented" > subsection of the logging documentation. Something like: > > Yep, agree.  But sadly, for each point, there may be multiple