Re: [Python-Dev] Slow down...

On Mon, May 07, 2018 at 10:23:32PM +0200, Antoine Pitrou wrote: > On Mon, 07 May 2018 19:19:28 + > Ryan Gonzalez wrote: > > 10 years feels like a simultaneously long and arbitrary limit. IMO a policy > > of "try to avoid major language features for a while" would work

Re: [Python-Dev] Slow down...

On Mon, May 07, 2018 at 10:21:13AM -0700, Glenn Linderman wrote: > Dan's original comment about language versus library is interesting, > though. It is probably true that one should resist adding language where > library suffices, but sometimes a lack of certain expressiveness in the >

Re: [Python-Dev] Slow down...

On Wed, May 09, 2018 at 01:35:53PM +0200, Antoine Pitrou wrote: > > > I would remove "for a while". "Try to avoid major language features" > > > sounds good. > > > > It sounds good, until you ask about "What if we had that policy from > > the beginning?" [...] > "Try to avoid" would make it

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote: > >> We're focused on Python 3.8 and 3.9, not Python 5 or Python 6. > > Hmmm... When I was hearing the repeated belated saying that Python > will never ever jump on the statically typed ship on each and every > static type

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

On Fri, Apr 27, 2018 at 10:56:06PM +1000, Nick Coghlan wrote: > On 27 April 2018 at 22:28, Steven D'Aprano <st...@pearwood.info> wrote: > > > On Fri, Apr 27, 2018 at 08:13:20AM +0200, Andrea Griffini wrote: > > > Now we got standard library features requiring type anno

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Fri, Apr 27, 2018 at 04:24:35PM -0400, Wes Turner wrote: > if ((1) or (x := 3)): > if ((y := func(x)) if x else (x := 3)) Wes, there is *absolutely nothing new* here. This sort of error is already possible in Python. Do you see a lot of code like: if (1 or sequence.append(3) or

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Fri, May 11, 2018 at 11:15:11AM -0700, Chris Barker - NOAA Federal via Python-Dev wrote: > > while the changes introduced by Python 3 > > affect pretty much everyone, even people who only write small simple > > scripts. > > Sure they do, but the *hard stuff* not so much. > > I have found

Re: [Python-Dev] Process to remove a Python feature

On Tue, May 08, 2018 at 03:20:50PM +0200, Stéphane Blondon wrote: > I wonder if it would be interesting to have a package available by > pypi.org which would provide the removed features. [...] > Cons: > - it pushes the question to how many times the previous behavior should > be maintained from

Re: [Python-Dev] Dealing with tone in an email

On Sun, May 06, 2018 at 11:09:21AM +1000, Chris Angelico wrote: > What exactly didn't work? I don't understand. https://bugs.python.org/issue33412 -- Steve ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] Process to remove a Python feature

On Fri, May 04, 2018 at 12:56:57PM +0200, Victor Stinner wrote: > Sorry, when I wrote "Python 4" I mean "the new Python release which > introduces a lot of backward incompatible changes and will annoy > everyone". It can be Python 3.9 or 3.10, or whatever version > (including 4.3 if you want) :-)

Re: [Python-Dev] What is the rationale behind source only releases?

On Tue, May 15, 2018 at 10:55:07PM -0700, Chris Jerdonek wrote: > What does “no release at all” mean? If it’s not released, how would people > use it? I've been using Python 1.7 for years now. It is the perfect Python, with exactly all the features I want, and none that I don't want, and so much

[Python-Dev] Normalisation of unicode and keywords

Stephan Houben noticed that Python apparently allows identifiers to be keywords, if you use Unicode "mathematical bold" letters. His explanation is that the identifier is normalised, but not until after keywords are checked for. So this works: class Spam: locals()['if'] = 1 Spam.퐢퐟#

Re: [Python-Dev] Unicode 11.0.0 released

On Thu, Jun 07, 2018 at 06:02:40PM +0100, MRAB wrote: > The Python community _is_ meant to be inclusive, and we should support > the addition of ginger emoijs. :-) https://www.youtube.com/watch?v=KVN_0qvuhhw -- Steve ___ Python-Dev mailing list

Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 billion

