[Python-ideas] Re: [Python-Dev] Have virtual environments led to neglect of the actual environment?

FWIW, Distro repacks are advantageous in comparison to "statically-bundled" releases that for example bundle in an outdated version of OpenSSL, because when you `apt-get upgrade -y` that should upgrade the OpenSSL that all the other distro packages depend upon. Here's something that doesn't get ca

[Python-ideas] Re: [Python-Dev] Have virtual environments led to neglect of the actual environment?

On 2/23/21, Random832 wrote: > I was reading a discussion thread > about > various issues with the Debian packaged version of Python, and the following > statement stood out for me as shocking: > > Christian Heimes wrote: >> Core dev

[Python-ideas] Re: Have virtual environments led to neglect of the actual environment?

On 2021-02-23 9:45 p.m., Random832 wrote: I was reading a discussion thread about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: >

[Python-ideas] Re: [Python-Dev] Have virtual environments led to neglect of the actual environment?

On Tue, Feb 23, 2021 at 7:48 PM Random832 wrote: > > I was reading a discussion thread > about > various issues with the Debian packaged version of Python, and the following > statement stood out for me as shocking: > > Christian

[Python-ideas] Re: Have virtual environments led to neglect of the actual environment?

I think it's a classic case of dependency hell. OS packagers are rebundling Python packages as OS packages and expressing their own OS-package dependency graphs. Then, you sudo pip install something that has a conflicting dependency, it bypasses OS packaging, and *boom*. I find tools like pipx go

[Python-ideas] Have virtual environments led to neglect of the actual environment?

I was reading a discussion thread about various issues with the Debian packaged version of Python, and the following statement stood out for me as shocking: Christian Heimes wrote: > Core dev and PyPA has spent a lot of effort in

[Python-ideas] Re: Alternate lambda syntax

On Fri, Feb 19, 2021 at 07:35:19PM +0300, Paul Sokolovsky wrote: > People won't learn "two syntaxes for Callable". People shun using > Python's current type annotations due to their ugliness and "quick hack > without thinking of UX" feel. Only after there will be "int | str" > instead of "Union[in

[Python-ideas] Re: Arrow functions polyfill

On 2/23/21 5:01 PM, Rob Cliffe via Python-ideas wrote: > > > On 23/02/2021 17:46, Stéfane Fermigier wrote: >> >> >> On Tue, Feb 23, 2021 at 6:13 PM Richard Damon >> mailto:rich...@damon-family.org>> wrote: >> >> >> Also note, that I am not saying that 'arrow-functions' can't happen, >> just

[Python-ideas] Re: Arrow functions polyfill

On 23/02/2021 17:46, Stéfane Fermigier wrote: On Tue, Feb 23, 2021 at 6:13 PM Richard Damon mailto:rich...@damon-family.org>> wrote: Also note, that I am not saying that 'arrow-functions' can't happen, just that if they are created, a natural consequence is that, like with

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

On 2021-02-23 7:10 p.m., Steven D'Aprano wrote: On Tue, Feb 23, 2021 at 01:57:08PM -0300, Soni L. wrote: > What about getting the parser to recognize ^~ as an XNOR operator and > have __xnor__ on bools actually do xnor on bools? Make xnor a real > operator by fusing two operators together!

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

On Tue, Feb 23, 2021 at 01:57:08PM -0300, Soni L. wrote: > 64-bit bools were a mistake, tbh. Oh well, at least we tried. What language are you talking about? In Python, bool is a subclass of int, which is a BigNum, not 64 bits. >>> False.bit_length() 0 >>> (~False).bit_length() 1 > What about

[Python-ideas] Re: Alternate lambda syntax

I was +0.5 on the arrow syntax for `Callable`. It seemed like a nice short hand but understood the arguments against it in the vain of "There should be one-- and preferably only one --obvious way to do it." But > The latter is the same as the former, just in the AST form. That's what > we ask p

[Python-ideas] Re: Arrow functions polyfill

> On 23 Feb 2021, at 21:42, Barry wrote: > >  > > >>> On 23 Feb 2021, at 18:08, Stéfane Fermigier wrote: >>> >>  >> Both '%' and .format() support both positional and named arguments. >> >> There are probably a few use cases for .format() (vs. f-strings) but overall >> I don't believe t

[Python-ideas] Re: Arrow functions polyfill

> On 23 Feb 2021, at 18:08, Stéfane Fermigier wrote: > >  > Both '%' and .format() support both positional and named arguments. > > There are probably a few use cases for .format() (vs. f-strings) but overall > I don't believe there is much reasons left to prefer %. I18n you can translate a

[Python-ideas] Multi-line lambda as last argument

Hello, Multi-line lambda is element of many languages, but they are not needed in the form in which they are made in many languages. А good use would be to use the lambda as the last argument of the function. Syntax: > def func(lambda1): > lambda1() > > func(): > print(1) > Can be used fo

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

