Re: [Python-Dev] PEP: New timestamp formats
Am 03.02.2012 um 01:59 schrieb Nick Coghlan : > On Fri, Feb 3, 2012 at 10:21 AM, Victor Stinner > wrote: >> I updated and completed my PEP and published the last draft. It will >> be available at: >> http://www.python.org/dev/peps/pep-0410/ >> ( or read the source: http://hg.python.org/peps/file/tip/pep-0410.txt ) >> >> I tried to list all alternatives. > > [...] > > datetime.datetime > > - as noted earlier in the thread, total_seconds() actually gives you a > decent timestamp value and always returning UTC avoids timezone issues > - real problem with the idea is that not all timestamps can be easily > made absolute (e.g. some APIs may return "time since system started" > or "time since process started") > - the complexity argument used against timedelta also applies Wasn't datetime supposed to be the canonical date/time infrastructure that everybody uses? Why do we need yet another way to express a point in time? And even if we're going with Decimal, at least datetime.datetime should we extended to support the higher resolution (in fact it's the one where this can be done with no or minimal backward compatibility problems). > [other alternatives] Servus, Walter ___ Python-Dev mailing list [email protected] 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: New timestamp formats
> datetime.datetime > > - as noted earlier in the thread, total_seconds() actually gives you a > decent timestamp value and always returning UTC avoids timezone issues os.stat() and time.time() use the local time. Using UTC would be completly wrong. It is possible to get the current timezone for time.time(), but how do you get it for os.stat() (for old timestamps)? If we know exactly how to get the timezone, tzinfo can be filled. If there is no reliable way to get the timezone, it better to not fill the tzinfo field. I don't see datetime without tzinfo as an issue. Being unable to convert a datetime to an epoch timestamp is also not an issue: if you need an epoch timestamp, just use float or Decimal types. > - real problem with the idea is that not all timestamps can be easily > made absolute (e.g. some APIs may return "time since system started" > or "time since process started") There is no such issue: each clock knows the start of the timestamp, or if the start is undefined (e.g. monotonic clocks). We can easily add a field to the interal structure describing a timestamp, and raise an exception of the start is undefined and user asked for a datetime object. -- I don't see any real issue of adding datetime as another accepted type, if Decimal is also accepted. Each type has limitations, and the user can choose the best type for his/her use case. I dropped datetime because I prefer incremental changes (and a simpler PEP is also more easily accepted :-)). We can add datetime later when most developers agree that datetime issues are no more issues :-) > tuple of integers > > - option B doesn't force loss of precision, it's just awkward because > you have to do a complicated calculation to express the full precision > fraction in base 10 > - option C only requires that the denominator be expressible as a > power of *some* base. That's the case for all interfaces we're aware > of (either a power of 2 or a power of 10). If the denominator is coprime with 2 and 10, we cannot express it as a power of 2 or 10 without loss of precision. Example: denominator=3. For option C, we have to use base=denominator and exponent=1 if a denominator is a prime number, or to not having to compute a log at runtime. I don't see any real advantage of using base^exponent. When the denominator is unknown at build time: you have to compute the base and the exponent at runtime, whereas you will have to recompute base^exponent later to do the division. Why not simply storing the denominator directly? Even if you know the denominator at build time but is not a constant number, how do you compute a log2 or log10 using the compiler? The only advantage that I see is for optimization for float if the base is 2 or for Decimal if the base is 10. But it looks like a minor advantage over drawacks. clock() uses CLOCKS_PER_SEC (known at build time, depend on the OS), QueryPerformanceCounter() uses the CPU frequency or another frequency and is only known at runtime. On Windows 7, QueryPerformanceFrequency() is 10^8 on my VM. I don't know if it is a constant. If I remember correctly, it is the CPU frequency on older Windows versions. -- I updated the PEP for your other remarks. Victor ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
Re "raise ValueError from ..." So what does it mean now? Just resetting __cause__ to make __context__ printed? Can you show the down-to-earth snippet of code where such syntax would be useful? Speaking of Zen of Python - I think this stuff contradicts with it more than it follows. On 2012-02-02, at 10:43 PM, Ethan Furman wrote: > Tim Delaney wrote: >> In that case, would the best syntax be: >>raise Exception() from Ellipsis >> or: >>raise Exception() from ... >> ? I kinda like the second - it feels more self-descriptive to me than "from >> Ellipsis" - but there's the counter-argument that it could look like noise, >> and I think would require a grammar change to allow it there. > >raise Exception() from ... > > is... well, I am now gleeful -- especially since I went to my fresh copy of > Python 3.3.0a0 and did this: > > --> ... > Ellipsis > > --> raise ValueError from ... > Traceback (most recent call last): > File "", line 1, in > ValueError > > Have I said lately how much I *love* Python? > > ~Ethan~ > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
Yury Selivanov wrote: Re "raise ValueError from ..." So what does it mean now? Just resetting __cause__ to make __context__ printed? Whatever __cause__ was before (None, or an actual exception), it is now Ellipsis -- so __context__ will be printed and the exception chain will be followed. Can you show the down-to-earth snippet of code where such syntax would be useful? Not sure I'll ever use it this way, but: try: try: raise IndexError() except: raise CustomError() from None except CustomError as e: # nevermind, let's see the whole thing after all raise e from Ellipsis ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] distutils 'depends' management
Hi Matteo, Now setup.py will rebuild all every time, this is because the policy of newer_group in build_extension is to consider 'newer' any missing file. Here you certainly mean “older”. [...] Can someone suggest me the reason of this choice distutils’ notion of dependencies directly comes from make. A missing (not existing) target is perfectly normal: it’s usually a generated file that make needs to create (i.e. compile from source files). In this world, you want to (re-)compile when the target is older than the sources, or when the target is missing. So here your extension module is a target that needs to be created, and when distutils does not find a file with the name you give in depends, it just thinks it’s another thing that will be generated. This model is inherently prone to typos; I’m not sure how we can improve it to let people catch possible typos. Cheers ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
While the example is valid, I doubt that it is in any sense "common" case. OTOH the language will allow strange mess of reserved words with '...', that hurts readability and even gives you an instrument to write tangled and obscured code. Most of the python code is readable in plain english, that's something a lot of people fond of. I can't read 'raise from ...' or 'raise from Ellipsis', and I even had mixed understanding of it after reading the PEP. It's much more than a simple behaviour of "raise from None" (which many of us eagerly want). I'm -1 on adding 'raise from ...'. On 2012-02-03, at 11:52 AM, Ethan Furman wrote: > Yury Selivanov wrote: >> Re "raise ValueError from ..." >> So what does it mean now? Just resetting __cause__ to make __context__ >> printed? > > Whatever __cause__ was before (None, or an actual exception), it is now > Ellipsis -- so __context__ will be printed and the exception chain will be > followed. > >> Can you show the down-to-earth snippet of code where such syntax would be >> useful? > > Not sure I'll ever use it this way, but: > > try: > try: >raise IndexError() > except: >raise CustomError() from None > except CustomError as e: > # nevermind, let's see the whole thing after all > raise e from Ellipsis > > ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-01-27 - 2012-02-03) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3248 (+14) closed 22466 (+29) total 25714 (+43) Open issues with patches: 1392 Issues opened (30) == #13892: distutils handling of windows manifest isn't optimal http://bugs.python.org/issue13892 opened by jackjansen #13893: Make CGIHTTPServer capable of redirects (and status other than http://bugs.python.org/issue13893 opened by Giovanni.Funchal #13896: shelf doesn't work with 'with' http://bugs.python.org/issue13896 opened by gruszczy #13897: Move fields relevant to coroutine/generators out of frame into http://bugs.python.org/issue13897 opened by Mark.Shannon #13898: Ignored exception in test_ssl http://bugs.python.org/issue13898 opened by nadeem.vawda #13899: re pattern r"[\A]" should work like "A" but matches nothing. D http://bugs.python.org/issue13899 opened by sjmachin #13902: Sporadic test_threading failure on FreeBSD 6.4 buildbot http://bugs.python.org/issue13902 opened by nadeem.vawda #13903: New shared-keys dictionary implementation http://bugs.python.org/issue13903 opened by Mark.Shannon #13904: Generator as *args: TypeError replaced http://bugs.python.org/issue13904 opened by july #13905: Built-in Types Comparisons should mention rich comparison meth http://bugs.python.org/issue13905 opened by catalin.iacob #13907: test_pprint relies on set/dictionary repr() ordering http://bugs.python.org/issue13907 opened by Mark.Shannon #13909: Ordering of free variables in dis is dependent on dict orderin http://bugs.python.org/issue13909 opened by Mark.Shannon #13910: test_packaging is dependent on dict ordering. http://bugs.python.org/issue13910 opened by Mark.Shannon #13911: test_trace depends on dict repr() ordering http://bugs.python.org/issue13911 opened by Mark.Shannon #13912: ImportError using __import__ and relative level 1 http://bugs.python.org/issue13912 opened by jason.coombs #13913: utf-8 or utf8 or utf-8 (codec display name inconsistency) http://bugs.python.org/issue13913 opened by kennyluck #13915: Update Tutorial 6.1.3 for PEP 3145 http://bugs.python.org/issue13915 opened by terry.reedy #13916: disallow the "surrogatepass" handler for non utf-* encodings http://bugs.python.org/issue13916 opened by kennyluck #13918: locale.atof documentation is missing func argument http://bugs.python.org/issue13918 opened by ced #13921: sqlite3: OptimizedUnicode doesn't work in Py3k http://bugs.python.org/issue13921 opened by petri.lehtinen #13922: argparse handling multiple "--" in args improperly http://bugs.python.org/issue13922 opened by Warren.Turkal #13923: new formatter for argparse http://bugs.python.org/issue13923 opened by Warren.Turkal #13924: Mercurial robots.txt should let robots crawl landing pages. http://bugs.python.org/issue13924 opened by Ivaylo.Popov #13926: pydoc - stall when requesting a list of available modules in t http://bugs.python.org/issue13926 opened by Jeroen #13927: Extra spaces in the output of time.ctime http://bugs.python.org/issue13927 opened by Roger.Caldwell #13928: bug in asyncore.dispatcher_with_send http://bugs.python.org/issue13928 opened by adamhj #13929: fnmatch to support escape characters http://bugs.python.org/issue13929 opened by fruch #13930: lib2to3 ability to output files into a different directory and http://bugs.python.org/issue13930 opened by gregory.p.smith #13932: If some test module fails to import another module unittest re http://bugs.python.org/issue13932 opened by sbarthelemy #13933: IDLE:not able to complete the hashlib module http://bugs.python.org/issue13933 opened by ramchandra.apte Most recent 15 issues with no replies (15) == #13933: IDLE:not able to complete the hashlib module http://bugs.python.org/issue13933 #13932: If some test module fails to import another module unittest re http://bugs.python.org/issue13932 #13930: lib2to3 ability to output files into a different directory and http://bugs.python.org/issue13930 #13929: fnmatch to support escape characters http://bugs.python.org/issue13929 #13923: new formatter for argparse http://bugs.python.org/issue13923 #13922: argparse handling multiple "--" in args improperly http://bugs.python.org/issue13922 #13916: disallow the "surrogatepass" handler for non utf-* encodings http://bugs.python.org/issue13916 #13915: Update Tutorial 6.1.3 for PEP 3145 http://bugs.python.org/issue13915 #13911: test_trace depends on dict repr() ordering http://bugs.python.org/issue13911 #13910: test_packaging is dependent on dict ordering. http://bugs.python.org/issue13910 #13909: Ordering of free variables in dis is dependent on dict orderin http://bugs.python.org/issue13909 #13907: test_pprint relies on set/dictionary repr() ordering http://
Re: [Python-Dev] PEP 409 update [was: PEP 409 - final?]
On Feb 03, 2012, at 08:52 AM, Ethan Furman wrote: >Not sure I'll ever use it this way, but: > >try: > try: > raise IndexError() > except: > raise CustomError() from None >except CustomError as e: > # nevermind, let's see the whole thing after all > raise e from Ellipsis In that context, I have to say that the last line, even if it were written raise e from ... is certainly cute, but not very informative. Triple-dots will be confusing and difficult to read in documentation and code, and Ellipsis has no logical connection to the purpose of this PEP. So while I'm +1 on everything else in the PEP, I'm -1 on this particular decision. One of the alternatives states: Create a special exception class, __NoException__. Rejected as possibly confusing, possibly being mistakenly raised by users, and not being a truly unique value as None, True, and False are. I think this should be revisited. First, `__NoException__` doesn't need to be an exception class. Ellipsis isn't so this doesn't need to be either. I have no problem adding a new non-exception derived singleton to mark this. And while __NoException__ may be a little confusing, something like __NoCause__ reads great and can't be mistaken for a raiseable exception. So your example would then be: try: try: raise IndexError() except: raise CustomError() from None except CustomError as e: # nevermind, let's see the whole thing after all raise e from __NoCause__ Cheers, -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Dev In a Box: Pumped for a better UX (with video)
Hi, If you don't know, Dev In a Box is "everything you need to contribute to Python in under 700 MB". I've patched it up to the latest standards of colorless console user interfaces and uploaded a video of the process for you to enjoy. http://www.youtube.com/watch?v=jbJcI9MnO_c This tool can be greatly improved to provide entrypoint for other healthy activities. Like improving docs by editing, comparing, building and sending patches for review. Specialized menus can greatly help with automating common tasks, which are not limited by sources fetching. https://bitbucket.org/techtonik/devinabox -- anatoly t. ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
I got it, and I think it's fine to use explicit __cause__ reset, using Ellipsis, or even some __NoException__ special object if we decide to introduce one. I'm against allowing 'from ...' syntax. On 2012-02-03, at 12:29 PM, Ethan Furman wrote: > Yury Selivanov wrote: >> While the example is valid, I doubt that it is in any sense "common" case. > > No it is a corner case. Another way to spell it is: > > try: >try: >raise IndexError() >except: >raise CustomError() from None > except CustomError as e: ># nevermind, let's see the whole thing after all >e.__cause__ = Ellipsis >raise e > > Ethan ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
Yury Selivanov wrote: While the example is valid, I doubt that it is in any sense "common" case. No it is a corner case. Another way to spell it is: try: try: raise IndexError() except: raise CustomError() from None except CustomError as e: # nevermind, let's see the whole thing after all e.__cause__ = Ellipsis raise e Ethan ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
Funny thing, it seems like you don't get it in the same way I did not in the first place. His example is more like: try: try: raise IndexError() except: raise CustomError() from __NoContext__ except CustomError as e: # nevermind, let's see the whole thing after all raise e from __OupsLooksLikeINeedContextAfterAll__ On 2012-02-03, at 12:29 PM, Barry Warsaw wrote: > On Feb 03, 2012, at 08:52 AM, Ethan Furman wrote: > >> Not sure I'll ever use it this way, but: >> >> try: >> try: >>raise IndexError() >> except: >>raise CustomError() from None >> except CustomError as e: >> # nevermind, let's see the whole thing after all >> raise e from Ellipsis > > In that context, I have to say that the last line, even if it were written > >raise e from ... > > is certainly cute, but not very informative. Triple-dots will be confusing > and difficult to read in documentation and code, and Ellipsis has no logical > connection to the purpose of this PEP. So while I'm +1 on everything else in > the PEP, I'm -1 on this particular decision. > > One of the alternatives states: > >Create a special exception class, __NoException__. > >Rejected as possibly confusing, possibly being mistakenly raised by users, >and not being a truly unique value as None, True, and False are. > > I think this should be revisited. First, `__NoException__` doesn't need to be > an exception class. Ellipsis isn't so this doesn't need to be either. I have > no problem adding a new non-exception derived singleton to mark this. And > while __NoException__ may be a little confusing, something like __NoCause__ > reads great and can't be mistaken for a raiseable exception. > > So your example would then be: > > try: > try: > raise IndexError() > except: > raise CustomError() from None > except CustomError as e: > # nevermind, let's see the whole thing after all > raise e from __NoCause__ > > Cheers, > -Barry > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
;) I completely understand what Ellipsis object and its short syntax (...) is. And for me 'raise from Ellipsis' or 'raise from ...', or even using the Ellipsis object internally instead of special __NoContext__ object is godawful. Why do we want to use some completely unrelated singleton in the exception contexts? Is the policy of "think before adding a new builtin object" really worth it in this concrete case? On 2012-02-03, at 1:01 PM, Ethan Furman wrote: > Yury Selivanov wrote: >> I got it, and I think it's fine to use explicit __cause__ reset, >> using Ellipsis, or even some __NoException__ special object if we decide to >> introduce one. >> I'm against allowing 'from ...' syntax. > > Well, ... /is/ Ellipsis -- no way to tell them apart by them time this part > of the code sees it. > > ~Ethan~ ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
On Fri, Feb 3, 2012 at 9:29 AM, Barry Warsaw wrote: > On Feb 03, 2012, at 08:52 AM, Ethan Furman wrote: > >>Not sure I'll ever use it this way, but: >> >>try: >> try: >> raise IndexError() >> except: >> raise CustomError() from None >>except CustomError as e: >> # nevermind, let's see the whole thing after all >> raise e from Ellipsis > > In that context, I have to say that the last line, even if it were written > > raise e from ... > > is certainly cute, but not very informative. Please. Let's stop this. There is no known use case to ever write that. We're just not putting specific measures to prevent it. Writing >>> a = ... Is likewise cute but not very informative. But it is valid syntax. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
Barry Warsaw wrote: raise e from ... is certainly cute, but not very informative. Triple-dots will be confusing and difficult to read in documentation and code, and Ellipsis has no logical connection to the purpose of this PEP. So while I'm +1 on everything else in the PEP, I'm -1 on this particular decision. One of the alternatives states: Create a special exception class, __NoException__. Rejected as possibly confusing, possibly being mistakenly raised by users, and not being a truly unique value as None, True, and False are. I think this should be revisited. First, `__NoException__` doesn't need to be an exception class. Ellipsis isn't so this doesn't need to be either. I have no problem adding a new non-exception derived singleton to mark this. And while __NoException__ may be a little confusing, something like __NoCause__ reads great and can't be mistaken for a raiseable exception. The problem I have with names like __NoException__, __NoCause__, __NoWhatever__ is that is sounds a lot like None -- in otherwords, like there won't be any chaining. So your example would then be: try: try: raise IndexError() except: raise CustomError() from None except CustomError as e: # nevermind, let's see the whole thing after all raise e from __NoCause__ If we do switch from Ellipsis to something else I think a name like __Chain__ would be more appropriate. Or __ExcChain__. raise e from __ExcChain__ Less cute, but probably less confusing. ~Ethan~ ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
On 2012-02-03, at 1:20 PM, Guido van Rossum wrote: > Please. Let's stop this. There is no known use case to ever write > that. We're just not putting specific measures to prevent it. Writing > a = ... > > Is likewise cute but not very informative. But it is valid syntax. Well, right now you'll get TypeError if you want to raise an exception from something that is not an exception. 'raise from None' will loosen the check allowing None values, in the 'raise from' statement, but that should be it. To achieve the same effect as 'raise from ...' just do 'e.__cause__ = ...'. On the question of using Ellipsis instead of some new singleton like __NoContext__: how's Ellipsis semantically related to exceptions after all? - Yury ___ Python-Dev mailing list [email protected] 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: New timestamp formats
On Fri, Feb 3, 2012 at 3:57 AM, Victor Stinner wrote: >> datetime.datetime >> >> - as noted earlier in the thread, total_seconds() actually gives you a >> decent timestamp value and always returning UTC avoids timezone issues > > os.stat() and time.time() use the local time. The documentation disagrees with you. http://docs.python.org/dev/library/time.html#time.time says "Return the time as a floating point number expressed in seconds since the epoch, in UTC." os.stat is documented less clearly, but it's implemented by forwarding to the system stat(), and that's defined at http://www.opengroup.org/sud/sud1/xsh/sysstat.h.htm#sysstat.h-file-desc-stru to return times since the Epoch. http://pubs.opengroup.org/onlinepubs/95399/functions/localtime.html says "January 1, 1970 0:00 UTC (the Epoch)" > I don't see datetime without tzinfo as an issue. > > Being unable to convert a datetime to an epoch timestamp is also not > an issue: if you need an epoch timestamp, just use float or Decimal > types. Your PEP still says, 'there is no easy way to convert it into "seconds since the epoch"'. If you don't actually think it's an issue (which it's not, because there is an easy way to convert it), then take that out of the PEP. Jeffrey ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
Yury Selivanov wrote: I got it, and I think it's fine to use explicit __cause__ reset, using Ellipsis, or even some __NoException__ special object if we decide to introduce one. I'm against allowing 'from ...' syntax. Well, ... /is/ Ellipsis -- no way to tell them apart by them time this part of the code sees it. ~Ethan~ ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
Yury Selivanov wrote: On 2012-02-03, at 1:20 PM, Guido van Rossum wrote: Please. Let's stop this. There is no known use case to ever write that. We're just not putting specific measures to prevent it. Writing a = ... Is likewise cute but not very informative. But it is valid syntax. Well, right now you'll get TypeError if you want to raise an exception from something that is not an exception. 'raise from None' will loosen the check allowing None values, in the 'raise from' statement, but that should be it. To achieve the same effect as 'raise from ...' just do 'e.__cause__ = ...'. On the question of using Ellipsis instead of some new singleton like __NoContext__: how's Ellipsis semantically related to exceptions after all? Merrian Webster says: - el·lip·sis noun \i-ˈlip-səs, e-\ plural el·lip·ses\-ˌsēz\ Definition of ELLIPSIS 1 a : the omission of one or more words that are obviously understood but that must be supplied to make a construction grammatically complete - Relation to exceptions: Two places to look: __context__ and __cause__ Priority? __cause__ When do we check __context__? if __cause__ is omitted (or Ellipsis) ~Ethan~ ___ Python-Dev mailing list [email protected] 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 408 -- Standard library __preview__ package
On 27/01/2012 15:09, Antoine Pitrou wrote: On Fri, 27 Jan 2012 15:21:33 +0200 Eli Bendersky wrote: Following an earlier discussion on python-ideas [1], we would like to propose the following PEP for review. Discussion is welcome. The PEP can also be viewed in HTML form at http://www.python.org/dev/peps/pep-0408/ A big +1 from me. Actually a pretty big -1 from me. I'd prefer to see the standard library getting smaller, not bigger, and packages being upgradeable independently from the Python version as a result. Every time I see things like the following I cry a little inside: try: try: from py2stdliblocation import FooBar as Foo except ImportError: from py3stdliblocation import foo as Foo except ImportError: from pypilocation import Foo Now we're talking about having to add __preview__ into that mix too? :'( Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Python-Dev mailing list [email protected] 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: New timestamp formats
On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan wrote: > datetime.datetime > > - real problem with the idea is that not all timestamps can be easily > made absolute (e.g. some APIs may return "time since system started" > or "time since process started") I think this is an argument for returning the appropriate one of datetime or timedelta from all of these functions: users need to keep track of whether they've got an absolute time, or an offset from an unspecified starting point, and that's a type-like distinction. > - the complexity argument used against timedelta also applies A plain number of seconds is superficially simpler, but it forces more complexity onto the user, who has to track what that number represents. datetime and timedelta are even available from a C module, which I had expected to be a blocking issue. The biggest problem I see with using datetime and timedelta for everything is that switching to them is very backwards-incompatible. Jeffrey ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
That's a bit far-fetched. Using same level argumentation we can utilize even `0`. `raise e from 0` (or `-1`), and use `0` object instead of Ellipsis. Anyways, if the PEP is not yet fully approved, I'm minus one on allowing of using anything other than Exception instance or None in 'raise from' statement. On 2012-02-03, at 2:03 PM, Ethan Furman wrote: > Yury Selivanov wrote: >> On 2012-02-03, at 1:20 PM, Guido van Rossum wrote: >>> Please. Let's stop this. There is no known use case to ever write >>> that. We're just not putting specific measures to prevent it. Writing >>> >> a = ... >>> Is likewise cute but not very informative. But it is valid syntax. >> Well, right now you'll get TypeError if you want to raise an exception >> from something that is not an exception. 'raise from None' will >> loosen the check allowing None values, in the 'raise from' statement, >> but that should be it. >> To achieve the same effect as 'raise from ...' just do 'e.__cause__ = ...'. >> On the question of using Ellipsis instead of some new singleton like >> __NoContext__: how's Ellipsis semantically related to exceptions after all? > > > Merrian Webster says: > - > el·lip·sis > noun \i-ˈlip-səs, e-\ > plural el·lip·ses\-ˌsēz\ > Definition of ELLIPSIS > 1 > a : the omission of one or more words that are obviously understood but that > must be supplied to make a construction grammatically complete > - > > Relation to exceptions: > Two places to look: __context__ and __cause__ > Priority? __cause__ > When do we check __context__? if __cause__ is omitted (or Ellipsis) > > ~Ethan~ ___ Python-Dev mailing list [email protected] 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: New timestamp formats
On Fri, 3 Feb 2012 11:04:14 -0800 Jeffrey Yasskin wrote: > On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan wrote: > > datetime.datetime > > > > - real problem with the idea is that not all timestamps can be easily > > made absolute (e.g. some APIs may return "time since system started" > > or "time since process started") > > I think this is an argument for returning the appropriate one of > datetime or timedelta from all of these functions: users need to keep > track of whether they've got an absolute time, or an offset from an > unspecified starting point, and that's a type-like distinction. Keep in mind timedelta has a microsecond resolution. The use cases meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(), for example). > A plain number of seconds is superficially simpler, but it forces more > complexity onto the user, who has to track what that number > represents. If all you are doing is comparing timestamps (which I guess is most of what people do with e.g. st_mtime), a number is fine. If you want the current time and date in a high-level form, you can already use datetime.now() or datetime.utcnow() (which "only" has microsecond resolution as well :-)). We don't need another way to spell it. Regards Antoine. ___ Python-Dev mailing list [email protected] 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: New timestamp formats
On Fri, Feb 3, 2012 at 11:17 AM, Antoine Pitrou wrote: > On Fri, 3 Feb 2012 11:04:14 -0800 > Jeffrey Yasskin wrote: >> On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan wrote: >> > datetime.datetime >> > >> > - real problem with the idea is that not all timestamps can be easily >> > made absolute (e.g. some APIs may return "time since system started" >> > or "time since process started") >> >> I think this is an argument for returning the appropriate one of >> datetime or timedelta from all of these functions: users need to keep >> track of whether they've got an absolute time, or an offset from an >> unspecified starting point, and that's a type-like distinction. > > Keep in mind timedelta has a microsecond resolution. The use cases > meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(), > for example). Yes, I think someone had noted that datetime and timedelta would need to be extended to support nanosecond resolution. >> A plain number of seconds is superficially simpler, but it forces more >> complexity onto the user, who has to track what that number >> represents. > > If all you are doing is comparing timestamps (which I guess is most of > what people do with e.g. st_mtime), a number is fine. Sure. I don't think the argument for datetime is totally convincing, just that it's stronger than the PEP currently presents. > If you want the current time and date in a high-level form, you can > already use datetime.now() or datetime.utcnow() (which "only" has > microsecond resolution as well :-)). We don't need another way to spell > it. Whoops, yes, there's no need to extend time() to return a datetime. ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
On Fri, Feb 3, 2012 at 11:18 AM, Yury Selivanov wrote: > That's a bit far-fetched. Using same level argumentation we can utilize > even `0`. `raise e from 0` (or `-1`), and use `0` object instead of > Ellipsis. > > Anyways, if the PEP is not yet fully approved, I'm minus one on allowing > of using anything other than Exception instance or None in 'raise from' > statement. I read your objection and disagree. The PEP *is* fully approved. > On 2012-02-03, at 2:03 PM, Ethan Furman wrote: > >> Yury Selivanov wrote: >>> On 2012-02-03, at 1:20 PM, Guido van Rossum wrote: Please. Let's stop this. There is no known use case to ever write that. We're just not putting specific measures to prevent it. Writing >>> a = ... Is likewise cute but not very informative. But it is valid syntax. >>> Well, right now you'll get TypeError if you want to raise an exception >>> from something that is not an exception. 'raise from None' will >>> loosen the check allowing None values, in the 'raise from' statement, >>> but that should be it. >>> To achieve the same effect as 'raise from ...' just do 'e.__cause__ = ...'. >>> On the question of using Ellipsis instead of some new singleton like >>> __NoContext__: how's Ellipsis semantically related to exceptions after all? >> >> >> Merrian Webster says: >> - >> el·lip·sis >> noun \i-ˈlip-səs, e-\ >> plural el·lip·ses\-ˌsēz\ >> Definition of ELLIPSIS >> 1 >> a : the omission of one or more words that are obviously understood but that >> must be supplied to make a construction grammatically complete >> - >> >> Relation to exceptions: >> Two places to look: __context__ and __cause__ >> Priority? __cause__ >> When do we check __context__? if __cause__ is omitted (or Ellipsis) >> >> ~Ethan~ > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
On 3 February 2012 19:18, Yury Selivanov wrote: > That's a bit far-fetched. Using same level argumentation we can utilize > even `0`. `raise e from 0` (or `-1`), and use `0` object instead of > Ellipsis. > > Anyways, if the PEP is not yet fully approved, I'm minus one on allowing > of using anything other than Exception instance or None in 'raise from' > statement. I may have missed something here, but as far as I am aware, the PEP is fundamentally only about allowing raise...from None to suppress chaining. There is an extremely obscure case where certain (generally library, not end user) code might want to reinstate chaining. For that very obscure case, the PEP suggests setting __cause__ to a sentinel value, and Ellipsis is used rather than inventing a new singleton for such a rare case. Purely by accident, the form "raise X from ..." will do the same as explicitly setting __cause__, and it's not worth the effort of testing for and rejecting this case. This issue is so not worth arguing about, it's silly. Paul. ___ Python-Dev mailing list [email protected] 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 409 - Accepted!
Good news! PEP 409 has been accepted! Not so good news: There is no one assigned to Issue 6210 to review the patches... any volunteers? http://bugs.python.org/issue6210 ~Ethan~ ___ Python-Dev mailing list [email protected] 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: New timestamp formats
Why is the PEP promoting the float type being used as the default on the new-in-3.3 APIs that were added explicitly to provide nanosecond level resolution that cannot be represented by a float? The *new* APIs should default to the high precision return value (be that datetime/timedelta or decimal). -gps On Fri, Feb 3, 2012 at 11:32 AM, Jeffrey Yasskin wrote: > On Fri, Feb 3, 2012 at 11:17 AM, Antoine Pitrou > wrote: > > On Fri, 3 Feb 2012 11:04:14 -0800 > > Jeffrey Yasskin wrote: > >> On Thu, Feb 2, 2012 at 4:59 PM, Nick Coghlan > wrote: > >> > datetime.datetime > >> > > >> > - real problem with the idea is that not all timestamps can be easily > >> > made absolute (e.g. some APIs may return "time since system started" > >> > or "time since process started") > >> > >> I think this is an argument for returning the appropriate one of > >> datetime or timedelta from all of these functions: users need to keep > >> track of whether they've got an absolute time, or an offset from an > >> unspecified starting point, and that's a type-like distinction. > > > > Keep in mind timedelta has a microsecond resolution. The use cases > > meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(), > > for example). > > Yes, I think someone had noted that datetime and timedelta would need > to be extended to support nanosecond resolution. > > >> A plain number of seconds is superficially simpler, but it forces more > >> complexity onto the user, who has to track what that number > >> represents. > > > > If all you are doing is comparing timestamps (which I guess is most of > > what people do with e.g. st_mtime), a number is fine. > > Sure. I don't think the argument for datetime is totally convincing, > just that it's stronger than the PEP currently presents. > > > If you want the current time and date in a high-level form, you can > > already use datetime.now() or datetime.utcnow() (which "only" has > > microsecond resolution as well :-)). We don't need another way to spell > > it. > > Whoops, yes, there's no need to extend time() to return a datetime. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
On Feb 03, 2012, at 10:20 AM, Guido van Rossum wrote: a = ... > >Is likewise cute but not very informative. But it is valid syntax. FWIW (probably not much at this point), it's not the syntax I have a problem with, but the semantics as described in the PEP of setting __cause__ to Ellipsis to mean use __context__. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] 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 408 -- Standard library __preview__ package
Chris Withers wrote: Every time I see things like the following I cry a little inside: try: try: from py2stdliblocation import FooBar as Foo except ImportError: from py3stdliblocation import foo as Foo except ImportError: from pypilocation import Foo The syntax is inelegant, but the concept is straightforward and simple and not worth tears. "I need a thing called Foo, which can be found here, or here, or here. Use the first one found." In principle this is not terribly different from the idea of a search PATH when looking for an executable, except the executable can be found under different names as well as different locations. Now we're talking about having to add __preview__ into that mix too? As I understand it, Guido nixed that idea. (Or did I imagine that?) Preview modules will be just added to the std lib as normal, and you have to read the docs to find out they're preview. -- Steven ___ Python-Dev mailing list [email protected] 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: New timestamp formats
> consider changing the default on any of these that return a time > value. these for example: > * time.clock_gettime() > * time.wallclock() (reuse time.clock_gettime(time.CLOCK_MONOTONIC)) Ah. Nanosecond resolution is overkill is common cases, float is enough and is faster. I prefer to use the same type (float) by default for all functions creating timestamps. Victor ___ Python-Dev mailing list [email protected] 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 409 - Accepted!
2012/2/3 Ethan Furman : > Good news! PEP 409 has been accepted! It may be too late for this, but I find the whole Ellipsis business most unpleasant. Why not just have a extra attribute on exception objects like __chain__ = False/True? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
On 2/3/2012 9:53 AM, Yury Selivanov wrote: Re "raise ValueError from ..." The use cases for Ellipsis/... are 99.99% internal. The typical Python programmer will never see or have cause to worry about such a thing. The problem is that we really want an exception attribute that is missing in certain cases. But C does not allow missing struct members (the corresponding block of memory *will* have some bit pattern!). So unset attributes requires a dict instead of slots (I am presuming each builting exception class uses slots now) and the use of the C equivalent of hasattr (or try: except:) and delattr. So instead the proposal is to use a marker value that effectively means 'unset' or 'unspecified'. But what? None cannot be used because it is being used as a set value. Ethan initially proposed 'False', but then realizaed that 'True' fits as well, so neither fit. I proposed a new internal exception class primarily to get us thinking about alternatives to True/False. Ellipsis, properly understoo, comes close to meaning 'unspecified'. My memory is that that it how it is used in NumPy slicings. The manual gives no meaning for Ellipsis, only saying that it is used in slicings. The linked slicings section does not mention it. Ethan: I think the PEP should say more about ... being a grammatical placeholder in English, much like 'pass' is in Python. Otherwise, we will see periodic posts objecting to it in python-list. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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 409 - Accepted!
On Fri, 3 Feb 2012 19:19:21 -0500 Benjamin Peterson wrote: > 2012/2/3 Ethan Furman : > > Good news! PEP 409 has been accepted! > > It may be too late for this, but I find the whole Ellipsis business > most unpleasant. Why not just have a extra attribute on exception > objects like __chain__ = False/True? Incredibly agreed with Benjamin. Regards Antoine. ___ Python-Dev mailing list [email protected] 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: New timestamp formats
> I don't see any real issue of adding datetime as another accepted
> type, if Decimal is also accepted. Each type has limitations, and the
> user can choose the best type for his/her use case.
>
> I dropped datetime because I prefer incremental changes (and a simpler
> PEP is also more easily accepted :-)). We can add datetime later when
> most developers agree that datetime issues are no more issues :-)
About incremental changes, I wrote a patch (timestamp_datetime.patch)
to support the datetime.datetime type using my API:
http://bugs.python.org/issue13882#msg152571
Example:
$ ./python
>>> import datetime, os, time
>>> open("x", "wb").close(); print(datetime.datetime.now())
2012-02-04 01:17:27.593834
>>> print(os.stat("x", timestamp=datetime.datetime).st_ctime)
2012-02-04 00:17:27.592284+00:00
>>> print(time.time(timestamp=datetime.datetime))
2012-02-04 00:18:21.329012+00:00
>>> time.clock(timestamp=datetime.datetime)
ValueError: clock has an unspecified starting point
>>> print(time.clock_gettime(time.CLOCK_REALTIME, timestamp=datetime.datetime))
2012-02-04 00:21:37.815663+00:00
>>> print(time.clock_gettime(time.CLOCK_MONOTONIC, timestamp=datetime.datetime))
ValueError: clock has an unspecified starting point
I still don't know if using UTC is correct.
Victor
___
Python-Dev mailing list
[email protected]
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: New timestamp formats
> Keep in mind timedelta has a microsecond resolution. The use cases > meant for the PEP imply nanosecond resolution (POSIX' clock_gettime(), > for example). datetime.datetime and datetime.timedelta can be patched to support nanosecond. >> A plain number of seconds is superficially simpler, but it forces more >> complexity onto the user, who has to track what that number >> represents. > > If all you are doing is comparing timestamps (which I guess is most of > what people do with e.g. st_mtime), a number is fine. > > If you want the current time and date in a high-level form, you can > already use datetime.now() or datetime.utcnow() (which "only" has > microsecond resolution as well :-)). We don't need another way to spell > it. datetime.datetime is interesting with os.stat() if you want to display the creation, modification or last access timestamp to the user. With datetime.datime, you don't have to read the documentation to get the reference date (Epoch for os.stat(), 1970.1.1) or the timezone (UTC for os.stat()?). So datetime.datime contains two more information (start date and timezone) than int, float or Decimal cannot store. Supporting datetime.datetime just for os.start(), whereas time.clock(), time.wallclock(), time.clock_gettime() and time.clock_getres() fail for this format, is maybe a bad idea. There is an exception: time.clock_gettime(time.CLOCK_REALTIME, timestamp=datetime.datetime) would be accept and you can get a timestamp with a nanosecond resolution... But datetime.datetime doesn't support nanosecond currently :-) The best reason to reject datetime.datetime is that it would only "work" with some functions, whereas it would fail (with a ValueError) in most cases. Victor ___ Python-Dev mailing list [email protected] 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 409 update [was: PEP 409 - final?]
On 2012-02-03, at 7:23 PM, Terry Reedy wrote: > On 2/3/2012 9:53 AM, Yury Selivanov wrote: >> Re "raise ValueError from ..." > > The use cases for Ellipsis/... are 99.99% internal. The typical Python > programmer will never see or have cause to worry about such a thing. I get your points. But I don't like this argument about some spherical "typical Python programmer". Any programmer at some point may go and investigate some bug in stdlib or any other library and see this "raise Exc() from ...", or "e = Exc(); e.__cause__ = ...; raise e" nonsense. BTW, will "raise .. from .." statement allow raising only from exceptions, None, and Ellipsis exclusively, or any python object can be used? Right now it would throw a TypeError if you try to raise from None or Ellipsis. And as Benjamin said in the later latter of his -- simple __chain__ attribute will be much more understandable, easy to document and explain. That can be used as simple as writing "raise Exception().no_chaining()" or something like that. - Yury ___ Python-Dev mailing list [email protected] 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 409 - Accepted!
On Fri, Feb 3, 2012 at 22:14, Ethan Furman wrote: > Good news! PEP 409 has been accepted! > > Not so good news: There is no one assigned to Issue 6210 to review the > patches... any volunteers? > > http://bugs.python.org/issue6210 > Hi Ethan, I've just looked at PEP 409 online (http://www.python.org/dev/peps/pep-0409/) and I'm not sure where it details the final syntax that was chosen. The "Proposal" section says: " I proprose going with the second option: raise NewException from None " This makes no mention of ellipsis / Could you please clarify the PEP to make it detail the new syntax and its proposed semantics more precisely? Thanks in advance, Eli ___ Python-Dev mailing list [email protected] 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 409 - Accepted!
There is no new syntax! It's going to remain "raise from ". The types of the expressions are constrained by the runtime, not by the syntax. If either type is unacceptable, a TypeError (with the default context :-) will be raised. None of that is new. Really, there is no new syntax to clarify, only new allowable types for , and a new meaning assigned to those types. On Fri, Feb 3, 2012 at 7:28 PM, Eli Bendersky wrote: > On Fri, Feb 3, 2012 at 22:14, Ethan Furman wrote: >> Good news! PEP 409 has been accepted! >> >> Not so good news: There is no one assigned to Issue 6210 to review the >> patches... any volunteers? >> >> http://bugs.python.org/issue6210 >> > > Hi Ethan, > > I've just looked at PEP 409 online > (http://www.python.org/dev/peps/pep-0409/) and I'm not sure where it > details the final syntax that was chosen. > > The "Proposal" section says: > > " > I proprose going with the second option: > > raise NewException from None > " > > This makes no mention of ellipsis / > > Could you please clarify the PEP to make it detail the new syntax and > its proposed semantics more precisely? > > Thanks in advance, > Eli > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] 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 408 -- Standard library __preview__ package
On 2/3/2012 6:18 PM, Steven D'Aprano wrote: Now we're talking about having to add __preview__ into that mix too? As I understand it, Guido nixed that idea. (Or did I imagine that?) No, you are right, discussion should cease. It is already marked 'rejected' and listed under Abandoned, Withdrawn, and Rejected PEPs. Preview modules will be just added to the std lib as normal, and you have to read the docs to find out they're preview. What's New should say so too. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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 408 -- Standard library __preview__ package
Woohoo! :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OS X build break
On Sat, Dec 31, 2011 at 5:56 PM, Guido van Rossum wrote: > PS. I would propose a specific fix but I can't seem to build a working > CPython from the trunk on my laptop (OS X 10.6, Xcode 4.1). I get this error > late in the build: > > ./python.exe -SE -m sysconfig --generate-posix-vars > Fatal Python error: Py_Initialize: can't initialize sys standard streams > Traceback (most recent call last): > File "/Users/guido/cpython/Lib/io.py", line 60, in > make: *** [Lib/_sysconfigdata.py] Abort trap I am having this problem now too. I am running OS X 10.7.2. 3.2 still builds for me, but I can't build default. Did you ever get past it? Anyone else seeing this? -- # Meador ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
