Re: IDLE editor suggestion.

down arrow key. -Original Message- From: Friedrich Romstedt Sent: Tuesday, December 12, 2023 12:52 PM To: Steve GS Cc: python-list@python.org Subject: Re: IDLE editor suggestion. Hi! Am Di., 12. Dez. 2023 um 09:28 Uhr schrieb Steve GS via Python-list : Maybe this already exists

RE: IDLE editor suggestion.

Subject: Re: IDLE editor suggestion. Hi! Am Di., 12. Dez. 2023 um 09:28 Uhr schrieb Steve GS via Python-list : > > Maybe this already exists but > I have never seen it in any > editor that I have used. You might want to choose Microsoft Code from its Visual Studio family of soft

Re: IDLE editor suggestion.

On 12/12/23 13:50, Thomas Passin via Python-list wrote: On 2023-12-12 08:22, Steve GS via Python-list wrote: > Maybe this already exists but > I have never seen it in any > editor that I have used. > > It would be nice to have a > pull-down text box that lists > all of the searches I have

Re: IDLE editor suggestion.

On 2023-12-12 08:22, Steve GS via Python-list wrote: > Maybe this already exists but > I have never seen it in any > editor that I have used. > > It would be nice to have a > pull-down text box that lists > all of the searches I have > used during this session. It > would make editing a lot > easi

Re: IDLE editor suggestion.

Hi! Am Di., 12. Dez. 2023 um 09:28 Uhr schrieb Steve GS via Python-list : > > Maybe this already exists but > I have never seen it in any > editor that I have used. You might want to choose Microsoft Code from its Visual Studio family of software, or, if you're ready for a deep dive, you might tr

Re: IDLE editor suggestion.

On 2023-12-12 08:22, Steve GS via Python-list wrote: Maybe this already exists but I have never seen it in any editor that I have used. It would be nice to have a pull-down text box that lists all of the searches I have used during this session. It would make editing a lot easier if I could sele

IDLE editor suggestion.

Maybe this already exists but I have never seen it in any editor that I have used. It would be nice to have a pull-down text box that lists all of the searches I have used during this session. It would make editing a lot easier if I could select the previous searches rather than having to enter it

Re: Suggestion: Regex string specifier like r and f

