On Thu, Jan 9, 2014 at 11:21 AM, MRAB wrote:
> On the other hand:
>
> "I need a new battery."
>
> "What kind of battery?"
>
> "I don't care!"
Or, bringing it back to Python: How do you write a set out to a file?
foo = {1, 2, 4, 8, 16, 32}
open("foo.txt","w").write(foo) # Uh... nope!
On Thu, Jan 9, 2014 at 5:50 PM, Lennart Regebro wrote:
> To be honest, you can define text as "A stream of bytes that are split
> up in lines separated by a linefeed", and do some basic text
> processing like that. Just very *basic*, but still. Replacing
> characters. Extracting certain lines etc.
On Fri, Jan 10, 2014 at 11:53 AM, anatoly techtonik wrote:
> 2. introduce autodetect mode to open functions
> 1. read and transform on the fly, maintaining a buffer that
> stores original bytes
> and their mapping to letters. The mapping is updated as bytes
> frequency
>
On Fri, Jan 10, 2014 at 1:39 PM, Steven D'Aprano wrote:
> On Fri, Jan 10, 2014 at 12:22:02PM +1100, Chris Angelico wrote:
>> On Fri, Jan 10, 2014 at 11:53 AM, anatoly techtonik
>> wrote:
>> > 2. introduce autodetect mode to open functions
>> >
On Mon, Jan 13, 2014 at 4:57 AM, Juraj Sukop wrote:
> On Sun, Jan 12, 2014 at 6:22 PM, Steven D'Aprano
> wrote:
>> First, "utf16_string" confuses me. What is it? If it is a Unicode
>> string, i.e.:
>
> It is a Unicode string which happens to contain code points outside U+00FF
> (as with the TTF e
On Tue, Jan 14, 2014 at 10:48 AM, Jim J. Jewett wrote:
>> The barrier for entry to the standard library is higher than mere
>> usefulness.
>
> Agreed. But "most programs will need it, and people will either
> include (the same) 3rd-party library themselves, or write their
> own workaround, or hav
And now for something completely different.
My root buildbot is finally now able to telnet out and get "Connection
refused" errors. (For the curious, the VirtualBox "NAT" mode doesn't
work properly, but the new "NAT Network" mode does. Why? I have no
idea. But if anyone else is having the same pro
On Tue, Jan 14, 2014 at 2:14 PM, Zachary Ware
wrote:
> On Mon, Jan 13, 2014 at 6:48 PM, Chris Angelico wrote:
>> And secondly, how can I run the tests manually? I can't find a binary
>> inside the buildarea tree. Does it get deleted afterward?
>
> Yes, that's t
On Tue, Jan 14, 2014 at 2:03 PM, Terry Reedy wrote:
> On 1/13/2014 7:48 PM, Chris Angelico wrote:
>>
>> ValueError: max() arg is an empty sequence
>
>
> try:
>
> g = max(self.saved_groups) + 1
> except ValueError:
> g = 1
>
>
> Unless someone
On Tue, Jan 14, 2014 at 2:16 PM, MRAB wrote:
> Alternatively:
>
> g = max(self.saved_groups, [1])
>
> or even:
>
> g = max(self.saved_groups or [1])
Patch created and tracker issue opened. I've used something similar to
MRAB's idea as it looks compact. Thanks all!
http://bugs.python.org/issue202
On Wed, Jan 15, 2014 at 11:22 PM, "Martin v. Löwis" wrote:
> I don't think that it is possible to write an interpreter that is fully
> compatible for all it accepts. Would you think that the program
>
> print(repr(2**80).endswith("L"))
>
> is in the subset that should be supported by both Python 2
On Thu, Jan 16, 2014 at 1:25 AM, Eric V. Smith wrote:
>> Easiest fix for that would be to have long.__repr__ omit the L tag.
>> Then it'll do the same as it would in Py3.
>
> I think Martin's point is not this specific thing, but that such a
> subset would be useless. Would you drop dict.items() b
On Sat, Jan 18, 2014 at 12:51 PM, Ethan Furman wrote:
> It seems there are two possibilities with %a:
>
> 1) have it be ascii(repr(obj))
Wouldn't that be redundant? ascii() is already repr()-like.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.
On Sat, Jan 18, 2014 at 8:02 PM, Serhiy Storchaka wrote:
> 2. I'm not use any IDE, but if you use, it can be important for you. If IDE
> shows sources tree, unlikely you want to see generated *.clinic.c files in
> them. This will increase the list of sources almost twice.
A point for the contrary
On Wed, Jan 22, 2014 at 11:15 PM, Donald Stufft wrote:
> Do you really think those people would be making the same complaints
> if they could restore the previous behavior with a simple boolean flag
> delivered either via environment variable or in their own code?
You assume that it's easy to twe
On Thu, Jan 23, 2014 at 1:08 AM, Jesse Noller wrote:
>> Now, maybe it wouldn't be a problem if the fix is an environment
>> variable, but imagine a thousand-computer deployment and you have to
>> tweak the environment on all of them. Feel like doing that just
>> because the newest Python needs it?
On Sat, Jan 25, 2014 at 3:38 AM, Antoine Pitrou wrote:
> On Fri, 24 Jan 2014 18:32:17 +0200
> Ram Rachum wrote:
>> Question: Why is there no str.rreplace in Python?
>
> What would it do?
> (also, I think such questions are better asked on python-ideas)
Or python-list. Chances are there's a way t
On Sat, Jan 25, 2014 at 4:19 AM, Ram Rachum wrote:
> I now looked at the 17 most recent python-list threads. Out of them:
>
> - 58% are about third-party packages.
> - 17% are off-topic (not even programming related)
> - 11% are 2-vs-3 discussions
> - 5% are job offers.
> - 5% (which is just
On Sat, Jan 25, 2014 at 3:07 PM, Larry Hastings wrote:
> What should it be?
>
> A) pydoc and help() should not show bound parameters in the signature, like
> inspect.signature.
> B) pydoc and help() should show bound parameters in the signature, like
> inspect.getfullargspec.
Vote for A. As far a
On Mon, Feb 10, 2014 at 5:23 PM, anatoly techtonik wrote:
> http://status.python.org/ shows all green
>
> https://pypi.python.org/pypi/gazest shows
>
> Error 503 backend read error
>
> backend read error
>
> Guru Meditation:
>
> XID: 2792709923
Working for me. But then, your email only just came
On Fri, Feb 14, 2014 at 7:04 PM, Chris Withers wrote:
>
> To implement __lt__ in Python 2, I could do:
>
> def __lt__(self, other):
> if not isinstance(other, Range):
> return True
> return ((self._lower, self._upper, self._bounds) <
> (other._lower,
On Fri, Feb 14, 2014 at 9:20 PM, Antoine Pitrou wrote:
> Hmm, it seems you're right, but I'm quite sure some DBMSes have a
> consistent way of ordering NULLs when using ORDER BY on a nullable
> column.
Yes, and I believe it's part of the SQL-92 spec. Certainly here's
PostgreSQL's take on the matt
On Fri, Feb 14, 2014 at 9:42 PM, Nick Coghlan wrote:
> IIRC, MySQL and PostgreSQL sort them in the opposite order from each
> other
Ouch! You're right:
http://dev.mysql.com/doc/refman/5.7/en/working-with-null.html
"""When doing an ORDER BY, NULL values are presented first if you do
ORDER BY ...
On Sat, Feb 15, 2014 at 4:14 AM, Chris Barker wrote:
> (though it could get a bit tricky -- what would AlwaysGreater > float('inf")
> evaluate to?
>
It'd be true. AlwaysGreater is greater than infinity. It is greater
than float("nan"). It is greater than the entire concept of floating
point. It i
On Tue, Feb 18, 2014 at 1:30 AM, M.-A. Lemburg wrote:
>>
>> Also think of the implications of changing None at this point. It would
>> allow us to write programs that work Python >= 3.5 and Python <= 2.7, but
>> fail mysteriously in all other versions in between. What a mess that would
>> be...
On Wed, Feb 19, 2014 at 3:10 AM, Mark Lawrence wrote:
> Sorry if this has already been suggested, but why not introduce a new
> singleton to make the database people happier if not happy? To avoid
> confusion call it dbnull? A reasonable compromise or complete cobblers? :)
That would be a major
Apologies if this is misdirected!
I notice the switch to the new python.org web site has happened; but
now PEPs are simply 404:
http://www.python.org/dev/peps/pep-0008/
However, trimming the URL offers a redirect:
http://www.python.org/dev/peps/
->
http://legacy.python.org/dev/peps/
from whi
On Thu, Feb 20, 2014 at 10:25 AM, Chris Angelico wrote:
> I notice the switch to the new python.org web site has happened; but
> now PEPs are simply 404:
>
> http://www.python.org/dev/peps/pep-0008/
>
> However, trimming the URL offers a redirect:
>
> http:/
PEP: 463
Title: Exception-catching expressions
Version: $Revision$
Last-Modified: $Date$
Author: Chris Angelico
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 15-Feb-2014
Python-Version: 3.5
Post-History: 16-Feb-2014, 21-Feb-2014
Abstract
Just as PEP 308
On Fri, Feb 21, 2014 at 3:54 PM, Ethan Furman wrote:
> (I'll vote on the syntax when the bikeshedding begins ;).
Go get the keys to the time machine! Bikeshedding begins a week ago.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
On Fri, Feb 21, 2014 at 10:35 PM, Nick Coghlan wrote:
> On 21 February 2014 13:15, Chris Angelico wrote:
>> PEP: 463
>> Title: Exception-catching expressions
> Great work on this Chris - this is one of the best researched and
> justified Python syntax proposals I've
On Fri, Feb 21, 2014 at 11:37 PM, Paul Moore wrote:
> On 21 February 2014 11:35, Nick Coghlan wrote:
>>> Just as PEP 308 introduced a means of value-based conditions in an
>>> expression, this system allows exception-based conditions to be used
>>> as part of an expression.
>>
>> Great work on th
On Sat, Feb 22, 2014 at 12:53 AM, Nick Coghlan wrote:
> On 21 February 2014 22:42, Chris Angelico wrote:
>> People can already write:
>>
>> if (x if y else z):
>>
>> without the parens, and it works. Readability suffers when the same
>> keyword is used twic
On Sat, Feb 22, 2014 at 1:59 AM, Chris Angelico wrote:
> I've spent the better part of the last hour debating this in my head.
> It's basically a question of simplicity versus future flexibility:
> either keep the syntax clean and deny the multiple-except-clause
> option,
On Sat, Feb 22, 2014 at 1:50 AM, Antoine Pitrou wrote:
> On Sat, 22 Feb 2014 00:28:01 +1000
> Nick Coghlan wrote:
>>
>> Neither of these objections addresses the problems with the status quo,
>> though:
>>
>> - the status quo encourages overbroad exception handling (as
>> illustrated by examples
On Sat, Feb 22, 2014 at 1:03 AM, Eli Bendersky wrote:
> Chris, while I also commend you for the comprehensive PEP, I'm -1 on the
> proposal, for two main reasons:
>
> 1. Many proposals suggest new syntax to gain some succinctness. Each has to
> be judged for its own merits, and in this case IMHO t
On Sat, Feb 22, 2014 at 1:22 AM, Rob Cliffe wrote:
> Small point: in one of your examples you give a plug for the PEP "note the
> DRY improvement".
> I would suggest that similarly
> perhaps in your Lib/tarfile.py:2198 example you point out the increase
> in readability due to the 2 lines lini
On Sat, Feb 22, 2014 at 1:34 AM, Brett Cannon wrote:
> While I like the general concept, I agree that it looks too much like a
> crunched statement; the use of the colon is a non-starter for me. I'm sure
> I'm not the only one whose brain has been trained to view a colon in Python
> to mean "state
On Sat, Feb 22, 2014 at 2:19 AM, Brett Cannon wrote:
> I understand you are arguing that a try expression will lead to people just
> doing `something() except Exception: None` or whatever and that people will
> simply get lazy and not think about what they are doing with their
> exceptions. Unfort
On Sat, Feb 22, 2014 at 3:46 AM, Eric Snow wrote:
> Be sure to capture in the PEP (within reason) a summary of concerns
> and rebuttals/acquiescence. Eli's, Brett's, and Antoine's concerns
> likely reflect what others are thinking as well. The PEP and its
> result will be better for recording su
On Sat, Feb 22, 2014 at 4:32 AM, Antoine Pitrou wrote:
>> value = (expr except Exception then default)
>
> +0.5
> But I'm aware it requires reserving "then" as a keyword, which might
> need a prior SyntaxWarning.
There are no instances of "then" used as a name in the Python stdlib,
I already chec
b/tarfile.py:2198:
>> try:
>> g = grp.getgrnam(tarinfo.gname)[2]
>> except KeyError:
>> g = tarinfo.gid
>> try:
>> u = pwd.getpwnam(tarinfo.uname)[2]
>> exce
On Sat, Feb 22, 2014 at 9:06 AM, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> On 21 February 2014 13:15, Chris Angelico wrote:
>>
>>> Generator expressions require parentheses, unless they would be
>>> strictly redundant. Ambiguities with except expres
On Sat, Feb 22, 2014 at 10:29 AM, Greg Ewing
wrote:
> Antoine Pitrou wrote:
>
>>>lst = [1, 2]
>>>value = lst[2] except IndexError: "No value"
>>
>>
>> the gain in concision is counterbalanced by a loss in
>> readability,
>
>
> This version might be more readable:
>
>value = lst[2] exce
On Sat, Feb 22, 2014 at 12:10 PM, Glenn Linderman wrote:
> Here's a challenge: There has been a big thread about None versus (SQL)
> Null. Show how an except: expression can help the DB API more easily convert
> from using None to using a new Null singleton, and you'll have a winner :)
Heh! I'm n
On Sat, Feb 22, 2014 at 12:55 PM, Greg Ewing
wrote:
> Steven D'Aprano wrote:
>
>> result = computation(
>> int(arg) except ValueError: abort("Invalid int")
>> )
>>
>> Actually, not quite so nice as I first thought, since you're relying on
>> the side-effects o
On Sat, Feb 22, 2014 at 1:07 PM, Victor Stinner
wrote:
> At the first read, I'm unable to understand this long expression. At
> the second read, I'm still unable to see which instruction will be
> executed first: lvl1[key] or lvl2[key]?
>
> The advantage of the current syntax is that the control f
On Sat, Feb 22, 2014 at 3:04 PM, Chris Angelico wrote:
> On Sat, Feb 22, 2014 at 1:07 PM, Victor Stinner
> wrote:
>> At the first read, I'm unable to understand this long expression. At
>> the second read, I'm still unable to see which instruction will be
>> exe
On Sat, Feb 22, 2014 at 4:01 PM, Steven D'Aprano wrote:
> (Chris, I think that ought to go in the motivation section of the PEP.)
Added to my draft, and here's the peps diff:
diff -r c52a2ae3d98e pep-0463.txt
--- a/pep-0463.txt Fri Feb 21 23:27:51 2014 -0500
+++ b/pep-0463.txt Sat Feb 22 16:33:3
On Sat, Feb 22, 2014 at 8:20 PM, Antoine Pitrou wrote:
> On Sat, 22 Feb 2014 16:12:27 +0900
> "Stephen J. Turnbull" wrote:
>>
>> Note in support: I originally thought that "get" methods would be more
>> efficient, but since Nick pointed out that "haveattr" is implemented
>> by catching the except
On Sat, Feb 22, 2014 at 10:57 AM, Greg Ewing
wrote:
> Nick Coghlan wrote:
>>
>> As Chris later noted, you likely *could* still implement expression
>> local name binding for an except expression without a full closure, it
>> would just be rather difficult.
>
>
> I'm still not convinced it would be
On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou wrote:
> On Sat, 22 Feb 2014 20:29:27 +1100
> Chris Angelico wrote:
>>
>> Which means that, fundamentally, EAFP is the way to do it. So if PEP
>> 463 expressions had existed from the beginning, hasattr() probably
>&
On Sat, Feb 22, 2014 at 9:17 PM, Antoine Pitrou wrote:
> On Sat, 22 Feb 2014 21:09:07 +1100
> Chris Angelico wrote:
>> On Sat, Feb 22, 2014 at 8:58 PM, Antoine Pitrou wrote:
>> > On Sat, 22 Feb 2014 20:29:27 +1100
>> > Chris Angelico wrote:
>> >>
>
On Sat, Feb 22, 2014 at 10:01 PM, Greg Ewing
wrote:
> Chris Angelico wrote:
>>
>> On Sat, Feb 22, 2014 at 10:57 AM, Greg Ewing
>> wrote:
>>
>>> I'm still not convinced it would be all *that* difficult.
>>> Seems to me it would be semantically
On Sat, Feb 22, 2014 at 10:27 PM, Antoine Pitrou wrote:
> Yeah, none of these examples makes a convincing case that hasattr() is
> useless, IMO.
I'm not trying to make the case that it's useless. I'm trying to show
that, if it didn't exist, all of these would be written some other
way, and the ca
On Sat, Feb 22, 2014 at 11:14 PM, Stephen J. Turnbull
wrote:
> Antoine Pitrou writes:
> > On Sat, 22 Feb 2014 22:13:58 +1100
> > Chris Angelico wrote:
>
> > > hasattr(x,"y") <-> (x.y or True except AttributeError: False)
>
> > But it
On Sun, Feb 23, 2014 at 11:00 AM, Thomas Wouters wrote:
> On Sat, Feb 22, 2014 at 2:08 AM, Thomas Wouters wrote:
>>
>> (FWIW, I have a working patch without tests that allows all of these, I'll
>> upload it tonight so people can play with it. Oh, and FWIW, currently I'm +0
>> on the idea, -0 on t
On Sun, Feb 23, 2014 at 12:56 PM, Ethan Furman wrote:
> Open Questions
> ==
>
> It has been suggested to use ``%b`` for bytes as well as ``%s``.
>
> - Pro: clearly says 'this is bytes'; should be used for new code.
>
> - Con: does not exist in Python 2.x, so we would have two ways
On Mon, Feb 24, 2014 at 6:26 AM, Thomas Wouters wrote:
>> I see a risk of interfering with in-place assignment operators, e.g.
>>
>> x /= y except ZeroDivisionError: 1
>>
>> might not do what one could expect, because (as I assume) it would behave
>> differently from
>>
>> x = x / y except
On Mon, Feb 24, 2014 at 7:51 AM, Ethan Furman wrote:
>> Yes. Augmented assignment is still assignment, so a statement. The only
>> way to parse that is as
>>
>> x /= (y except ZeroDivisionError: 1)
>
>
> Well, that is certainly not what I would have expected.
I can see that you'd want to have tha
On Tue, Feb 25, 2014 at 11:27 AM, Jim J. Jewett wrote:
> This also makes me wonder whether the cost of a subscope
> (for exception capture) could be limited to when an
> exception actually occurs, and whether that might lower
> the cost enough to make the it a good tradeoff.
>
> def myfunc1(a,
On Tue, Feb 25, 2014 at 11:59 PM, Maciej Fijalkowski wrote:
>> Last issues:
>> - hash DoS
>
> is this fixed?
Yes, hash randomization was added as an option in 2.7.3 or 2.7.4 or
thereabouts, and is on by default in 3.3+. You do have to set an
environment variable for 2.7 (and I think 2.6 got that
On Wed, Feb 26, 2014 at 12:07 AM, Maciej Fijalkowski wrote:
> No, the hash randomization is broken, it does not provide enough
> randomness (without changing the hash function which only happened in
> 3.4+)
Hmm, I don't remember reading about that - got a link to more info? Or
was that report kep
On Wed, Feb 26, 2014 at 12:21 AM, Donald Stufft wrote:
> Instead of pre-generating one set of values that can be be used to DoS things
> you have to pre-generate 256 sets of values and try them until you get the
> right one. It’s like putting on armor made of paper and saying it’s harder to
> stab
On Thu, Feb 27, 2014 at 7:44 PM, Ronald Oussoren wrote:
> What about (also mentioned in the PEP)?
>
> value = (expr except Exception try default)
>
> This seems to read nicely, although “try” is at a completely different
> position than it is in the equivalent try statement.
>
> I like the gene
On Thu, Feb 27, 2014 at 9:44 PM, Ronald Oussoren wrote:
>> expr except Exception try default # "try" indicates the initial expr,
>> not the default
>
> I didn’t parse the expression this way at all, but quite naturally parsed is
> as “use expr, and try using default if expr raises Exception” and
On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman wrote:
> +1
>
> f() except ((TypeError, AttributeError): "No value")
>
> is a nice extension to the idea of
>
> value = expr except (
> Exception1: default1,
> Exception2: default2,
> Exception3: default3,
>)
>
>
I've added another utility script to my PEP draft repo:
https://github.com/Rosuav/ExceptExpr/blob/master/replace_except_expr.py
It's built out of some pretty horrendous hacks, it makes some
assumptions about code layout (eg spaces for indentation, and a
try/except block never has anything else on
On Fri, Feb 28, 2014 at 8:29 AM, Chris Angelico wrote:
> @@ -43,6 +43,34 @@
>
> * statistics.mean(data) - no way to handle an empty iterator
>
> +Had this facility existed early in Python's history, there would have been
> +no need to create dict.get() and related methods;
On Fri, Feb 28, 2014 at 10:33 AM, Nick Coghlan wrote:
>
> On 28 Feb 2014 05:56, "Chris Angelico" wrote:
>>
>> On Fri, Feb 28, 2014 at 6:36 AM, Glenn Linderman
>> wrote:
>> > +1
>> >
>> > f() except ((TypeError, AttributeErr
On Fri, Feb 28, 2014 at 1:12 PM, Glenn Linderman wrote:
> Yes. But the point is really the location of the (), sorry if my "nice
> extension" comment is throwing you off that track.
Ah! I see.
We touched on this syntax on -ideas, but at the time, the proposed
syntax didn't have parens around th
On Fri, Feb 28, 2014 at 6:38 PM, Glenn Linderman wrote:
> Whereas the current PEP syntax has ambiguity regarding how to interpret
> a-expr except except-list-b: b-expr except except-list-c: c-expr (does the
> 2nd except apply to a-expr or b-expr?), without parentheses, and, as far as
> I am concer
On Fri, Feb 28, 2014 at 8:30 PM, Glenn Linderman wrote:
> > Are there any other expressions that allow parens around a part of the
> > expression, without the stuff inside them becoming a completely
> > separate sub-expression?
>
>
> Sure. Function invocation. You can claim (and it is accurate) t
On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan wrote:
> So I think that on balance, I actually do prefer your current
> proposal. That said, I do think this is a variant worth discussing
> explicitly in the PEP, if only to remind people that there's
> definitely precedent for using a colon to sepa
On Fri, Feb 28, 2014 at 11:51 PM, Nick Coghlan wrote:
>>> > Are there any other expressions that allow parens around a part of the
>>> > expression, without the stuff inside them becoming a completely
>>> > separate sub-expression?
>
> Also generator expressions and most uses of yield or yield fro
On Sat, Mar 1, 2014 at 12:24 AM, Nick Coghlan wrote:
> Yeah, that works. You may also want to add a "common objections"
> section to explicitly cover the "but colons introduce suites"
> objection. That would provide a space to explicitly list all of the
> current "not introducing a suite" use case
On Sat, Mar 1, 2014 at 12:24 PM, Glenn Linderman wrote:
> You are overlooking that the keyword except provides exactly the connotation
> of lazy evaluation, so if this is your only reason for preferring the lambda
> syntax, you just erased it :)
Statements are always executed sequentially. That's
Way back in 2012, Martin Löwis declared a standing offer on this list
to get issue patches reviewed: review five issues and he'll review one
of yours. [1] Is that offer still around? Have any other devs made any
similar offer?
I have a couple of patches outstanding, notably issue 20249 [2], which
On Sun, Mar 2, 2014 at 11:11 AM, Chris Angelico wrote:
> I have a couple of patches outstanding, notably issue 20249 [2], which
> is a small change, has a patch, and has no activity or nosying since
> its creation.
And Benjamin Peterson has just looked into this one and committed it,
On Sun, Mar 2, 2014 at 11:25 AM, Antoine Pitrou wrote:
> On Sun, 2 Mar 2014 11:11:01 +1100
> Chris Angelico wrote:
>> More importantly, if there is such an offer, it'd be great to mention
>> it somewhere, so people can know what they can do to move an issue
>> fo
On Sun, Mar 2, 2014 at 4:07 PM, Terry Reedy wrote:
> On 3/1/2014 7:11 PM, Chris Angelico wrote:
>> I have a couple of patches outstanding, notably issue 20249 [2], which
>> is a small change, has a patch, and has no activity or nosying since
>> its creation.
>
On Sun, Mar 2, 2014 at 7:48 PM, Terry Reedy wrote:
> On 3/2/2014 1:51 AM, Chris Angelico wrote:
>>
>> On Sun, Mar 2, 2014 at 4:07 PM, Terry Reedy wrote:
>>>
>>> On 3/1/2014 7:11 PM, Chris Angelico wrote:
>>>>
>>>> I have a couple of patc
On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters wrote:
> On Thu, Feb 27, 2014 at 1:29 PM, Chris Angelico wrote:
>>
>> +Had this facility existed early in Python's history, there would have
>> been
>> +no need to create dict.get() and related methods;
>
>
On Thu, Mar 6, 2014 at 7:57 AM, Thomas Wouters wrote:
> All in all I believe I will continue to prefer specific methods for specific
> use-cases; I'm -0 on the idea of an except-expression, -0 on the syntax with
> the mandatory parentheses around the whole thing (and so far -1 on any of
> the othe
On Thu, Mar 6, 2014 at 12:03 PM, Thomas Wouters wrote:
> PEP update pushed (changeset 59653081cdf6.)
>
Thanks for that!
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://m
On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett wrote:
>
> The PEP currently says:
>
>> Alternative Proposals
>> =
>
>> Discussion on python-ideas brought up the following syntax suggestions::
>
>>value = expr except default if Exception [as e]
>
> This one was rejected becau
On Sat, Mar 8, 2014 at 5:58 AM, Jim J. Jewett wrote:
>
> (Thu Mar 6 23:26:47 CET 2014) Chris Angelico responded:
>
>> On Fri, Mar 7, 2014 at 7:29 AM, Jim J. Jewett
>> wrote:
>
>>> [ note that "x if y" already occurs in multiple contexts, and
>>
On Sat, Mar 8, 2014 at 9:06 PM, Victor Stinner wrote:
> And MyObject is not destroyed which is an obvious memory leak, beause
> there is no more explicit reference to it.
And it doesn't seem to be getting put into gc.garbage, either, which
is probably worth mentioning. You have __del__ in there,
On Mon, Mar 10, 2014 at 1:16 PM, Jim J. Jewett wrote:
> On Fri Mar 7 20:54:31 CET 2014, Chris Angelico wrote:
>> I don't see except expressions as fundamentally more associated with
>> if/else than with, say, an or chain, which works left to right.
>
> I do, becau
On Mon, Mar 10, 2014 at 1:35 PM, Jim J. Jewett wrote:
> The PEP should therefore explicitly state that implementation details
> may force the deferral to be permanent, and that this is considered an
> acceptable trade-off.
How about words to this effect?
"""Should there be, in future, a way to c
On Tue, Mar 11, 2014 at 3:56 AM, Antoine Pitrou wrote:
> On Mon, 10 Mar 2014 17:04:08 +0100
> "Stefan Richthofer" wrote:
>
>> > Guido famously hates two digit minor version numbers. :)
>>
>> This is no problem either. Simply switch to hexadecimal numbering ;)
>
> Or wrap around to negative number
On Tue, Mar 11, 2014 at 4:08 AM, R. David Murray wrote:
> (That said, I
> do see some merit to doing some extra cleaning at the 4.0
> boundary, just for mental convenience.)
A transition from 3.9 to 4.0 that removes a whole lot of deprecated
aliases and such wouldn't be a bad thing. It's technic
On Tue, Mar 11, 2014 at 5:17 AM, Ryan Gonzalez wrote:
> You forgot 3., and 3.$.
>
They're both earlier than digits. Comma is 2C and dollar is 24, I
remember those from the earliest days of playing around in assembly
language on an Epson PC-compatible running MS-DOS 5 :)
But that's beside the poi
On Wed, Mar 12, 2014 at 2:20 PM, Ethan Furman wrote:
> I sure hope this is accepted. I could have used it at least a half-dozen
> times in the last week -- which is more often than I would have used the
> ternary-if! :)
Where do we go from here? I've not made any edits for some time - no
materi
PEP 463, Exception-catching expressions, is stable and I believe ready
for pronouncement. Drumroll please...
http://www.python.org/dev/peps/pep-0463/
PEP: 463
Title: Exception-catching expressions
Version: $Revision$
Last-Modified: $Date$
Author: Chris Angelico
Status: Draft
Type: Standards
On Thu, Mar 13, 2014 at 2:14 AM, Brett Cannon wrote:
> While I'm +0 on the idea, I'm -1 on the syntax; I just don't like having a
> colon in an expression.
Which is why there are alternatives listed, and the best four of them
(including the proposed one) ranked.
ChrisA
__
On Thu, Mar 13, 2014 at 2:44 AM, Barry Warsaw wrote:
> That being said, the colon really bothers me, despite what is written in
> "Common objections". True, colons are used in places other than suite
> introduction, but with exception handling, colons *do* introduce a new suite,
> so its use here
On Thu, Mar 13, 2014 at 4:09 AM, Guido van Rossum wrote:
> But the thing I can't get behind are the motivation and rationale. I don't
> think that e.g. dict.get() would be unnecessary once we have except
> expressions, and I disagree with the position that EAFP is better than LBYL,
> or "generally
On Thu, Mar 13, 2014 at 7:14 AM, Barry Warsaw wrote:
> Interestingly enough, where ternaries are most useful are in the same
> situations where I think exception expressions would be most useful, in the
> setting of a variable or attribute to one of two different values. In both
> branches of the
On Thu, Mar 13, 2014 at 7:26 AM, "Martin v. Löwis" wrote:
> I think you (or someone) first needs to find a BDFL delegate.
> Traditionally, with syntax changes, there is a good chance that Guido
> doesn't want to delegate at all, so ask him whether he wants to delegate
> or not.
He beat you to it;
301 - 400 of 1000 matches
Mail list logo
