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 Pyt
Woohoo! :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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, Withdr
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
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.pyth
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
> 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 i
> 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 acce
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__ = Fa
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
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
__
> 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
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, bu
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
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)
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
Python-Dev@python.org
http://mail.python.o
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 anyt
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 usi
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.
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
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'
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
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
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, r
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
pa
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 dis
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
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
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 se
;)
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
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 __
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 t
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 val
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
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 co
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 wit
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, th
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
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.
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-0
> 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
t
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/
42 matches
Mail list logo