> On 8 Jan 2023, at 21:16, Raphael Santiago > wrote: > > Maybe something like re"" > It should behave exactly like a raw string but would be useful for syntax > highlighting and debugging. Perhaps also for type hinting expected regex > input (don't know if this is feasible). This is unlikely

Re: Suggestion: Regex string specifier like r and f

On 08Jan2023 12:44, Raphael Santiago wrote: Maybe something like re"" It should behave exactly like a raw string but would be useful for syntax highlighting and debugging. Perhaps also for type hinting expected regex input (don't know if this is feasible). A nice idea. (Though I'm personally r

Suggestion: Regex string specifier like r and f

Maybe something like re"" It should behave exactly like a raw string but would be useful for syntax highlighting and debugging. Perhaps also for type hinting expected regex input (don't know if this is feasible). -- https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion. Replace Any with *

On Tue, 14 Jun 2022 at 01:59, h3ck phy wrote: > > It would be nice if we could write something like this > data: dict[str, *] = {} > instead of > data: dict[str, Any] = {} > > In import statement asterisk means "all names" in a module. > But in type closure it should mean "all types". Type hints

Suggestion. Replace Any with *

It would be nice if we could write something like this data: dict[str, *] = {} instead of data: dict[str, Any] = {} In import statement asterisk means "all names" in a module. But in type closure it should mean "all types". -- https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Sat, 16 Apr 2022 at 17:14, Peter J. Holzer wrote: > > On 2022-04-16 16:49:17 +0200, Marco Sulla wrote: > > Furthermore, you didn't answer my simple question: why does the > > security update package contain metadata about Debian patches, if the > > Ubuntu security team did not benefit from Debi

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 2022-04-16 16:49:17 +0200, Marco Sulla wrote: > Furthermore, you didn't answer my simple question: why does the > security update package contain metadata about Debian patches, if the > Ubuntu security team did not benefit from Debian security patches but > only from internal work? It DOES NOT

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Sat, 16 Apr 2022 at 10:15, Peter J. Holzer wrote: > It doesn't (or at least you can't conclude that from the evidence you > posted). > > There is a subdirectory called "debian" in the build directory of every > .deb package. This is true on Debian, Ubuntu and every other > distribution which us

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 2022-04-14 19:31:58 +0200, Marco Sulla wrote: > On Wed, 13 Apr 2022 at 20:05, Peter J. Holzer wrote: > > > > On 2022-04-12 21:03:00 +0200, Marco Sulla wrote: > > > On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote: > > > > They are are about a year apart, so they will usually contain > > > >

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Wed, 13 Apr 2022 at 20:05, Peter J. Holzer wrote: > > On 2022-04-12 21:03:00 +0200, Marco Sulla wrote: > > On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote: > > > They are are about a year apart, so they will usually contain different > > > versions of most packages right from the start. So

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 2022-04-12 21:03:00 +0200, Marco Sulla wrote: > On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote: > > They are are about a year apart, so they will usually contain different > > versions of most packages right from the start. So the Ubuntu and Debian > > security teams probably can't benefit

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote: > They are are about a year apart, so they will usually contain different > versions of most packages right from the start. So the Ubuntu and Debian > security teams probably can't benefit much from each other. Well, this is what my updater on

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Thu, 31 Mar 2022 at 18:38, Cecil Westerhof via Python-list wrote: > Most people think that > Ubuntu is that also, because it is based on Debian. But Ubuntu wants > also provide the newest versions of software and this will affect the > stability and security negatively. I think you're referrin

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 2022-03-31 09:46:14 +0200, Cecil Westerhof via Python-list wrote: > "Peter J. Holzer" writes: > > Standard policy (there are exceptions) on most distros is to stay with > > the same version of any package for the entire lifetime. So for example, > > Ubuntu 20.04 was released with Apache 2.4.41

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

"Peter J. Holzer" writes: > On 2022-03-30 08:48:36 +0200, Marco Sulla wrote: >> On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote: >> > They are are about a year apart, so they will usually contain different >> > versions of most packages right from the start. So the Ubuntu and Debian >> > sec

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

"Peter J. Holzer" writes: > On 2022-03-28 15:35:07 +0200, Cecil Westerhof via Python-list wrote: >> "Loris Bennett" writes: >> > Ubuntu is presumably relying on the Debian security team as well as >> > other volunteers and at least one company, namely Canonical. >> >> Nope. One important reason

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 2022-03-30 08:48:36 +0200, Marco Sulla wrote: > On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote: > > They are are about a year apart, so they will usually contain different > > versions of most packages right from the start. So the Ubuntu and Debian > > security teams probably can't benefit

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Tue, 29 Mar 2022 at 00:10, Peter J. Holzer wrote: > They are are about a year apart, so they will usually contain different > versions of most packages right from the start. So the Ubuntu and Debian > security teams probably can't benefit much from each other. Are you sure? Since LTS of Debian

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 2022-03-28 15:35:07 +0200, Cecil Westerhof via Python-list wrote: > "Loris Bennett" writes: > > Ubuntu is presumably relying on the Debian security team as well as > > other volunteers and at least one company, namely Canonical. > > Nope. One important reason that I really hate that people use

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

"Loris Bennett" writes: > Marco Sulla writes: > >> On Fri, 11 Mar 2022 at 19:10, Michael Torrie wrote: >>> Both Debian stable and Ubuntu LTS state they have a five year support >>> life cycle. >> >> Yes, but it seems that official security support in Debian ends after >> three years: >> >> "Deb

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

Dear Loris, "Loris Bennett" writes: > (...thanks...) > The sysadmins I know who are interested in long-term stability and > avoiding unnecessary OS updates use Debian rather than Ubuntu, +1; Reasonable! Sincerely, Linux fan Byung-Hee -- ^고맙습니다 _地平天成_ 감사합니다_^))// -- https://mail.python.org/m

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Mon, 14 Mar 2022 at 18:33, Loris Bennett wrote: > I am not sure how different the two situations are. Ubuntu is > presumably relying on the Debian security team as well as other > volunteers and at least one company, namely Canonical. So do you think that Canonical contributes to the LTS secu

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