On Mon, Jun 04, 2018 at 07:25:49PM +0200, Matěj Cepl wrote: > On 2018-06-04, 16:06 GMT, Guido van Rossum wrote: > > I don't see how this *increases* the uncertainty. Surely if > > GitHub had remained independent there would have been be > > similar concerns about how it would make enough money

Re: [Python-Dev] Microsoft to acquire GitHub for $7.5 b

On Wed, Jun 06, 2018 at 05:59:17PM -0700, Chris Jerdonek wrote: > Is the “service” they provide (and what it needs) allowed to change over > time, so that the rights granted can expand? Of course it can change. And they might not even need to give us notice. But that's no different from any

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Thu, Jun 28, 2018 at 03:42:49PM -0700, Chris Barker via Python-Dev wrote: > If we think hardly anyone is ever going to do that -- then I guess it > doesn't matter how it's handled. That's how you get a language with surprising special cases, gotchas and landmines in its behaviour. (Cough PHP

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sat, Jun 30, 2018 at 11:32:03PM -0500, Tim Peters wrote: [...] > So, no, gaining performance is _not_ the motivation here. You already had > a way to make it "run fast'. The motivation is the _brevity_ assignment > expressions allow while _retaining_ all of the two-statement form's >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jul 01, 2018 at 08:35:08AM -0700, Michael Selik wrote: > On Sun, Jul 1, 2018 at 12:39 AM Tim Peters wrote: > > > So, ya, when someone claims [assignment expressions will] make Python > > significantly harder to teach, I'm skeptical of that claim. > > > > I don't believe anyone is making

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 08:00:20AM -0400, Eric V. Smith wrote: > On 6/27/2018 7:08 AM, Chris Angelico wrote: > >It gets funnier with nested loops. Or scarier. I've lost the ability > >to distinguish those two. > > > >def test(): > > spam = 1 > > ham = 2 > > vars = [key1+key2 for key1

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 03:41:23PM +0200, Antoine Pitrou wrote: > > Why is this discussion talking about comprehensions at all? > Is there a decent use case for using assignments in comprehensions (as > opposed to language lawyering or deliberate obfuscation)? Yes. The *very first* motivating

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 05:52:16PM +0300, Ivan Pozdeev via Python-Dev wrote: > >What this means in practice is that assignments will go to different > >scopes depending on *where* they are in the comprehension: > > > > [ expr for x in iter1 for y in iter2 if cond ...] > > [ BB

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Fri, Jun 22, 2018 at 11:28:45AM -0700, Chris Barker via Python-Dev wrote: > On Fri, Jun 22, 2018 at 10:09 AM, Michael Selik wrote: > > > I forgot to add that I don't anticipate changing my lesson plans if this > > proposal is accepted. There's already not enough time to teach everything > >

Re: [Python-Dev] About [].append == [].append

On Fri, Jun 22, 2018 at 11:44:07AM -0700, Guido van Rossum wrote: [...] > > I know why it happens -- at the REPL, the interpreter uses the same > > object for both 17.1 instances when they're part of the same statement, > > but not when they're on separate lines. I just don't know whether this > >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Fri, Jun 22, 2018 at 10:59:43AM -0700, Michael Selik wrote: > > > I've started testing the proposed syntax when I teach. I don't have a > > > large > > > sample yet, but most students either dislike it or don't appreciate the > > > benefits. They state a clear preference for shorter, simpler

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sat, Jun 23, 2018 at 12:22:33AM +1000, Nick Coghlan wrote: [...] > * for the reactions to my description of the currently proposed parent > local scoping behaviour in comprehensions, I'd use the word > "horrified", and feel I wasn't overstating the response :) Without knowing how you worded

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Fri, Jun 22, 2018 at 09:08:37PM -0700, Chris Barker wrote: > > So if you absolutely need to teach it to a beginner, it > > shouldn't be difficult once they understand the difference between an > > expression and a statement. > > > > probably not, though that's a distinction that's mostly