Hello, On Tue, 23 Feb 2021 13:09:39 -0500 Ned Batchelder wrote: > On 2/23/21 12:55 PM, Paul Sokolovsky wrote: > > Hello, > > > > On Tue, 23 Feb 2021 11:52:57 -0500 > > Ned Batchelder wrote: > > > >> On 2/23/21 12:56 AM, Paul Sokolovsky wrote: > >>> Hello, > >>> > >>> On Mon, 22 Feb 2021 17:

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

Hello, On Wed, 24 Feb 2021 05:01:37 +1100 Chris Angelico wrote: > On Wed, Feb 24, 2021 at 4:59 AM Paul Sokolovsky > wrote: > > Without getting to the root cause, there will be only workarounds of > > different level of ugliness. For example, any reasonable JIT would > > implement proper semanti

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

On 2/23/21 12:55 PM, Paul Sokolovsky wrote: Hello, On Tue, 23 Feb 2021 11:52:57 -0500 Ned Batchelder wrote: On 2/23/21 12:56 AM, Paul Sokolovsky wrote: Hello, On Mon, 22 Feb 2021 17:32:23 -0500 Ned Batchelder wrote: On 2/22/21 3:06 PM, Paul Sokolovsky wrote: No, I'm proposing to stop

[Python-ideas] Re: Arrow functions polyfill

Both '%' and .format() support both positional and named arguments. There are probably a few use cases for .format() (vs. f-strings) but overall I don't believe there is much reasons left to prefer %. Note that the existence, and popularity, of tools like flynt and pyupgrade (that convert % and .

[Python-ideas] Re: Arrow functions polyfill

Hello, On Tue, 23 Feb 2021 12:11:00 -0500 Richard Damon wrote: [] > them. If we look at 'f-strings' as the example, I beleive f-strings > are now considered the 'preferred obvious' way to do it, when it is It's a common mistake. %-formatting was "preferred obvious" 30 years ago, and is "prefer

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

On Wed, Feb 24, 2021 at 4:59 AM Paul Sokolovsky wrote: > Without getting to the root cause, there will be only workarounds of > different level of ugliness. For example, any reasonable JIT would > implement proper semantics - param checking *inside* functions (just > like the C code does now). Wh

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

Hello, On Tue, 23 Feb 2021 11:52:57 -0500 Ned Batchelder wrote: > On 2/23/21 12:56 AM, Paul Sokolovsky wrote: > > Hello, > > > > On Mon, 22 Feb 2021 17:32:23 -0500 > > Ned Batchelder wrote: > > > >> On 2/22/21 3:06 PM, Paul Sokolovsky wrote: > >>> No, I'm proposing to stop faking lack of th

[Python-ideas] Re: Arrow functions polyfill

On Tue, Feb 23, 2021 at 6:13 PM Richard Damon wrote: > > Also note, that I am not saying that 'arrow-functions' can't happen, > just that if they are created, a natural consequence is that, like with > .format(), the 'old' (lambda) way will need to be marked as 'old', and > not the current obviou

[Python-ideas] Re: Arrow functions polyfill