Marco Sulla writes: > On Fri, 11 Mar 2022 at 19:10, Michael Torrie wrote: >> Both Debian stable and Ubuntu LTS state they have a five year support >> life cycle. > > Yes, but it seems that official security support in Debian ends after > three years: > > "Debian LTS is not handled by the Debian

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

Cousin Stanley wrote: >> apt-cache search lxqt | grep ^lxqt Chris Angelico wrote: > Much faster: > > apt-cache pkgnames lxqt > > apt-cache search will look for "lxqt" in descriptions too, > hence the need to filter those out > > apt-cache pkgnames is used by tab completion) > Thanks

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Fri, 11 Mar 2022 at 19:10, Michael Torrie wrote: > Both Debian stable and Ubuntu LTS state they have a five year support > life cycle. Yes, but it seems that official security support in Debian ends after three years: "Debian LTS is not handled by the Debian security team, but by a separate g

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 3/11/22 11:03, Marco Sulla wrote: > Anyway I think I'll not install Debian, because it's LTS releases are > not long enough for me. I don't know if there's a distro based on > Debian that has a long LTS support, Ubuntu apart. Both Debian stable and Ubuntu LTS state they have a five year support

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Fri, 11 Mar 2022 at 06:38, Dan Stromberg wrote: > That's an attribute of your desktop environment, not the Linux distribution. > > EG: I'm using Debian with Cinnamon, which does support ctrl-alt-t. Never used Cinnamon. It comes from Mint, right? > Some folks say the desktop environment matter

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