Re: [Python-Dev] About [].append == [].append

On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote: > Honestly it looks to me like the status quo is perfect. Does this example work for you? py> (17.1).hex == (17.1).hex True But: py> a = 17.1 py> b = 17.1 py> a.hex == b.hex False I know why it happens -- at the REPL, the

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jun 24, 2018 at 09:24:39AM -0700, Guido van Rossum wrote: > A quick follow-up: PEP 572 currently has two ideas: (a) introduce := for > inline assignment, (b) when := is used in a comprehension, set the scope > for the target as if the assignment occurred outside any comprehensions. It >

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jun 24, 2018 at 04:33:38PM +1000, Nick Coghlan wrote: [...] > > Making the intentional choice to use an assignment expression is not > > really "implicit" in any meaningful sense. > > No, it's actually implicit: there's an extra "global NAME" or > "nonlocal NAME" in the equivalent code

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sun, Jun 24, 2018 at 02:33:59PM +1000, Nick Coghlan wrote: > Given that PEP 572 *is* proposing implicit comprehension state export, "Implicit" and "explicit" are two terms which often get misused to mean "I don't like it" and "I do like it". Making the intentional choice to use an

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Mon, Jun 25, 2018 at 11:30:24AM +1200, Greg Ewing wrote: > Guido van Rossum wrote: > >Greg seem to be +0 or better for (a) > > Actually, I'm closer to -1 on (a) as well. I don't like := as a > way of getting assignment in an expression. The only thing I would > give a non-negative rating is

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Tue, Jun 26, 2018 at 05:42:43AM +1000, Chris Angelico wrote: > So. sublocal scopes, like in the earliest versions of PEP 572? > > The wheel turns round and round, and the same spokes come up. It isn't as if comprehensions (and generator expressions) run in a proper separate scope. It is

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 08:30:00AM +0100, Paul Moore wrote: > On 27 June 2018 at 07:54, Steven D'Aprano wrote: > > Comprehensions already run partly in the surrounding scope. [...] > > Given the code shown: > > > > def test(): > > a = 1 > > b = 2

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 05:52:16PM +1000, Chris Angelico wrote: > def test(): > a = 1 > b = 2 > vars = {key: locals()[key] for key in locals()} > return vars > > What would your intuition say? Should this be equivalent to dict(locals()) ? That example is so elegant it makes me

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Tue, Jun 26, 2018 at 10:54:12AM +1200, Greg Ewing wrote: > A decision still needs to be made about whether we *want* > semantics that leak some things but not others. My sense (or bias, if you prefer) is that the answer to that depends on how you word the question. If you talk about

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Sat, Jun 30, 2018 at 06:30:56PM +1000, Nick Coghlan wrote: > The significant semantic differences between "{x : 1}" and "{x := 1}" > are also rather surprising :) *Significant* and obvious differences are good. It's the subtle differences that you don't notice immediately that really hurt:

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 09:52:43PM -0700, Chris Barker wrote: > It seems everyone agrees that scoping rules should be the same for > generator expressions and comprehensions, Yes. I dislike saying "comprehensions and generator expressions" over and over again, so I just say "comprehensions".

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 07:29:52PM -0500, Tim Peters wrote: [...] > For example, if the name is declared "global" in the outer scope, you'll > get a compile-time error if you try to declare it "nonlocal" in the > contained scope. "parentlocal" adjusts its meaning accordingly, becoming a > synonym

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

On Wed, Jun 27, 2018 at 03:31:42PM -0700, Guido van Rossum wrote: > I'd also like to keep the rule prohibiting use of the same name as a > comprehension loop control variable and as an inline assignment target; > this rule would also prohibit shenanigans with nested comprehensions (for > any set

Re: [Python-Dev] Drop/deprecate Tkinter?

On Thu, May 03, 2018 at 07:39:05AM +0200, Matěj Cepl wrote: > I have my doubts about IDLE though. I know, the same > argument applies, but really, does anybody use IDLE for > development for long time Yes, tons of beginners use it. On the tutor and python-list mailing lists, there are plenty