On Wed, Feb 24, 2021 at 4:13 AM Richard Damon wrote: > As far as between % or .format(), I think the documentation is fairly > clear that the % method is 'old' and if not 'formally' deprecated, is no > longer considered the 'obvious' way to do it (even if some people will > still do it that way fo

[Python-ideas] Re: Arrow functions polyfill

On 2/23/21 10:07 AM, Paul Sokolovsky wrote: > Hello, > > On Tue, 23 Feb 2021 09:35:58 -0500 > Richard Damon wrote: > > [] > >> My first thought to the idea of making an alternate syntax is the line >> from the Zen: >> >> There should be one-- and preferably only one --obvious way to do it. >> Alth

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

64-bit bools were a mistake, tbh. Oh well, at least we tried. What about getting the parser to recognize ^~ as an XNOR operator and have __xnor__ on bools actually do xnor on bools? Make xnor a real operator by fusing two operators together! On 2021-02-23 5:49 a.m., Steven D'Aprano wrote: On

[Python-ideas] Re: [Python-Dev] Re: Inadequate error reporting during function call setup stage

On 2/23/21 12:56 AM, Paul Sokolovsky wrote: Hello, On Mon, 22 Feb 2021 17:32:23 -0500 Ned Batchelder wrote: On 2/22/21 3:06 PM, Paul Sokolovsky wrote: No, I'm proposing to stop faking lack of the last stack frame due to CPython's implementation details. See the original message for more info

[Python-ideas] Re: Arrow functions polyfill

On Tue, 23 Feb 2021 at 15:52, M.-A. Lemburg wrote: > > On 23.02.2021 15:29, Paul Moore wrote: > > On Tue, 23 Feb 2021 at 14:10, M.-A. Lemburg wrote: > >> > >> The natural way in Python to write an anonymous function would > >> be to simply drop the name in a regular function definition: > >> > >>

[Python-ideas] Re: Arrow functions polyfill

On 23.02.2021 15:29, Paul Moore wrote: > On Tue, 23 Feb 2021 at 14:10, M.-A. Lemburg wrote: >> >> The natural way in Python to write an anonymous function would >> be to simply drop the name in a regular function definition: >> >> def (a): return a**2 >> >> The lambda notation is less verbose and

[Python-ideas] Re: Arrow functions polyfill

Hello, On Tue, 23 Feb 2021 09:35:58 -0500 Richard Damon wrote: [] > My first thought to the idea of making an alternate syntax is the line > from the Zen: > > There should be one-- and preferably only one --obvious way to do it. > Although that way may not be obvious at first unless you're Dut

[Python-ideas] Re: Arrow functions polyfill

On 2/23/21 7:57 AM, Paul Sokolovsky wrote: > Hello, > > On Tue, 23 Feb 2021 23:29:33 +1100 > Steven D'Aprano wrote: > >> On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote: >> >>> Also: I know there are several modern computer languages that use >>> arrows to represent anonymous fun

[Python-ideas] Re: Arrow functions polyfill

On Tue, 23 Feb 2021 at 14:10, M.-A. Lemburg wrote: > > The natural way in Python to write an anonymous function would > be to simply drop the name in a regular function definition: > > def (a): return a**2 > > The lambda notation is less verbose and closer to computer > science theory, though: > >

[Python-ideas] Re: Arrow functions polyfill

Hello, On Tue, 23 Feb 2021 15:07:50 +0100 "M.-A. Lemburg" wrote: [] > FWIW: I don't understand why people are so unhappy with lambdas. I don't think that people are unhappy with lambdas. I think that people are *so* happy with lambdas, that want even shorter notation for them. > There isn't

[Python-ideas] Re: Arrow functions polyfill

The natural way in Python to write an anonymous function would be to simply drop the name in a regular function definition: def (a): return a**2 The lambda notation is less verbose and closer to computer science theory, though: lambda a: a**2 FWIW: I don't understand why people are so unhappy w

[Python-ideas] Re: Arrow functions polyfill

Hello, On Tue, 23 Feb 2021 13:24:10 + Stestagg wrote: > I was quite feeling pretty positive about the 'stab' (thanks Steve > for this term!) operator idea, until I tried out some examples > locally, and it just feels a bit too out-of-place in python, for me > (100% subjective opinion here).

[Python-ideas] Re: Arrow functions polyfill

On Tue, Feb 23, 2021 at 1:34 PM Steven D'Aprano wrote: > On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote: > > > Also: I know there are several modern computer languages that use arrows > to > > represent anonymous functions (JS, Kotlin, Scala...). > > Javascript: first release w

[Python-ideas] Re: Arrow functions polyfill

I was quite feeling pretty positive about the 'stab' (thanks Steve for this term!) operator idea, until I tried out some examples locally, and it just feels a bit too out-of-place in python, for me (100% subjective opinion here). Having used stabs and compact closure syntax in various languages: s

[Python-ideas] Re: Arrow functions polyfill

Hello, On Tue, 23 Feb 2021 23:29:33 +1100 Steven D'Aprano wrote: > On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote: > > > Also: I know there are several modern computer languages that use > > arrows to represent anonymous functions (JS, Kotlin, Scala...). > > Javascript: fi

[Python-ideas] Re: Arrow functions polyfill

On Tue, Feb 23, 2021 at 11:27:12AM +0100, Stéfane Fermigier wrote: > Also: I know there are several modern computer languages that use arrows to > represent anonymous functions (JS, Kotlin, Scala...). Javascript: first release was 1995, making it 25 years old. It's older than most Javascript pro

[Python-ideas] Re: Arrow functions polyfill

Also: I know there are several modern computer languages that use arrows to represent anonymous functions (JS, Kotlin, Scala...). I also personally remember using (and teaching) Maple in the mid-90s, which used arrows to define functions: https://www.maplesoft.com/support/help/Maple/view.aspx?pat

[Python-ideas] Re: Arrow functions polyfill

On Tue, 23 Feb 2021 at 09:25, Steven D'Aprano wrote: > > On Mon, Feb 15, 2021 at 09:29:45AM -0800, Guido van Rossum wrote: > > > Proposals like this always baffle me. Python already has both anonymous and > > named functions. They are spelled with 'lambda' and 'def', respectively. > > What good wo

[Python-ideas] Re: Arrow functions polyfill

Hi, My personal opinion is that arrows or even fat arrows would be a nice addition to the Python language for anonymous functions. I cringe a bit every time I have to write "lambda x: ..." (and even more for parameter-less "lambda: ..."). I have a background in math so I find arrow notation very

[Python-ideas] Re: Arrow functions polyfill

On Mon, Feb 15, 2021 at 09:29:45AM -0800, Guido van Rossum wrote: > Proposals like this always baffle me. Python already has both anonymous and > named functions. They are spelled with 'lambda' and 'def', respectively. > What good would it do us to create an alternate spelling for 'def'? [...] I

[Python-ideas] Re: Deprecate/change the behaviour of ~bool

On Mon, Feb 22, 2021 at 10:11:14PM -0300, Soni L. wrote: > Currently ~False is -1 and ~True is -2. Would be nicer if ~bool was the > same as not bool. That's your opinion. I disagree. Bitwise-not is not the same thing as boolean-not, and they should not be spelled the same, especially not when