repository and available to install > > > > > > apt-cache search lxqt | grep ^lxqt > > > > > Much faster: > > > > apt-cache pkgnames lxqt > > > > (apt-cache search will look for "lxqt" in descriptions too, hence the > > need to fi

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

-cache pkgnames lxqt (apt-cache search will look for "lxqt" in descriptions too, hence the need to filter those out - apt-cache pkgnames is used by tab completion) Cousing Stanley's suggestion has the advantage that it also prints the short descriptions instead of just the package

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Fri, 11 Mar 2022 at 16:39, Dan Stromberg wrote: > Some folks say the desktop environment matters more than the distribution, > when choosing what OS to install. Matters more to the choice? Impossible to say. Matters more to the UI? Without a doubt. ChrisA -- https://mail.python.org/mailman/

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Thu, Mar 10, 2022 at 5:04 AM Marco Sulla wrote: > On Thu, 10 Mar 2022 at 04:50, Michael Torrie wrote: > > > > On 3/9/22 13:05, Marco Sulla wrote: > > > So my laziness pays. I use only LTS distros, and I update only when > > > there are security updates. > > > PS: any suggestions for a new LTS

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Fri, 11 Mar 2022 at 09:51, Cousin Stanley wrote: > > Marco Sulla wrote: > > >> > >> Maybe Debian itself? > > > > I tried Debian on a VM, but I found it too much basical. A little > > example: it does not have the shortcut ctrl+alt+t to open a terminal > > that Ubuntu has. I'm quite sure it's si

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

Marco Sulla wrote: >> >> Maybe Debian itself? > > I tried Debian on a VM, but I found it too much basical. A little > example: it does not have the shortcut ctrl+alt+t to open a terminal > that Ubuntu has. I'm quite sure it's simple to add, but I'm starting > to be old and lazy... > I use the

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 3/10/22 12:42, Marco Sulla wrote: > PS: Is it just my impression or is there a plebiscite for Debian? A vote? No I don't think so. Not sure what you mean. The reason we're all suggesting Debian is because you specifically said you want a LTS Debian-like distro. Can't get any more Debian-like

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Thu, 10 Mar 2022 at 14:13, Jack Dangler wrote: > or why not get a cloud desktop running whatever distro you want and you > don't have to do anything Three reasons: privacy, speed, price. Not in this order. On Thu, 10 Mar 2022 at 15:20, Chris Angelico wrote: > Very easy. I use Debian with Xfc

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 3/10/22 06:03, Marco Sulla wrote: > I tried Debian on a VM, but I found it too much basical. A little > example: it does not have the shortcut ctrl+alt+t to open a terminal > that Ubuntu has. I'm quite sure it's simple to add, but I'm starting > to be old and lazy... Debian has the same desktop

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

Marco Sulla writes: > On Thu, 10 Mar 2022 at 04:50, Michael Torrie wrote: >> >> On 3/9/22 13:05, Marco Sulla wrote: >> > So my laziness pays. I use only LTS distros, and I update only when >> > there are security updates. >> > PS: any suggestions for a new LTS distro? My Lubuntu is reaching its

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Fri, 11 Mar 2022 at 00:05, Marco Sulla wrote: > > On Thu, 10 Mar 2022 at 04:50, Michael Torrie wrote: > > > > On 3/9/22 13:05, Marco Sulla wrote: > > > So my laziness pays. I use only LTS distros, and I update only when > > > there are security updates. > > > PS: any suggestions for a new LTS

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

On 3/10/22 08:03, Marco Sulla wrote: On Thu, 10 Mar 2022 at 04:50, Michael Torrie wrote: On 3/9/22 13:05, Marco Sulla wrote: So my laziness pays. I use only LTS distros, and I update only when there are security updates. PS: any suggestions for a new LTS distro? My Lubuntu is reaching its en

Suggestion for Linux Distro (from PSA: Linux vulnerability)

On Thu, 10 Mar 2022 at 04:50, Michael Torrie wrote: > > On 3/9/22 13:05, Marco Sulla wrote: > > So my laziness pays. I use only LTS distros, and I update only when > > there are security updates. > > PS: any suggestions for a new LTS distro? My Lubuntu is reaching its > > end-of-life. I prefer lig

Re: Review, suggestion etc?

On 2020-12-18, Joe Pfeiffer wrote: > Grant Edwards writes: > >> Yep, there are definitly cases where it's pretty much the only right >> answer. If you try to avoid it, you end up writing what turns into a >> simulation of recursion -- and doing that correctly isn't easy. > > Decades ago I had to

Re: Review, suggestion etc?

Grant Edwards writes: > On 2020-12-18, Joe Pfeiffer wrote: > >> Recursion has very limited application, but where it's the right >> tool it's invaluable (top-down parsers, some graph algorithms...). >> We teach it primarily because by the time a student has a good >> handle on how to write a re

Re: Review, suggestion etc?

On 2020-12-18, Joe Pfeiffer wrote: > Recursion has very limited application, but where it's the right > tool it's invaluable (top-down parsers, some graph algorithms...). > We teach it primarily because by the time a student has a good > handle on how to write a recursive function they understand

Re: Review, suggestion etc?

Bischoop writes: > On 2020-12-17, Dennis Lee Bieber wrote: >>> >> >> The main concern is that you are using a RECURSIVE call. It is much >> better for such input checking to use an ITERATIVE (loop) scheme. >> >> def marriage(): >> #loop forever >> while True:

Re: Review, suggestion etc?

On 2020-12-17, Bischoop wrote: > On 2020-12-17, Dennis Lee Bieber wrote: >>> >> >> The main concern is that you are using a RECURSIVE call. It is much >> better for such input checking to use an ITERATIVE (loop) scheme. >> >> def marriage(): >> #loop forever >>

Re: Review, suggestion etc?

On 2020-12-17, Dennis Lee Bieber wrote: >> > > The main concern is that you are using a RECURSIVE call. It is much > better for such input checking to use an ITERATIVE (loop) scheme. > > def marriage(): > #loop forever > while True: > #

Re: Review, suggestion etc?

On 2020-12-17, Michał Jaworski wrote: > > Exactly. I would go even further and make it a reusable function. Eg. > > def prompt_choices(prompt, choices): > choices = set(c.lower() for c in choices) > while value := input(f"{prompt} {choices}:").lower() not in choices: > pass > r

Re: Review, suggestion etc?

> I think he's hinting at using a loop instead. > > while maritals != 'Yes' and maritals != 'No': >maritals = input('Married: Yes/No ?: ').title() Exactly. I would go even further and make it a reusable function. Eg. def prompt_choices(prompt, choices): choices = set(c.lower() for c in ch

Re: Review, suggestion etc?

On 2020-12-17, Michael Torrie wrote: > On 12/17/20 9:10 AM, Bischoop wrote: >> Could you expand here, I rather don't know how I could do it different >> way apart from if maritals == 'Yes' or maritals == 'No' or is it what >> you meant? > > I think he's hinting at using a loop instead. > > while m

Re: Review, suggestion etc?

On 12/17/20 9:10 AM, Bischoop wrote: > Could you expand here, I rather don't know how I could do it different > way apart from if maritals == 'Yes' or maritals == 'No' or is it what > you meant? I think he's hinting at using a loop instead. while maritals != 'Yes' and maritals != 'No': marita

Re: Review, suggestion etc?

On 2020-12-17, Michał Jaworski wrote: Thanks for feedback and useful tips. I couldn't use any OOP here because have not a clue about it, just going to go toward it. > I've made a quick look at the code and even executed it. It looks pretty > clear and is easy to understand, although it has som

Re: Review, suggestion etc?

I've made a quick look at the code and even executed it. It looks pretty clear and is easy to understand, although it has some structural problems. I won't do a thorough review but highlight the most important problems. First, the recursive user input pattern you use: def marriage():

Re: Review, suggestion etc?

On 2020-12-17, Bischoop wrote: Accidently removed the paste, https://bpa.st/E3FQ -- https://mail.python.org/mailman/listinfo/python-list

Review, suggestion etc?

I've done my biggest project that allowed me to learn a lot. It's basically simply Database with basic options >> https://bpa.st/FU4A . What sucks here is basically the find_people() I'll have to work on it yet to make it more useful. . If anyone was bored and wished to point me some wrong way or

Re: List Partition Comprehension (Feature Suggestion)

On 9/22/2020 3:16 PM, Yakov Shalunov wrote: Python list comprehension is substantially faster than plan iteration, to the point where ``` l0, l1 = [],[] for x in l: if cond(x): l0.append(x) else: l1.append(x) ``` runs at about the same speed as ``` l0 = [x for x in l

Re: List Partition Comprehension (Feature Suggestion)

On 23/09/20 7:16 am, Yakov Shalunov wrote: l0, l1 = ([x for x in l if cond(x) else x]) l0, l1, l2 = ([x for x in l if cond0(x) else x**2 if cond1(x) else x**3]) This syntax seems a bit convoluted. One of the result expressions is at the beginning as usual, but the rest are tacked on the end. An

Re: List Partition Comprehension (Feature Suggestion)

A possible alternative would be a partition library function in the same vein as `map` and `filter` ``` def partition(n, key, iter): """ Partitions a list. Args: (n: the number of partitions), (key: function which takes elements and returns the index of the partition to place them in)

List Partition Comprehension (Feature Suggestion)

Python list comprehension is substantially faster than plan iteration, to the point where ``` l0, l1 = [],[] for x in l: if cond(x): l0.append(x) else: l1.append(x) ``` runs at about the same speed as ``` l0 = [x for x in l if cond(x)] l1 = [x for x in l if not cond(x)] ```

Re: Asyncio Queue implementation suggestion

> On 17 Sep 2020, at 15:51, Dennis Lee Bieber wrote: > > On Wed, 16 Sep 2020 13:39:51 -0400, Alberto Sentieri <2...@tripolho.com> > declaimed the following: > > >> devices tested simultaneously, I soon run out of file descriptor. Well, >> I increased the number of file descriptor in the appl

Re: Asyncio Queue implementation suggestion

On 17/09/2020 16:51, Dennis Lee Bieber wrote: > On Wed, 16 Sep 2020 13:39:51 -0400, Alberto Sentieri <2...@tripolho.com> > declaimed the following: > >> devices tested simultaneously, I soon run out of file descriptor. Well, >> I increased the number of file descriptor in the application and then

Re: Asyncio Queue implementation suggestion

Hello Alberto, I scrambled your original message a bit here. > Apparently asyncio Queues use a Linux pipe and each queue require 2 file > descriptors. Am I correct? As far as I know (And I know a bit about asyncio in CPython 3.5+) asyncio.queues.Queue doesn't use any file descriptor. It is imple

Asyncio Queue implementation suggestion

I have a suggestion about the implementation of asyncio queues that could improve performance. I might be missing something, however. I am sort of new to Python. Below a short description of the problem I am facing. I wrote a daemon in Python 3 (running in Linux) which test many devices at

Re: Syntax Suggestion: Pass Function Definition as Argument

On 07/11/2019 13:36, Stephen Waldron wrote: This is how it is at the moment, however it may be more agreeable, especially if that is the only purpose of the function, for python users to be able to define new functions inside of function calls. No, not seeing it. Sorry, I don't think "I don'

Re: Syntax Suggestion: Pass Function Definition as Argument

ion's scope, but prompt is not inherited: runOpt ("Play Game"): getUserData() chr[0].id = 0 time = 0 score = 0 scene = 1 runOpt ("How To Play"): nonlocal prompt loadBg() display(prompt) scene = 2 runOpt ("Settings"):

Re: Syntax Suggestion: Pass Function Definition as Argument

On Fri, Nov 8, 2019 at 11:22 PM Antoon Pardon wrote: > > On 8/11/19 13:00, Chris Angelico wrote: > > On Fri, Nov 8, 2019 at 10:57 PM Antoon Pardon wrote: > >> On 7/11/19 18:10, Stephen Waldron wrote: > >>> What I'm aiming for is the ability to, within a function call, pass a > >>> suite that wou

Re: Syntax Suggestion: Pass Function Definition as Argument

On 8/11/19 13:00, Chris Angelico wrote: > On Fri, Nov 8, 2019 at 10:57 PM Antoon Pardon wrote: >> On 7/11/19 18:10, Stephen Waldron wrote: >>> What I'm aiming for is the ability to, within a function call, pass a suite >>> that would be there automatically defined by the compiler/interpreter. >>

Re: Syntax Suggestion: Pass Function Definition as Argument

On Fri, Nov 8, 2019 at 10:57 PM Antoon Pardon wrote: > > On 7/11/19 18:10, Stephen Waldron wrote: > > What I'm aiming for is the ability to, within a function call, pass a suite > > that would be there automatically defined by the compiler/interpreter. > > Another comment did mention lambda func

Re: Syntax Suggestion: Pass Function Definition as Argument

On 7/11/19 18:10, Stephen Waldron wrote: > What I'm aiming for is the ability to, within a function call, pass a suite > that would be there automatically defined by the compiler/interpreter. > Another comment did mention lambda functions, which does to some degree > provide that capability, but

RE: Syntax Suggestion: Pass Function Definition as Argument

Here is it rewritten using the proposal: ``` #Definition def myFoo (str1, str2, foo, str = " "): print( foo(str = str1), foo(str = str2) ) #Call myFoo ("hello", "world!"): str = list(str)[0].upper() + str[1:] return str ``` Are you looking for multi-line l

Re: Syntax Suggestion: Pass Function Definition as Argument

Thanks Antoon. I do suppose that it is kind of wrong to say the only way is to "reference its [the function's] name" as an argument, however the point I was trying to make was that it isn't possible to pass a function that is either not in some way previously defined or a reference to something

Re: Syntax Suggestion: Pass Function Definition as Argument

Thanks Antoon. I do suppose that it is kind of wrong to say the only way is to "reference its [the function's] name" as an argument, however the point I was trying to make was that you cannot pass a function that is either not in some way previously defined or a reference to something previously

Re: Syntax Suggestion: Pass Function Definition as Argument

On 7/11/19 14:36, Stephen Waldron wrote: > Hi, I'm new to the group and to Python, so forgive me if I make any faux-pas > here. As I can tell, the only way to pass a function as an argument is to > reference its name as follows: > > def foo1(message): > print(message) > > def foo2(foo, messag

Syntax Suggestion: Pass Function Definition as Argument

Hi, I'm new to the group and to Python, so forgive me if I make any faux-pas here. As I can tell, the only way to pass a function as an argument is to reference its name as follows: def foo1(message): print(message) def foo2(foo, message): print("Your function says:") foo(message)

Re: Feature suggestion: "Using declarations" i.e. context managers ("with" blocks) tied to scope/lifetime of the variable rather than to nesting

On 21/02/2019 19:35, mnl.p...@gmail.com wrote: > (I sent this a few days ago but got bounced without a reason—don’t see it > posted, so I’m trying one more time.) No, it got through. And it's in the archive: https://mail.python.org/pipermail/python-list/2019-February/739548.html -- https://mail

Re: Feature suggestion: "Using declarations" i.e. context managers ("with" blocks) tied to scope/lifetime of the variable rather than to nesting

On 21/02/2019 18:35, mnl.p...@gmail.com wrote: (I sent this a few days ago but got bounced without a reason—don’t see it posted, so I’m trying one more time.) It was posted, and commented on. You can see the thread in the mailing list archives, if you don't believe me: https://mail.python.or

Feature suggestion: "Using declarations" i.e. context managers ("with" blocks) tied to scope/lifetime of the variable rather than to nesting

(I sent this a few days ago but got bounced without a reason—don’t see it posted, so I’m trying one more time.) I thought this new C# feature would be a good thing to add to Python: https://vcsjones.com/2019/01/30/csharp-8-using-declarations/ The nesting required by context managers can be at od

[asyncio] Suggestion for a major PEP

Hello, I copy paste the main idea from an article I have written: contextual async " Imagine you have some code written for monothread. And you want to include your code in a multithread environment. Do you need to adapt all your c

Re: Suggestion for a "data" object syntax

On Sat, May 12, 2018 at 5:38 PM, Ian Kelly wrote: > On Fri, May 11, 2018 at 5:26 PM, Mikhail V wrote: >> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly wrote: >>> On Thu, May 10, 2018 at 6:34 PM, Mikhail V wrote: Do you understand that basically any python code sent by e-mail converts ta

Re: Suggestion for a "data" object syntax

On Fri, May 11, 2018 at 5:26 PM, Mikhail V wrote: > On Fri, May 11, 2018 at 9:12 AM, Ian Kelly wrote: >> On Thu, May 10, 2018 at 6:34 PM, Mikhail V wrote: >>> Do you understand that basically any python code sent by e-mail converts >>> tabs to >>> spaces, thus the only way to receive it - is to

Re: Suggestion for a "data" object syntax

On Sat, May 12, 2018 at 7:54 AM, Steven D'Aprano wrote: > On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote: > >> it is just not a trivial task to find an optimal solution to this > > We already have an optimal solution to this. Yes. current syntax will not go anyway so proposal addresses case

Re: Suggestion for a "data" object syntax

On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote: > it is just not a trivial task to find an optimal solution to this We already have an optimal solution to this. * It works with any editor, including simple ones. * It is safe for transmit over email, or on web forums, so long as you av

Re: Suggestion for a "data" object syntax

On Fri, May 11, 2018 at 9:39 AM, Ian Kelly wrote: > On Mon, May 7, 2018 at 9:45 PM, Mikhail V wrote: >> *Example 1. Multi-line strings* >> >> data === S : >> this is multi-line string >> escape chars: same as in strings (\\, \\n, \\t ...) , >> but "no need to 'escape' quotes" > > My

Re: Suggestion for a "data" object syntax

On Fri, May 11, 2018 at 9:12 AM, Ian Kelly wrote: > On Thu, May 10, 2018 at 6:34 PM, Mikhail V wrote: >> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano >> wrote: >>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote: >>> >> but I propose Tab-separated elements. > > Then these are not ord

Re: Suggestion for a "data" object syntax

On Fri, May 11, 2018 at 4:39 PM, Ian Kelly wrote: > On Mon, May 7, 2018 at 9:45 PM, Mikhail V wrote: >> Benefits are easy to see: say I want a tuple of strings: >> >> data === T : >> "foo bar" >> "hello world" >> "to be continued..." >> >> VS current: >> >> data = ( >> "foo bar" ,

Re: Suggestion for a "data" object syntax

On Mon, May 7, 2018 at 9:45 PM, Mikhail V wrote: > Here is an idea for 'data object' a syntax. > For me it is interesting, how would users find such syntax. > I personally find that this should be attractive from users > perspective. > Main aim is more readable presenting of typical data chunks >

Re: Suggestion for a "data" object syntax

On Thu, May 10, 2018 at 6:34 PM, Mikhail V wrote: > On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano > wrote: >> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote: >> > >>> but I propose Tab-separated elements. >> >> We already have tab-separated elements in Python. It is allowed to use >> tabs

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano wrote: > On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote: > >> but I propose Tab-separated elements. > > We already have tab-separated elements in Python. It is allowed to use > tabs between any whitespace separated tokens. Yes, exactly. So in

Re: Suggestion for a "data" object syntax

, so as to fit more lines into a single screen, sometimes it means I spread things out over multiple lines in order to get maximum benefit from two dimensional layout. It all depends on the code I am writing and I use whatever is best for the situation. >> - the first one is unambiguous whil

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 3:14 AM, Ben Finney wrote: > Mikhail V writes: > >> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico wrote: >> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V wrote: >> >> Just admit it, you try to troll me (or just pretend, I don't know). >> > >> > No, I am not trolling you.

Re: Suggestion for a "data" object syntax

Mikhail V writes: > On Wed, May 9, 2018 at 12:33 AM, Chris Angelico wrote: > > On Wed, May 9, 2018 at 7:15 AM, Mikhail V wrote: > >> Just admit it, you try to troll me (or just pretend, I don't know). > > > > No, I am not trolling you. > > I don't believe you. If that's true – if you believe C

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 12:33 AM, Chris Angelico wrote: > On Wed, May 9, 2018 at 7:15 AM, Mikhail V wrote: >> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico wrote: >>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V wrote: Right? Your issues with tabs aside, I think it is impossible to ignore th

Re: Suggestion for a "data" object syntax

sy) way, so there's no point debating this. Fortunately for the rest of us, status quo wins a stalemate. ChrisA Please stop feeding the OP, to my knowledge he's never once come up with any sensible suggestion for Python. -- My fellow Pythonistas, ask not what our language can do for yo

Re: Suggestion for a "data" object syntax

On Wed, May 9, 2018 at 7:15 AM, Mikhail V wrote: > On Tue, May 8, 2018 at 5:25 PM, Chris Angelico wrote: >> On Tue, May 8, 2018 at 10:52 PM, Mikhail V wrote: >>> Right? Your issues with tabs aside, I think it is impossible to ignore the >>> the readability improvement. Not even speaking of how >

  1   2   3   4   5   6   7   8   >