Re: [Python-Dev] [Python-checkins] cpython (3.2): logging: Added locking in flush() and close() handler methods. Thanks to Fayaz

2012-02-23 Thread Gregory P. Smith
On Thu, Feb 23, 2012 at 5:51 PM, Gregory P. Smith wrote: > On Thu, Feb 23, 2012 at 12:04 PM, vinay.sajip > wrote: >> http://hg.python.org/cpython/rev/b2adcd90e656 >> changeset:   75211:b2adcd90e656 >> branch:      3.2 >> parent:      75200:85d08a1ba74e >> user:        Vinay Sajip >> date:      

Re: [Python-Dev] [Python-checkins] cpython (3.2): logging: Added locking in flush() and close() handler methods. Thanks to Fayaz

2012-02-23 Thread Gregory P. Smith
On Thu, Feb 23, 2012 at 12:04 PM, vinay.sajip wrote: > http://hg.python.org/cpython/rev/b2adcd90e656 > changeset:   75211:b2adcd90e656 > branch:      3.2 > parent:      75200:85d08a1ba74e > user:        Vinay Sajip > date:        Thu Feb 23 19:45:52 2012 + > summary: >  logging: Added locking

Re: [Python-Dev] requirements for moving __import__ over to importlib?

2012-02-23 Thread Brett Cannon
I just tried this and I get a str/bytes issue. I also think your setup3k.py command is missing ``build`` and your build/scripts-3.2 is missing ``/hg``. On Wed, Feb 22, 2012 at 19:26, Éric Araujo wrote: > Hi Brett, > > I think this message went unanswered, so here’s a late reply: > > Le 07/02/201

Re: [Python-Dev] Proposing an alternative to PEP 410

2012-02-23 Thread Guido van Rossum
On Thu, Feb 23, 2012 at 3:47 PM, Larry Hastings wrote: > On 02/23/2012 02:35 PM, Victor Stinner wrote: > > For os.stat(), you should use the UTC timezone, not a naive datetime. > > Why is that more appropriate?  IIUC, timestamps ignore leap seconds and > strictly represent "seconds since the epoch

Re: [Python-Dev] Proposing an alternative to PEP 410

2012-02-23 Thread Larry Hastings
On 02/23/2012 02:35 PM, Victor Stinner wrote: I rejected datetime.datetime because I want to get nanosecond resolution for time and os modules, not only for the os module. If we choose to only patch the os module (*stat() and *utime*() functions), datetime.datetime would be meaningful (e.g. it's

Re: [Python-Dev] Proposing an alternative to PEP 410

2012-02-23 Thread Victor Stinner
I rejected datetime.datetime because I want to get nanosecond resolution for time and os modules, not only for the os module. If we choose to only patch the os module (*stat() and *utime*() functions), datetime.datetime would be meaningful (e.g. it's easier to format datetime for an human, than a E

[Python-Dev] Proposing an alternative to PEP 410

2012-02-23 Thread Larry Hastings
I've been meditating on the whole os.stat mtime representation thing. Here's a possible alternative approach. * Improve datetime.datetime objects so they support nanosecond resolution, in such a way that it's 100% painless to make them even more precise in the future. * Add support to date

Re: [Python-Dev] cpython: Refactor importlib to make it easier to re-implement in C.

2012-02-23 Thread Brett Cannon
On Thu, Feb 23, 2012 at 10:43, Antoine Pitrou wrote: > On Thu, 23 Feb 2012 16:18:19 +0100 > brett.cannon wrote: > > def _sanity_check(name, package, level): > > """Verify arguments are "sane".""" > > +if not hasattr(name, 'rpartition'): > > +raise TypeError("module name must be

Re: [Python-Dev] [Python-checkins] peps: Switch back to named functions, since the Ellipsis version degenerated badly

2012-02-23 Thread Jim Jewett
On Wed, Feb 22, 2012 at 10:22 AM, nick.coghlan wrote: > +    in x = weakref.ref(target, report_destruction) > +    def report_destruction(obj): >         print("{} is being destroyed".format(obj)) > +If the repetition of the name seems especially annoying, then a throwaway > +name like ``f`` can

Re: [Python-Dev] cpython: Refactor importlib to make it easier to re-implement in C.

2012-02-23 Thread Antoine Pitrou
On Thu, 23 Feb 2012 16:18:19 +0100 brett.cannon wrote: > def _sanity_check(name, package, level): > """Verify arguments are "sane".""" > +if not hasattr(name, 'rpartition'): > +raise TypeError("module name must be str, not {}".format(type(name))) Why don't you simply use isinsta

Re: [Python-Dev] Exceptions in LOAD_GLOBAL and LOAD_NAME

2012-02-23 Thread Mark Shannon
Nick Coghlan wrote: On Thu, Feb 23, 2012 at 8:12 PM, Mark Shannon wrote: Should exceptions raised in the equality test be converted to a NameError or just propogated? Our general trend has been towards letting such exceptions escape the operation that caused them rather than implicitly suppre

Re: [Python-Dev] Exceptions in LOAD_GLOBAL and LOAD_NAME

2012-02-23 Thread Nick Coghlan
On Thu, Feb 23, 2012 at 8:12 PM, Mark Shannon wrote: > Should exceptions raised in the equality test be converted to a NameError or > just propogated? Our general trend has been towards letting such exceptions escape the operation that caused them rather than implicitly suppressing them. In this

[Python-Dev] Exceptions in LOAD_GLOBAL and LOAD_NAME

2012-02-23 Thread Mark Shannon
The code below causes different behaviour for LOAD_GLOBAL and LOAD_NAME. Which is correct? Should exceptions raised in the equality test be converted to a NameError or just propogated? Cheers, Mark. - import sys class S(str): pass def eq_except(self, o

Re: [Python-Dev] http://pythonmentors.com/

2012-02-23 Thread Stephen J. Turnbull
Brian Curtin writes: > On Thu, Feb 23, 2012 at 01:15, Stephen J. Turnbull > wrote: > > Brian Curtin writes: > > > >  > If you want to contribute to development, I think you'll know that a > >  > link about development is relevant. > > > > For values of "you" in "experienced programmers",

Re: [Python-Dev] C-API functions for reading/writing tstate->exc_* ?

2012-02-23 Thread Stefan Behnel
"Martin v. Löwis", 19.02.2012 23:24: >> When compiling for PyPy, Cython therefore needs a way to tell PyPy about >> any changes. For the tstate->curexc_* fields, there are the two functions >> PyErr_Fetch() and PyErr_Restore(). Could we have two similar "official" >> functions for the exc_* fields?