Re: [Python-Dev] Drop/deprecate Tkinter?

On Thu, May 03, 2018 at 12:01:53AM +0200, Antoine Pitrou wrote: > On Wed, 2 May 2018 22:54:04 +0100 > Paul Moore wrote: > > Nor do I think the tone of his message here is acceptable - regardless > > of how annoyed he is, posting insults ("no-one gives a damn") about > >

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 07:16:28PM +1200, Greg Ewing wrote: > Tim Peters wrote: > >As a statement in a program (as opposed to typed at a shell), > >"a := 3" has the unnecessary (in that context) property of returning > >(and discarding 3), so it's better style to use "a = 3" in that > >context. >

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote: > On 4/25/2018 8:20 PM, Chris Angelico wrote: > >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov > > wrote: > >>Just yesterday this snippet was used on python-dev to show how great the > >>new syntax is: > >> >

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Wed, Apr 25, 2018 at 10:14:11PM -0700, Łukasz Langa wrote: > So only use the Pascal one in expressions. But don't forget > parentheses, otherwise it will bind the thing you probably didn't want > anyway. Binding expressions are no worse than any other expression: sometimes you need to

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 05:22:58PM +1200, Greg Ewing wrote: > Łukasz Langa wrote: > >What was its own assignment before > >now is part of the logic test. This saves on vertical whitespace but makes > >parsing and understanding logic tests harder. > > Another way to say this is that expressions

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On Wed, Apr 25, 2018 at 09:36:31PM -0500, Ryan Gonzalez wrote: > > > I have to say I'm not overly thrilled with PEP 572...it's almost odd, > because if you asked me back when I first joined this list when I was 13, I > would've no doubt said *YES*. I have the opposite experience: I've warmed

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 08:48:12AM -0700, Łukasz Langa wrote: > > > On Apr 25, 2018, at 11:10 PM, Steven D'Aprano <st...@pearwood.info> wrote: > > Criticising binding- > > expressions for that reason, especially implying that we must always use > > parens, is

Re: [Python-Dev] Reserve ':=' for type-inferred variable initialization (was PEP 572)

Hi Fatty, and welcome! On Thu, Apr 26, 2018 at 08:00:55PM +0200, Fatty Morgan wrote: > The natural interpretation of 'name := expr' is a PEP 526 > type-annotated variable initialization 'name : T = expr' with the > type annotation T omitted, the tokens ':' and '=' coalesced, and > the implied

Re: [Python-Dev] Is PEP 572 really the most effective way to solve the problems it's targeting?

On Thu, Apr 26, 2018 at 09:36:48AM -0700, Mike Miller wrote: > However, there were two good questions in this message which I haven't seen > addressed yet: > > - How are other modern languages solving this issue? > - How does this new construct intersect with typing functionality? What

Re: [Python-Dev] (name := expression) doesn't fit the narrative of PEP 20

On Thu, Apr 26, 2018 at 08:00:46PM +0100, Zero Piraeus wrote: > Since it now looks like it really *does* have a decent chance, and > maybe another -1 has a small chance of tipping the balance: my > reaction to the proposal is also emotional. Visceral, in fact, to the > extent that I'd aim to read

Re: [Python-Dev] PEP 572: Assignment Expressions

On Mon, Apr 30, 2018 at 05:27:08PM -0700, Larry Hastings wrote: > > On 04/30/2018 07:30 AM, Mark Shannon wrote: > >Would Python be better with two subtly different assignment operators? > >The answer of "no" seems self evident to me. > > Maybe this has been covered in the thread earlier--if so,

Re: [Python-Dev] PEP 572: Assignment Expressions

On Tue, May 01, 2018 at 11:04:55AM +1000, Chris Angelico wrote: > To be fair, I don't see many people replacing "x = 1" with "for x in > [1]: pass". Even though it IS going to have the same effect. :-) Aside from the pass, that is precisely one of the current work-arounds for lack of

Re: [Python-Dev] PEP 572: A backward step in readability

