On Sun, Feb 1, 2015 at 9:13 PM, Benjamin wrote:
> I much prefer the idea of a 'where' keyword to denote typing, as discussed
> http://aroberge.blogspot.com/2015/01/type-hinting-in-python-focus-on.html,
> but I think a refinement of their idea would prove even better:
>
> def retry(callback, timeou
On Fri, Feb 6, 2015 at 10:27 AM, Francis Giraldeau
wrote:
> Instead, I access members directly:
> char *str = PyUnicode_DATA(frame->f_code->co_filename);
> size_t len = PyUnicode_GET_DATA_SIZE(frame->f_code->co_filename);
>
> Is it safe to assume that unicode objects co_filename and co_name are al
On Fri, Feb 13, 2015 at 12:46 PM, MRAB wrote:
class BaseInt:
> ... def __init__(self, value):
> ... self._value = value
> ... def __add__(self, other):
> ... return type(self)(self._value + other)
On Fri, Feb 13, 2015 at 11:55 AM, Guido van Rossum wrote:
> ... there
On Sat, Feb 14, 2015 at 11:07 AM, Nick Coghlan wrote:
> OTOH, it may be time to reconsider our recommendation to distros as well,
> suggesting that for Python 3.5+, we will consider it appropriate to have the
> "python" symlink refer to "python3".
If *all* distros provide a "python2" symlink, the
On Mon, Feb 16, 2015 at 10:47 PM, Petr Viktorin wrote:
>> If *all* distros provide a "python2" symlink, then the recommendation
>> can become "use python if it's 2/3 compatible, or python2/python3 to
>> choose", and then it won't hurt to switch python to be python3.
>> Are there known distros in w
On Wed, Jan 7, 2015 at 2:48 PM, Guido van Rossum wrote:
> There's a proof of concept patch in http://bugs.python.org/issue22906, but
> it doesn't have the __future__ import and probably gets other details wrong.
>
> Reference:
> PEP 479 -- Change StopIteration handling inside generators
>
> --
> -
On Tue, Feb 24, 2015 at 2:44 AM, Guido van Rossum wrote:
> I think that's a bit too strong. This has been unquestionably valid, correct
> Python -- it was an intentional feature from the start. It may not have
> turned out great, but I think that before warning loudly about every
> instance of thi
On Tue, Feb 24, 2015 at 3:12 AM, Brett Cannon wrote:
>
>
> On Mon Feb 23 2015 at 10:55:23 AM Chris Angelico wrote:
>>
>> On Tue, Feb 24, 2015 at 2:44 AM, Guido van Rossum
>> wrote:
>> > I think that's a bit too strong. This has been unquestionably val
On Tue, Feb 24, 2015 at 7:40 PM, M.-A. Lemburg wrote:
> I think the easiest way would be to tweak the error message
> output to indicate the real problem.
>
> At the moment, you get:
>
open('c:\test.txt')
> Traceback (most recent call last):
> File "", line 1, in
> FileNotFoundError: [Errn
On Wed, Feb 25, 2015 at 6:54 AM, Greg Ewing wrote:
> Chris Angelico wrote:
>>
>> Then he changed the code over to use his
>> own file instead of the provided sample, and at the same time,
>> switched from using open() to using csv.reader(open()), and moved all
>&
On Wed, Feb 25, 2015 at 5:00 PM, Ben Finney wrote:
> There is a wider context here, too: semantics of the backslash escape
> https://en.wikipedia.org/wiki/Backslash#Usage> commonly include
> “backslash followed by a character not otherwise mentioned will produce
> that character, verbatim”.
>
> Pr
On Sat, Mar 7, 2015 at 6:09 AM, Benjamin Peterson wrote:
> I think it would be preferable deprecate -O and -OO and replace them
> with flags like --no-docstrings or --no-asserts. Ideally, "optimization"
> levels shouldn't change program semantics.
Plenty of C compilers have optimization levels th
On Wed, Mar 11, 2015 at 4:27 AM, lou xiao wrote:
> I find a bug in str.lstrip, when i call str.lstrip, i get this result.
>
> tiny➜ ~ python
> Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
> [GCC 4.8.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
a='dev
On Sat, Mar 28, 2015 at 8:39 PM, Victor Stinner
wrote:
> Are you able to reproduce these issues? I'm unable to reproduce them
> on Fedora 21. Maybe they are more likely on Debian-like operating
> systems?
I just tried it on my Debian Wheezy AMD64, not running as root. (The
same computer the build
On Sat, Mar 28, 2015 at 9:10 PM, Chris Angelico wrote:
> On Sat, Mar 28, 2015 at 8:39 PM, Victor Stinner
> wrote:
>> Are you able to reproduce these issues? I'm unable to reproduce them
>> on Fedora 21. Maybe they are more likely on Debian-like operating
>> syste
On Sat, Mar 28, 2015 at 11:50 PM, Victor Stinner
wrote:
> Good, you are able to reproduce it. The next step is to identify the
> sequence of test to reproduce it. How do you run the test suite? Are you
> using -j1?
I just ran 'make test'. Early in the output are these lines:
./python ./Tools/sc
On Thu, Apr 9, 2015 at 8:32 AM, Alexander Belopolsky
wrote:
> A "named offset" is an abbreviation such as UTC, EST, MSK, MSD which (at any
> given time)
> corresponds to a fixed offset from UTC.
That assumes the abbreviations are unique. They're not. Just this
morning I had to explain to a new st
On Thu, Apr 16, 2015 at 1:00 AM, Lennart Regebro wrote:
> So because of this, perhaps we actually *should* change the internal
> representation to UTC, because that makes the issues I'm fighting with
> now so much simpler. (I'm currently trying to get arithmetic to do the
> right thing in all case
On Thu, Apr 16, 2015 at 1:43 AM, Lennart Regebro wrote:
> On Wed, Apr 15, 2015 at 11:10 AM, Chris Angelico wrote:
>> Bikeshed: Would arithmetic be based on UTC time or Unix time? It'd be
>> more logical to describe it as "adding six hours means adding six
>> hours
On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich wrote:
> * It is not optional. Please stop saying that. The people promoting it would
> prefer that everyone use it. If it is approved it will be optional in the
> way that PEP8 is optional. If I'm reading your annotated code it is
> certainly /not/
On Tue, Apr 21, 2015 at 10:52 AM, Ben Finney wrote:
> Chris Angelico writes:
>
>> On Tue, Apr 21, 2015 at 9:41 AM, Jack Diederich wrote:
>> > * It is not optional. Please stop saying that. The people promoting
>> > it would prefer that everyone use it. If it is app
On Tue, Apr 21, 2015 at 6:58 PM, Cory Benfield wrote:
> On 21 April 2015 at 01:45, Chris Angelico wrote:
>> When you're writing a library, it can be a great help to provide type
>> annotations, because every application that uses your library can
>> benefit.
>
>
On Tue, Apr 21, 2015 at 7:56 PM, Arnaud Delobelle wrote:
> If people constantly get told by their editor / IDE that they are calling
> function with the wrong argument types, what are they going to do? They may
> start adopting the same approach as in Java / C++ etc... where interfaces
> must be
On Wed, Apr 22, 2015 at 12:51 AM, Cory Benfield wrote:
> On 21 April 2015 at 15:31, Chris Angelico wrote:
>> Granted, there are some
>> vague areas - how many functions take a "file-like object", and are
>> they all the same? - but between MyPy types and the abst
On Sun, Apr 26, 2015 at 2:01 AM, Ronan Lamy wrote:
>>> * PEP484 hints are too high-level. Replacing an 'int' object with a
>>> single machine word would be useful, but an 'int' annotation gives no
>>> guarantee that it's correct (because Python 3 ints can have arbitrary
>>> size and because subcla
On Thu, Apr 30, 2015 at 11:03 AM, Stephen J. Turnbull
wrote:
> Note that even if you have a UTF-8 input source, some users are likely
> to be surprised because IIRC Python doesn't canonicalize in its
> codecs; that is left for higher-level libraries. Linux UTF-8 is
> usually NFC normalized, while
On Sun, May 10, 2015 at 4:13 AM, M.-A. Lemburg wrote:
> By providing a way to intentionally switch off the new default,
> we do make people aware of the risks and that's good enough,
> while still maintaining the contract people rightly expect of
> patch level releases of Python.
Just as long as
On Wed, May 13, 2015 at 3:04 AM, Larry Hastings wrote:
> Workflow 1
> ==
>
> When I ship beta 1, we create the 3.5 branch. trunk become 3.6.
>
> When I ship rc 1, the 3.5 branch becomes 3.5.1. I maintain a publically
> visible repo on bitbucket for 3.5.0, and we use bitbucket "pull reque
On Wed, May 13, 2015 at 8:15 AM, David Wilson wrote:
> SPF only covers the envelope sender, so it should be possible to set
> that to something that validates with SPF, keep the RFC822 From: header
> as it is, and maybe(?) include a separate Sender: header matching the
> envelope address.
As Came
On Mon, May 18, 2015 at 1:04 AM, Yury Selivanov wrote:
> Chris,
>
> Could you please add a link to the email where the PEP was accepted?
Sure. A Resolution: header is the right way to do this? Done.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.
On Mon, Sep 11, 2017 at 7:29 AM, Koos Zevenhoven wrote:
> On Sun, Sep 10, 2017 at 8:21 PM, Barry Warsaw wrote:
>>
>> On Sep 9, 2017, at 15:12, Guido van Rossum wrote:
>> >
>> > I can't tell whether this was meant seriously, but I don't think it's
>> > worth it. People can easily write their own
On Mon, Sep 11, 2017 at 11:03 AM, Barry Warsaw wrote:
> On Sep 10, 2017, at 14:39, Chris Angelico wrote:
>>
>> As a language change, definitely not. But I like this idea for
>> PYTHONBREAKPOINT. You set it to the name of a function, or to "pass"
>> if you wa
On Sun, Oct 8, 2017 at 7:02 PM, David Cournapeau wrote:
> It is certainly true that for a CLI tool that actually makes any network
> I/O, especially SSL, import times will quickly be negligible. It becomes
> tricky for complex tools, because of error management. For example, a common
> pattern I h
On Mon, Oct 23, 2017 at 2:06 AM, Wes Turner wrote:
> What about bus latency (and variance)?
I'm currently in Los Angeles. Bus latency is measured in minutes, and
may easily exceed sixty of them. :|
Seriously though: For applications requiring accurate representation
of relativistic effects, the
On Mon, Nov 6, 2017 at 9:36 PM, Stefan Krah wrote:
> On Mon, Nov 06, 2017 at 12:18:17PM +0200, Paul Sokolovsky wrote:
>> MicroPython hashmap implementation is effectively O(n) (average and
>> worst case) due to the algorithm parameters chosen (like the load factor
>> of 1). Of course, parameters c
On Wed, Nov 8, 2017 at 1:32 AM, Antoine Pitrou wrote:
> On Wed, 8 Nov 2017 00:01:04 +1000
> Nick Coghlan wrote:
>
>> On 7 November 2017 at 23:48, Stefan Krah wrote:
>> >
>> >
>> > This is just a reminder that the current dict is not an "OrderedDict":
>> >
>> from collections import OrderedD
On Mon, Nov 13, 2017 at 9:46 PM, Antoine Pitrou wrote:
> On Sun, 12 Nov 2017 19:48:28 -0800
> Nathaniel Smith wrote:
>> On Sun, Nov 12, 2017 at 1:24 AM, Nick Coghlan wrote:
>> > This change will lead to DeprecationWarning being displayed by default for:
>> >
>> > * code executed directly at the
On Thu, Nov 23, 2017 at 3:36 PM, Greg Ewing wrote:
> Paul Moore wrote:
>>
>> 3. List comprehensions are the same as list(the equivalent generator
>> expression).
>
>
> I don't think that's ever been quite true -- there have
> always been odd cases such as what happens if you
> raise StopIteration
On Fri, Nov 24, 2017 at 1:21 AM, Paul Moore wrote:
> On 23 November 2017 at 13:04, Ivan Levkivskyi wrote:
>> Let us forget for a moment about other problems and focus on this one: list
>> comprehension is currently not equivalent to a for-loop.
>> There are two options:
>> - Fix this, i.e. make c
On Mon, Nov 27, 2017 at 2:20 PM, David Mertz wrote:
> Changing subject line because this is way off to the side. Guido and
> Nathaniel point out that you can do everything yield expressions do with
> async/await *without* an explicit event loop. While I know that is true, it
> feels like the bes
On Fri, Dec 1, 2017 at 5:45 AM, Tres Seaver wrote:
>> I would *not* add any spelling for an explicit bare-except equivalent.
>> You would have to write:
>>
>> val = name.strip()[4:].upper() except Exception as -1
>
>
> Wouldn't that really need to be this instead, for a true 'except:'
> equival
On Wed, Dec 6, 2017 at 4:46 PM, Nick Coghlan wrote:
> Something I've just noticed that needs to be clarified: on Linux, "C"
> locale and "POSIX" locale are aliases, but this isn't true in general
> (e.g. it's not the case on *BSD systems, including Mac OS X).
For those of us with little to no BSD
On Tue, Dec 12, 2017 at 7:39 PM, Michel Desmoulin
wrote:
>
>
> Le 29/11/2017 à 19:02, Barry Warsaw a écrit :
>> On Nov 29, 2017, at 12:40, David Mertz wrote:
>>
>>> I think some syntax could be possible to only "catch" some exceptions and
>>> let others propagate. Maybe:
>>>
>>>val = name.s
On Wed, Dec 13, 2017 at 6:03 AM, Guido van Rossum wrote:
> And I'll never approve syntax to make it easier to just ignore all
> exceptions without looking at them.
Well, I certainly wouldn't advocate "except Exception: -1", but the
syntax is the same as "except KeyError: -1" which is less
unreaso
Redirecting comments from the PR to the ML. Everything that was
tightly bound to the PR has been dropped.
On Wed, Dec 13, 2017 at 12:15 PM, Yury Selivanov
wrote:
> Most of your questions should be asked on python-dev. I'll answer them here,
> but if you have any follow-ups, please raise the on t
On Tue, Dec 19, 2017 at 6:09 PM, Steven D'Aprano wrote:
> I completely agree. We might argue that it was a mistake to sort dicts
> in the first place, or at least a mistake to *always* sort them without
> allowing the caller to provide a sort key. But what's done is done: the
> fact that dicts are
On Mon, Jan 1, 2018 at 12:39 PM, Steven D'Aprano wrote:
> On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote:
>
>> This is another reason why we ought to let users do their own IDNA handling
>> if they want...
>
> I expect that letting users do their own IDNA handling will correspond
On Sun, Jan 14, 2018 at 7:10 PM, joannah nanjekye
wrote:
> Hello,
>
> Apparently when you implement two methods with the same name:
>
> def sub(x, y):
> print(x -y)
>
> def sub(x, y):
> print(x -y)
>
> Even with type hints.
>
> def sub(x: int, y:int) -> int:
> return x - y
>
> def su
On Sun, Jan 28, 2018 at 3:58 AM, Senthil Kumaran wrote:
> Someone in HackerNews shared the Guido's Python 1.0.0 announcement from 27
> Jan 1994. That is, on this day, 20 years ago.
>
> https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo/KIFdu0-Dv7sJ
>
> It is very entertain
On Thu, Feb 22, 2018 at 8:38 AM, Guido van Rossum wrote:
> On Wed, Feb 21, 2018 at 1:28 PM, Bernát Gábor
> wrote:
>>
>> Any reason in particular for not using github issues (or blockers in
>> achieving this)?
>
>
> Many core devs did not want to change their workflow, and Brett did not want
> to
On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote:
> On Feb 22 2018, Serhiy Storchaka wrote:
>> 1. Inner generator expression:
>>
>> result = [y + g(y) for y in (f(x) for x in range(10))]
>>
> [...]
>>
>> And maybe there are other ways.
>
> I think the syntax recently brough up by Nick is
On Mon, Feb 26, 2018 at 12:11 AM, Nikolaus Rath wrote:
> On Feb 25 2018, Chris Angelico wrote:
>> On Sun, Feb 25, 2018 at 11:02 PM, Nikolaus Rath wrote:
>>> On Feb 22 2018, Serhiy Storchaka wrote:
>>>> 1. Inner generator expression:
>>>>
>>&
On Mon, Feb 26, 2018 at 8:00 PM, Nick Coghlan wrote:
> On 26 February 2018 at 01:08, Chris Angelico wrote:
>>
>> Speaking as a C programmer who's quite happy to write code like "while
>> ((var = func()) != sentinel)", I wouldn't object to this coming up i
As part of the discussions on local name binding, I dug up a patch
that I sent to python-ideas back in June 2015. That's two and a half
years ago, and was based on CPython 3.5. Here's what happened when I
attempted to apply it to the current master branch (3.8):
$ patch <~/Downloads/scope_hack.pat
On Thu, Mar 29, 2018 at 7:18 PM, Nathaniel Smith wrote:
> Another example is the multiprocessing module: it's very safe to
> assume that the parent and the child are using the same interpreter
> :-). There's no fundamental reason you shouldn't be able to send
> bytecode between them.
You put a sm
On Thu, Mar 29, 2018 at 7:56 PM, Paul Moore wrote:
> On 29 March 2018 at 09:49, Chris Angelico wrote:
>> On Thu, Mar 29, 2018 at 7:18 PM, Nathaniel Smith wrote:
>>> Another example is the multiprocessing module: it's very safe to
>>> assume that the parent
On Thu, Mar 29, 2018 at 11:28 PM, Steven D'Aprano wrote:
> On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
>
>> The optimizer already changes
>> semantic. Non-optimized "if a and True:" would call bool(a) twice, but
>> optimized code calls it only once.
>
> I don't understand thi
On Fri, Mar 30, 2018 at 1:08 AM, Chris Angelico wrote:
> On Thu, Mar 29, 2018 at 11:28 PM, Steven D'Aprano wrote:
>> On Wed, Mar 28, 2018 at 06:27:19PM +0300, Serhiy Storchaka wrote:
>>
>>> The optimizer already changes
>>> semantic. Non-optimized "if
On Tue, Apr 3, 2018 at 10:51 PM, Paul G wrote:
> Breaking this off from the pickle thread because it seems unrelated:
>
> On 04/02/2018 06:57 PM, Lukasz Langa wrote:
>> I think we need to get past thinking about "Python 2" vs. "Python 3". This
>> frame of mind creates space for another mythical r
572
Title: Assignment Expressions
Author: Chris Angelico
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Feb-2018
Python-Version: 3.8
Post-History: 28-Feb-2018, 02-Mar-2018, 23-Mar-2018, 04-Apr-2018, 17-Apr-2018
Abstract
This is a proposal for creating a way to
On Tue, Apr 17, 2018 at 6:26 PM, Chris Jerdonek
wrote:
> On Tue, Apr 17, 2018 at 12:46 AM, Chris Angelico wrote:
>>
>> Having survived four rounds in the boxing ring at python-ideas, PEP
>> 572 is now ready to enter the arena of python-dev. I'll let the
>> pro
On Tue, Apr 17, 2018 at 10:17 PM, Nick Coghlan wrote:
> Initially I thought the problem was specific to tuple unpacking
> syntax, but attempting to explain why subscript assignment and
> attribute assignments were OK made me realise that they're actually
> even worse off (since they can execute ar
On Wed, Apr 18, 2018 at 5:28 AM, Tim Peters wrote:
> I'll channel that Guido would be happiest if this rule were followed:
>
> Given an assignment statement using "=", the meaning is the same if
> "=" is replaced with ":=".
That's broadly the intention. At the moment, there are two exceptions:
1
On Wed, Apr 18, 2018 at 7:53 AM, Terry Reedy wrote:
> On 4/17/2018 3:46 AM, Chris Angelico wrote:
>
>> Abstract
>>
>>
>> This is a proposal for creating a way to assign to names within an
>> expression.
>
>
> I started at -something as t
On Wed, Apr 18, 2018 at 11:20 AM, Steven D'Aprano wrote:
> On Wed, Apr 18, 2018 at 10:13:58AM +1000, Chris Angelico wrote:
>
> [regarding comprehensions]
>
>> The changes here are only to edge and corner cases, other than as they
>> specifically relate to assign
On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum wrote:
> I can't tell from this what the PEP actually says should happen in that
> example. When I first saw it I thought "Gaah! What a horrible piece of
> code." But it works today, and people's code *will* break if we change its
> meaning.
>
> H
On Thu, Apr 19, 2018 at 2:18 AM, Guido van Rossum wrote:
> On Wed, Apr 18, 2018 at 7:35 AM, Chris Angelico wrote:
>>
>> On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum
>> wrote:
>> > I can't tell from this what the PEP actually says should happen in that
On Thu, Apr 19, 2018 at 6:26 AM, Barry Warsaw wrote:
> On Apr 18, 2018, at 11:17, Chris Angelico wrote:
>
>> At the moment, it isn't aware of 'del’.
>
> I don’t know if it’s relevant to the current discussion, but don’t forget
> about implicit dels:
>
ll need to change, if it
tried to use the same name in multiple scopes, or tried to use ancient
Python 2 semantics with a yield expression in the outermost iterable.
I'm pretty much ready for pronouncement.
https://www.python.org/dev/peps/pep-0572/
ChrisA
PEP: 572
Title: Assignment Express
On Fri, Apr 20, 2018 at 2:45 PM, Dmitry Malinovsky wrote:
> Hello Chris, and thank you for working on this PEP!
>
> What do you think about using variable type hints with this syntax?
> I tried to search through python-dev and couldn't find a single post
> discussing that question.
> If I missed i
On Fri, Apr 20, 2018 at 1:30 PM, Stephen J. Turnbull
wrote:
> Christoph Groth writes:
>
> > Wouldn't it be a pity not to liberate assignments from their boring
> > statement existence?
>
> Maybe not. While it would be nice to solve the loop-and-a-half
> "problem" and the loop variable initializ
On Fri, Apr 20, 2018 at 4:32 PM, Robert Smallshire wrote:
> If you restrict the idea to 'if' and 'while', Why not render this using the
> existing 'as' form for binding names, already used with 'except' and 'with':
>
> while learner.get(static_hint) as points:
> learner.feed(f(points))
On Fri, Apr 20, 2018 at 6:32 PM, Paul Moore wrote:
>> def read_document(file):
>> doc = ""
>> while (token := file.get_next_token()) != "END":
>> doc += token
>> return doc
>>
>> The loop condition is "while the token is not END", or "while
>> get_next_token() doesn't return EN
On Fri, Apr 20, 2018 at 10:51 PM, Paul Moore wrote:
> 2. I hadn't really thought of the PEP in those terms. Now that you've
> mentioned it, "Python has never before had syntax that assigns names
> from within an expression" is quite a significant change, and one the
> PEP needs to examine the impl
On Sat, Apr 21, 2018 at 1:50 AM, Guido van Rossum wrote:
> Maybe annotations should get a brief mention in the Rejected Ideas section,
> with your explanation here added. (And maybe my response.)
Good idea. Actually, since it's a syntactic difference, I've promoted
it to the "Differences" section
On Sat, Apr 21, 2018 at 2:17 AM, Christoph Groth
wrote:
> Chris Barker - NOAA Federal wrote:
>
>> > Personally, I even slightly prefer
>> >
>> > a := 3
>> >
>> > to the commonplace
>> >
>> > a = 3
>> > because it visually expresses the asymmetry of the operation.
>>
>> Careful here! That’s a fine
On Sat, Apr 21, 2018 at 2:50 AM, Mike Miller wrote:
>
> On 2018-04-19 23:52, Chris Angelico wrote:
>>
>> And are limited to conditions that check the truthiness/falsiness of
>> the value you care about. So that works for re.match, but not for
>> anything that might
On Sat, Apr 21, 2018 at 6:04 AM, David Mertz wrote:
> It's horrors like this:
>
> g(items[idx] := idx := f())
>
> That make me maybe +0 if the PEP only allowed simple name targets, but
> decisively -1 for any assignment target in the current PEP.
But that's my point: you shouldn't need to wri
On Sat, Apr 21, 2018 at 6:59 AM, Guido van Rossum wrote:
> Does the PEP currently propose to *allow* that horrible example? I thought
> Tim Peters successfully pleaded to *only* allow a single "NAME := ".
> You don't have to implement this restriction -- we know it's possible to
> implement, and i
On Sat, Apr 21, 2018 at 8:07 AM, Mike Miller wrote:
> On 2018-04-20 14:59, Jelle Zijlstra wrote:
>> In other words, the with statement would continue to require an as
>> clause
>> outside of the parentheses. A double name binding doesn't seem very
>> useful
>> however.
>>
>> The with
On Sat, Apr 21, 2018 at 11:38 AM, Anthony Flury via Python-Dev
wrote:
> I am entirely new to this list, but if I can I would like share my comments
> :
>
> * I do think this proposal := has merit in my
>opinion; it does make some code more readable.
>
> * I think readability is only improv
On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote:
> On Sat, Apr 21, 2018 at 12:30:36PM +1000, Chris Angelico wrote:
>> Introducing expression assignments will make these oddities even more
>> obvious. You'd be able to demonstrate things like this at function
>&g
On Sat, Apr 21, 2018 at 6:38 PM, Anthony Flury via Python-Dev
wrote:
> On 21/04/18 08:46, Chris Angelico wrote:
>>
>> doubled_items = [x for x in (items := get_items()) if x * 2 in items]
>>
>> This will leak 'items' into the surrounding scope (but not 'x
On Sat, Apr 21, 2018 at 7:12 PM, Paul Moore wrote:
> On 21 April 2018 at 03:30, Chris Angelico wrote:
>> There's that word "readability" again. Sometimes I wish the Zen of
>> Python didn't use it, because everyone seems to think that "readable&quo
On Sat, Apr 21, 2018 at 10:26 PM, Steven D'Aprano wrote:
> On Sat, Apr 21, 2018 at 05:46:44PM +1000, Chris Angelico wrote:
>> On Sat, Apr 21, 2018 at 5:11 PM, Steven D'Aprano wrote:
>
>> > So can you explain specifically what odd function-scope behaviour you
vior
> 5. with (closing(urlopen(url)) as dl): # same
>
> 4. with closing(urlopen(url) as dl): # urlopener named early
>
>
> On 2018-04-20 17:15, Chris Angelico wrote:
>>
>> The second and fifth could be special cased as either the same as
>> first and
On Sun, Apr 22, 2018 at 7:29 PM, Christoph Groth
wrote:
> If I had to choose between the above and ":= binding expressions", I
> guess I would tend to prefer the latter because they are sufficient,
> nicer looking and offer less potential for trouble. But I think that it
> is worth to fully discu
On Mon, Apr 23, 2018 at 6:22 AM, Mike Miller wrote:
> On 2018-04-22 12:37, Chris Angelico wrote:
>> Kinda, except that that's not quite a match either. But mainly, the
>> comparison with 'with' and 'except' is dangerously incompatible.
>
> Hmm, looks
On Mon, Apr 23, 2018 at 8:20 AM, Mike Miller wrote:
>
> On 2018-04-22 14:33, Chris Angelico wrote:
>>
>> with open(fn) as f:
>> with (open(fn) as f):
>>
>> These two do the same thing, but only because a file object's
>> __enter__ returns self.
On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote:
> On 23.04.2018 17:59, Steve Holden wrote:
>
>
> While Tim's expression might look (superficially) like C, the five-line
> alternative isn't exactly an inspiring example of Pythonicity, is it?
>
>
> What about
>
> diff = x - x_base
> if diff an
On Tue, Apr 24, 2018 at 6:21 AM, Sven R. Kunze wrote:
> On 23.04.2018 19:24, Chris Angelico wrote:
>>
>> On Tue, Apr 24, 2018 at 3:13 AM, Sven R. Kunze wrote:
>>>
>>> diff = x - x_base
>>> if diff and gcd(diff, n) > 1:
>>> return gcd(d
On Tue, Apr 24, 2018 at 7:25 AM, Sven R. Kunze wrote:
> On 23.04.2018 22:37, Chris Angelico wrote:
>>
>> Ah, are you one of those programmers who writes code once and it's
>> instantly perfect? I apologize, I didn't realize I was in the presence
>> of a unic
On Tue, Apr 24, 2018 at 4:27 PM, Antoine Pitrou wrote:
> On Tue, 24 Apr 2018 01:06:30 -0500
> Tim Peters wrote:
>>
>> > - does it make Python easier to learn and teach?
>>
>> By whom? Almost no addition has ever made a language easier to learn
>> for raw beginners: every addition is something t
On Tue, Apr 24, 2018 at 5:12 PM, Greg Ewing wrote:
> Chris Jerdonek wrote:
>
if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
>
>
>> "if diff, which we let equal x - x_base, and g, which ..." or
>> "if diff, which we set equal to x - x_base, and g, which " or
>> "if diff, which we def
On Tue, Apr 24, 2018 at 5:23 PM, Greg Ewing wrote:
> Stephen J. Turnbull wrote:
>>
>> Neologisms are usually written in the
>> other order: "dead on arrival (DOA, for short)." ;-)
>
>
> Maybe we can make use of that?
>
>if (x - x_base) (diff) and gcd(diff, n) (g) > 1:
>
> That doesn't work, be
On Wed, Apr 25, 2018 at 12:23 AM, Yury Selivanov
wrote:
> On Tue, Apr 24, 2018 at 10:07 AM, Nick Coghlan wrote:
>
>>> "=" is always an assignment.
>>> "==" is always an equality check.
>>
>> That's not the distinction I meant, I meant the difficulty of
>> explaining the discrepancies in this list
On Wed, Apr 25, 2018 at 12:54 AM, Anthony Flury via Python-Dev
wrote:
> As discussed previously by others on this exact proposals, you now have the
> issue of confusion when using keyword arguments : *my_func(a = b)* :
> clearly that is a call to `my_func' where argument a has the value of b, but
On Wed, Apr 25, 2018 at 1:03 AM, Yury Selivanov wrote:
> On Tue, Apr 24, 2018 at 10:56 AM, Chris Angelico wrote:
> [..]
>>> A lot of other questions arise though. PEP 572 proposes:
>>>
>>> a = 1 # assignment
>>> a := 1 # also assignment
>>&g
On Wed, Apr 25, 2018 at 12:58 AM, Yury Selivanov
wrote:
> On Tue, Apr 24, 2018 at 10:49 AM, Paul Moore wrote:
> [..]
3. Most importantly: it is *not* allowed to mask names in the current
local scope.
>>>
>>> While I agree this would be unambiguous to a computer, I think for
>>> most hum
: Chris Angelico
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Feb-2018
Python-Version: 3.8
Post-History: 28-Feb-2018, 02-Mar-2018, 23-Mar-2018, 04-Apr-2018, 17-Apr-2018,
25-Apr-2018
Abstract
This is a proposal for creating a way to assign to
101 - 200 of 1000 matches
Mail list logo