On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote: [...] > A PEP that can detract from readability; *readability*, a central > tenet of Python, should > be rejected, (on principle!), when such objections are treated so > dismissively. Unless you have an objective measurement of

Re: [Python-Dev] Examples for PEP 572

On Tue, Jul 03, 2018 at 09:54:22PM -0400, Terry Reedy wrote: > >     results = [(x, y, x/y) for x in input_data for y in [f(x)] if y > 0] > > Would (f(x),) be faster? There is a deferred feature request to optimize "for x in [item]" as equivalent to "for x in (item,)", to avoid constructing a

[Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On Wed, Jul 04, 2018 at 11:13:20AM +1200, Greg Ewing wrote: > Terry Reedy wrote: > >If we had followed the math precedent, instead of >language>, we would have set builders, list builders, dict builders, and > >generator builders. > > I was intending to suggest something like that back when >

Re: [Python-Dev] [ssl] The weird case of IDNA

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 to not doing any IDNA handling at all. -- Steve

Re: [Python-Dev] Why wont duplicate methods be flagged as error (syntax or anything suitable error)

On Sun, Jan 14, 2018 at 11:10:33AM +0300, joannah nanjekye wrote: [...] > Is this sort of method name duplication important in any cases? Yes. For example, inside a class: class MyClass(object): @property def something(self): pass @something.setter def something(self):

Re: [Python-Dev] Friendly reminder: be kind to one another

On Tue, Jan 30, 2018 at 06:00:36PM +, Paul Moore wrote: > On 30 January 2018 at 17:10, Antoine Pitrou wrote: > > > > This is missing a bit of context. Is this about python-dev? Some > > other ML? > > While I'll admit to being curious about what prompted this, honestly,

Re: [Python-Dev] A minimal Python interpreter written in Python for experimenting with language changes

On Sat, Feb 03, 2018 at 12:50:11AM -0500, Terry Reedy wrote: > On 2/2/2018 7:01 PM, asrp asrp wrote: > >I don't know if this is the right place to post this. Please redirect as > >needed. > > This list is for development *of* cpython. Development *with* python in > general belongs on

Re: [Python-Dev] A minimal Python interpreter written in Python for experimenting with language changes

On Sat, Feb 03, 2018 at 01:01:30AM +0100, asrp asrp wrote: > I've made a small Python interpreter in Python with runtime AST node > semantics and edit-and-continue. I thought it could make prototyping > language changes more easily and visualize usage before writing them > in C. That sounds

Re: [Python-Dev] Is object the most base type? (bpo-20285)

On Fri, Feb 02, 2018 at 01:53:00AM -0500, Terry Reedy wrote: > >>> object.__doc__ > 'The most base type' [...] > I have suggested > "The superclass for all Python classes." > "The starting base class of all types and classes other than itself." > > I intended to pick the second, but Serhiy

Re: [Python-Dev] Why is Python for Windows compiled with MSVC?

On Wed, Jan 31, 2018 at 03:04:04PM +, Oleg Sivokon wrote: > Now, since Go won't compile with MSVC [...] Perhaps you should be asking Google why Go doesn't support the most popular C compiler on Windows. -- Steve ___ Python-Dev mailing list

Re: [Python-Dev] Immutability vs. hashability

On Sun, Feb 04, 2018 at 09:18:25PM -0800, Guido van Rossum wrote: > The way I think of it generally is that immutability is a property of > types, while hashability is a property of values. That's a great way to look at it, thanks. -- Steve ___

Re: [Python-Dev] A minimal Python interpreter written in Python for experimenting with language changes

On Sat, Feb 03, 2018 at 11:45:15AM +0100, asrp wrote: > > Can you give an example of how you would do that? I don't mean the > > mechanism used, I mean how would a developer implement a new syntactic > > feature. Suppose I wanted to add a new clause to for...else, let's say: > > > > for ...

Re: [Python-Dev] Immutability vs. hashability

On Mon, Feb 05, 2018 at 12:09:52AM -0600, Chris Barker wrote: > But a bit more detail -- I'm commenting on the API, not the capability - > that is, since users often equate hashable and immutability, they will > expect that if they say hash=True, then will get an immutable, and if they > say

Re: [Python-Dev] Dataclasses and correct hashability

On Mon, Feb 05, 2018 at 10:50:21AM -0800, David Mertz wrote: > Absolutely I agree. 'unsafe_hash' as a name is clear warning to users. (I don't mean to pick on David specifically, I had to reply to some message in this thread and I just picked his.) I'm rather gobsmacked at the attitudes of

Re: [Python-Dev] Dataclasses, frozen and __post_init__

On Mon, Feb 19, 2018 at 07:02:42PM -0800, Guido van Rossum wrote: > On Mon, Feb 19, 2018 at 5:06 PM, Chris Barker - NOAA Federal < > chris.bar...@noaa.gov> wrote: [...] > > This seems another use case — maybe it would be helpful to be able to > > freeze an instance after creation for multiple

Re: [Python-Dev] The `for y in [x]` idiom in comprehensions

On Fri, Feb 23, 2018 at 11:23:04AM -0800, Chris Barker wrote: > But I still think the original: > > [g(y) for x in range(5) for y in [f(x)]] > > Is always going to be confusing to read. Though I do agree that it's not > too bad when you unpack it into for loops: > > In [89]: for x in range(5):

Re: [Python-Dev] Guarantee ordered dict literals in v3.7?

On Wed, Dec 20, 2017 at 03:23:16PM -0800, Chris Barker wrote: > On Wed, Dec 20, 2017 at 2:31 AM, Steven D'Aprano <st...@pearwood.info> > wrote: > > Even when it works, the guarantee is quite weak. For instance, even > > the object type is not preserved: >

Re: [Python-Dev] [ssl] The weird case of IDNA

On Sun, Dec 31, 2017 at 05:51:47PM -0800, Nathaniel Smith wrote: > On Sun, Dec 31, 2017 at 5:39 PM, Steven D'Aprano <st...@pearwood.info> wrote: > > On Sun, Dec 31, 2017 at 09:07:01AM -0800, Nathaniel Smith wrote: > > > >> This is another reason why we ought to let us

Re: [Python-Dev] About [].append == [].append

On Thu, Jun 21, 2018 at 02:33:27PM +0300, Ivan Pozdeev via Python-Dev wrote: > First, tell us what problem you're solving. You might not be aware of the context of Jereon's question. He is the author of PEP 579 and 580, so I expect he's looking into implementation details of the CPython

Re: [Python-Dev] Python REPL doesn't work on Windows over remote powershell session (winrm)

On Sat, Aug 25, 2018 at 11:09:10PM +, ZHU Xiang wrote: > But for the remote Windows powershell session the REPL doesn’t work, > when I type ‘’python” on the remote session, there’s nothing happened. [...] > FYI, I’ve also opened a issue on Microsoft Powershell GitHub : >

Re: [Python-Dev] Issue?

On Wed, Aug 22, 2018 at 06:40:42PM +0800, 楼晓峰 wrote: > Why compare twice? This is not a mailing list for asking for help with your own code. You can try this list instead: https://mail.python.org/mailman/listinfo/python-list -- Steve ___

Re: [Python-Dev] PEP 572 and assert

On Tue, Jul 17, 2018 at 07:24:12PM +0300, Serhiy Storchaka wrote: > 17.07.18 18:48, Guido van Rossum пише: > >On Tue, Jul 17, 2018 at 8:28 AM, Serhiy Storchaka >> wrote: > >Should not the assert statement introduce an implicit lexical scope > >for preventing

Re: [Python-Dev] PEP 572 and assert

On Wed, Jul 18, 2018 at 03:41:08AM +1000, Steven D'Aprano wrote: > Besides, there is a legitimate use for assignment expressions in > assertions: > > assert (spam := something) > 2, 'not enough spam' > assert sequence[foo] == 999, 'sequence item isn't 999' Ah, o

Re: [Python-Dev] Official citation for Python

On Sun, Sep 09, 2018 at 03:43:13PM -0400, Jacqueline Kazil wrote: > The PSF has received a few inquiries asking the question — “How do I cite > Python?”So, I am reaching out to you all to figure this out. If you figure it out, it would be lovely to see some movement on this ticket:

Re: [Python-Dev] Official citation for Python

On Mon, Sep 10, 2018 at 09:25:29PM +0200, Chris Barker via Python-Dev wrote: > I"d like ot know what thee citations are expected to be used for? > > i.e. -- usually, academic papers have a collection of citiations to > acknowledge where you got an idea, or fact, or It serves both to >

Re: [Python-Dev] Official citation for Python

On Tue, Sep 11, 2018 at 11:16:08AM +0200, Chris Barker wrote: > On Tue, Sep 11, 2018 at 3:48 AM, Steven D'Aprano > wrote: > > > > That is about reproducible results, which is really a different thing > > than > > > the usual citations. > > > >

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 01:00:41PM -0700, Devin Jeanpierre wrote: > On Wed, Jul 4, 2018 at 11:04 AM Steven D'Aprano wrote: > > Did you actually mean arbitrary simple statements? > > > > if import math; mylist.sort(); print("WTF am I reading?"); True: > >

Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"

On Thu, Jul 05, 2018 at 05:33:50AM +0300, Ivan Pozdeev via Python-Dev wrote: > And https://mail.python.org/pipermail/python-dev/2018-June/154160.html > disproves the "chosen often these days in new languages". Ivan, I think you may have linked to the wrong page. That page was Chris kindly

Re: [Python-Dev] Assignment expression and coding style: the while True case

On Thu, Jul 05, 2018 at 12:51:37AM +0200, Victor Stinner wrote: > I propose to start the discussion about "coding style" (where are > assignment expressions appropriate or not?) with the "while True" > case. We don't even have an official implementation yet, and you already want to start

Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"

On Wed, Jul 04, 2018 at 04:52:54PM -0700, Mike Miller wrote: > Additionally, I have noticed a dichotomy between prolific "C programmers" > who've supported this PEP and many Python programmers who don't want it. Prolific C programmers like me, hey? *shakes head in a combination of amusement

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Wed, Jul 04, 2018 at 03:21:29PM +0400, Abdur-Rahmaan Janhangeer wrote: > was going to tell > > instead of := maybe => better > > := too close to other langs The fact that := will be familiar to many people (especially if they know Go, Pascal or Eiffel etc) is a point in its favour.

Re: [Python-Dev] Examples for PEP 572

On Tue, Jul 03, 2018 at 03:24:09PM -0700, Chris Barker via Python-Dev wrote: > Over the years I've been using it (most of its life), Python has evolved to > become much less of a "scripting" language, and much more of a "systems" > language, and this addition is a (pretty significant) step more

Re: [Python-Dev] PEP 572, VF/B, and "Shark Jumping"

On Thu, Jul 05, 2018 at 08:52:24PM +0300, Ivan Pozdeev via Python-Dev wrote: > * Same goes for `except`: doesn't accept expressions, same semantic. py> def make_exception(arg): ... return ValueError if arg else TypeError ... py> expr = [make_exception] py> try: ... 1+"1" ... except

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

On Thu, Jul 05, 2018 at 09:00:39PM -0400, Alexander Belopolsky wrote: > Do we want to protect users who > cannot tell = from == so much that we are willing to cause Python to be > the first language with two non-interchangeable assignment operators? Not even close to the first. Go beat us to it

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

On Wed, Jul 11, 2018 at 05:14:34AM +0300, Ivan Pozdeev via Python-Dev wrote: > On 11.07.2018 1:41, Victor Stinner wrote: > >2018-07-09 18:01 GMT+02:00 Steve Dower : > >>The difficulty is that they *definitely* can use the 32-bit version, and > >>those few who are on older machines or older

Re: [Python-Dev] Symmetric vs asymmetric symbols (was PEP 572: Do we really need a ":" in ":="?)

On Sat, Jul 07, 2018 at 01:03:06PM +1200, Greg Ewing wrote: > Ivan Pozdeev via Python-Dev wrote: > >(while "<>" reads "less or greater" which is mathematically not > >equivalent to that: not everything has a defined ordering relation. > > I think this is a silly argument against "<>". While I

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

On Sat, Jul 07, 2018 at 02:58:23AM +0300, Ivan Pozdeev via Python-Dev wrote: > >Also, "generator builder" is not much more expressive than "generator > >expression", I agree with Guido on that comment. The only advantage (such little as it is) is that we can refer to them all using the same

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 12:10:11AM -0700, Nathaniel Smith wrote: > Right, Python has a *very strong* convention that each line should > have at most one side-effect, import math, fractions, decimal (PEP 8 be damned, sometimes, especially in the REPL, this is much better than three separate

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 01:03:02AM -0700, Devin Jeanpierre wrote: > The PEP doesn't talk about it, but FWIW, Go and C++17 if statements > allow you to put arbitrary simple statements in the suite header, and > by doing that, solves all the issues you and the PEP mentioned. Whether they solve

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 10:20:35AM -0400, David Mertz wrote: > Hmmm... I admit I didn't expect quite this behavior. I'm don't actually > understand why it's doing what it does. > > >>> def myfun(): > ...print(globals().update({'foo', 43}), foo) Try it with a dict {'foo': 43} instead of a set

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 05:02:07PM +1000, Chris Angelico wrote: > On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka wrote: > "Assignment is a statement" -- that's exactly the point under discussion. Not any more it isn't. We've now gone from discussion to bitter recriminations *wink* > "del

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 10:13:15AM -0700, Devin Jeanpierre wrote: > > > In Python it'd look like this: > > > > > > if x = expr(); x < 0: > > > do_stuff() [...] > > Python's parser is restricted to LL(1) by design, so treating semicolons > > in "if" statements as a special case might not even

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 08:33:17PM +0300, Ivan Pozdeev via Python-Dev wrote: > >>while total != (total := total + term): > >>    term *= mx2 / (i*(i+1)) > >>    i += 2 > >>return total [...] > It took me a few minutes to figure out that this construct actually > checks term == 0. That's badly

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 08:32:32PM +0200, Sven R. Kunze wrote: > >>while total != (total := total + term): > >>    term *= mx2 / (i*(i+1)) > >>    i += 2 > >>return total > > This very example here caught my eye. > > Isn't total not always equal to total? What would "regular" Python have >

Re: [Python-Dev] Examples for PEP 572

On Wed, Jul 04, 2018 at 03:24:08PM -0400, Terry Reedy wrote: > On 7/4/2018 9:35 AM, Steven D'Aprano wrote: > >On Wed, Jul 04, 2018 at 05:02:07PM +1000, Chris Angelico wrote: > >>On Wed, Jul 4, 2018 at 4:07 PM, Serhiy Storchaka > >>wrote: > > > >>&qu

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow

On Wed, Jul 04, 2018 at 03:36:18PM +0300, Ivan Pozdeev via Python-Dev wrote: > On 04.07.2018 15:29, Victor Stinner wrote: > >The PEP 572 has been approved, it's no longer worth it to discuss it ;-) > > > >Victor > > As of now, https://www.python.org/dev/peps/pep-0572/ is marked as "draft".

Re: [Python-Dev] Deprecate PEP 370 Per user site-packages directory?

On Sat, Jan 13, 2018 at 09:00:07PM +0100, Christian Heimes wrote: > You'd be surprised how many tools and programs are using Python these > days. You can easily break important user programs by installing a > package with --user. Or by writing a Python script and innocently giving it the same

Re: [Python-Dev] Python 3.7: Require OpenSSL >=1.0.2 / LibreSSL >= 2.5.3

On Sat, Jan 13, 2018 at 02:23:19PM +0100, Antoine Pitrou wrote: > On Sat, 13 Jan 2018 13:54:33 +0100 > Christian Heimes wrote: > > > > If we agree to drop support for OpenSSL 0.9.8 and 1.0.1, then I can land > > bunch of useful goodies like proper hostname verification [2],

<    6   7   8   9   10   11   12   13   14   15   >