Re: Difference method vs attribut = function

Ulrich Goebel wrote at 2024-6-28 18:08 +0200: >Hi, > >a class can have methods, and it can have attributes, which can hold a >function. Both is well known, of course. > >My question: Is there any difference? I think you should make the distinction "class versus instance attribute" rather than "me

Re: Difference method vs attribut = function

On 6/28/2024 12:08 PM, Ulrich Goebel via Python-list wrote: Hi, a class can have methods, and it can have attributes, which can hold a function. Both is well known, of course. My question: Is there any difference? The code snipped shows that both do what they should do. But __dict__ includes

Re: Difference method vs attribut = function

On 6/28/24 10:08, Ulrich Goebel via Python-list wrote: By the way: in my usecase I want to pass different functions to different instances of MyClass. It is in the context of a database app where I build Getters for database data and pass one Getter per instance. If I understood what you're

Re: Difference method vs attribut = function

On 2024-06-28 18:08:54 +0200, Ulrich Goebel via Python-list wrote: > a class can have methods, and it can have attributes, which can hold a > function. Both is well known, of course. > > My question: Is there any difference? > > The code snipped shows that both do what they should do. But __dict_

Difference method vs attribut = function

Hi, a class can have methods, and it can have attributes, which can hold a function. Both is well known, of course. My question: Is there any difference? The code snipped shows that both do what they should do. But __dict__ includes just the method, while dir detects the method and the attribu

Re: venvs vs. package management

There are several independent problems here: 1. Very short release cycle. This is independent of the Python venv module but is indirectly influenced by Python's own release cycle. Package maintainers don't have time for proper testing, they are encouraged to release a bunch of new (and poorly test

Re: venvs vs. package management

On 19/05/2024 08.49, Peter J. Holzer wrote: [...] That's what package management on Linux is for. Sure, it means that you won't have the newest version of anything and some packages not at all, but you don't have to care about dependencies. Or updates. Well, that doesn't work as well. Distribut

venvs vs. package management (was: Terminal Emulator (Posting On Python-List Prohibited))

On 2024-05-18 20:12:33 +0200, Piergiorgio Sartor via Python-list wrote: > On 18/05/2024 20.04, Mats Wichmann wrote: > > So venvs make managing all that pretty convenient. Dunno why everybody's > > so down on venvs... > > Only people which are *not* using python... :-) > > In my experience, venvs

Re: pathlib.Path.is_file vs os.path.isfile difference

> On 10 Mar 2024, at 14:49, Thomas Passin via Python-list > wrote: > > That and there's a registry setting: > > https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation > Yep that and rules about size of parts of the path. Barry -- https://mail.python.org/mailm

Re: pathlib.Path.is_file vs os.path.isfile difference

On 3/10/2024 9:33 AM, Albert-Jan Roskam wrote: On Mar 10, 2024 12:59, Thomas Passin via Python-list wrote: On 3/10/2024 6:17 AM, Barry wrote: > > >> On 8 Mar 2024, at 23:19, Thomas Passin via Python-list wrote: >> >> We just learned a few posts back that it

Re: pathlib.Path.is_file vs os.path.isfile difference

On Mar 10, 2024 12:59, Thomas Passin via Python-list wrote: On 3/10/2024 6:17 AM, Barry wrote: > > >> On 8 Mar 2024, at 23:19, Thomas Passin via Python-list wrote: >> >> We just learned a few posts back that it might be specific to Linux; I ran it on

Re: pathlib.Path.is_file vs os.path.isfile difference

On 3/10/2024 6:17 AM, Barry wrote: On 8 Mar 2024, at 23:19, Thomas Passin via Python-list wrote: We just learned a few posts back that it might be specific to Linux; I ran it on Windows. Depending on the exact win32 api used there is a 257 limit on windows. The 257 includes 2 for the dev

Re: pathlib.Path.is_file vs os.path.isfile difference

> On 8 Mar 2024, at 23:19, Thomas Passin via Python-list > wrote: > > We just learned a few posts back that it might be specific to Linux; I ran it > on Windows. Depending on the exact win32 api used there is a 257 limit on windows. The 257 includes 2 for the device, C:, and 255 for the pat

Re: pathlib.Path.is_file vs os.path.isfile difference

On 2024-03-08, Thomas Passin via Python-list wrote: > >> Hi, I tested this with Python 3.8. Good to know that this was fixed! > > We just learned a few posts back that it might be specific to Linux; I > ran it on Windows. On Linux, the limit is imposed by the filesystem. Most of the "real" file

Re: pathlib.Path.is_file vs os.path.isfile difference

On 3/8/2024 5:14 PM, Albert-Jan Roskam wrote: On Mar 8, 2024 19:35, Thomas Passin via Python-list wrote: On 3/8/2024 1:03 PM, Albert-Jan Roskam via Python-list wrote: > Hi, > I was replacing some os.path stuff with Pathlib and I discovered this: > Path(256

Re: pathlib.Path.is_file vs os.path.isfile difference

On Mar 8, 2024 19:35, Thomas Passin via Python-list wrote: On 3/8/2024 1:03 PM, Albert-Jan Roskam via Python-list wrote: > Hi, > I was replacing some os.path stuff with Pathlib and I discovered this: > Path(256 * "x").is_file() # OSError > os.p

Re: pathlib.Path.is_file vs os.path.isfile difference

On 3/8/2024 2:21 PM, Grant Edwards via Python-list wrote: On 2024-03-08, Thomas Passin via Python-list wrote: On 3/8/2024 1:03 PM, Albert-Jan Roskam via Python-list wrote: Hi, I was replacing some os.path stuff with Pathlib and I discovered this: Path(256 * "x").is_file() # OSE

Re: pathlib.Path.is_file vs os.path.isfile difference

On 2024-03-08, Grant Edwards via Python-list wrote: >> OSError: [Errno 36] File name too long: >> 'x

Re: pathlib.Path.is_file vs os.path.isfile difference

On 2024-03-08, Grant Edwards via Python-list wrote: > On 2024-03-08, Thomas Passin via Python-list wrote: >> On 3/8/2024 1:03 PM, Albert-Jan Roskam via Python-list wrote: >>> Hi, >>> I was replacing some os.path stuff with Pathlib and I discovered this: >>> Path(256 * "x").is_file()

Re: pathlib.Path.is_file vs os.path.isfile difference

On 2024-03-08, Thomas Passin via Python-list wrote: > On 3/8/2024 1:03 PM, Albert-Jan Roskam via Python-list wrote: >> Hi, >> I was replacing some os.path stuff with Pathlib and I discovered this: >> Path(256 * "x").is_file() # OSError >> os.path.isfile(256 * "x") # bool >> I

Re: pathlib.Path.is_file vs os.path.isfile difference

On 3/8/2024 1:03 PM, Albert-Jan Roskam via Python-list wrote: Hi, I was replacing some os.path stuff with Pathlib and I discovered this: Path(256 * "x").is_file() # OSError os.path.isfile(256 * "x") # bool Is this intended? Does pathlib try to resemble os.path as closely as

pathlib.Path.is_file vs os.path.isfile difference

Hi, I was replacing some os.path stuff with Pathlib and I discovered this: Path(256 * "x").is_file() # OSError os.path.isfile(256 * "x") # bool Is this intended? Does pathlib try to resemble os.path as closely as possible? Best wishes, Albert-Jan -- https://mail.python.or

RE: A problem with str VS int.

y, December 12, 2023 3:58 AM To: python-list@python.org Subject: Re: A problem with str VS int. Op 12/12/2023 om 9:22 schreef Steve GS via Python-list: > With all these suggestions on > how to fix it, no one seems to > answer why it fails only when > entering a two-digit number. > O

Re: A problem with str VS int.

On 12/12/23 21:22, Steve GS wrote: With all these suggestions on how to fix it, no one seems to answer why it fails only when entering a two-digit number. One and three work fine when comparing with str values. It is interesting that the leading 0 on a two digit worked. Still, one digit and thre

Re: A problem with str VS int.

Op 12/12/2023 om 9:22 schreef Steve GS via Python-list: With all these suggestions on how to fix it, no one seems to answer why it fails only when entering a two-digit number. One and three work fine when comparing with str values. It is interesting that the leading 0 on a two digit worked. Stil

RE: A problem with str VS int.

now more of a curiosity as I did use the integer comparisons. SGA -Original Message- From: Python-list On Behalf Of dn via Python-list Sent: Sunday, December 10, 2023 12:53 AM To: python-list@python.org Subject: Re: A problem with str VS int. On 10/12/23 15:42, Steve GS via Python-list

Re: A problem with str VS int.

On 10/12/23 15:42, Steve GS via Python-list wrote: If I enter a one-digit input or a three-digit number, the code works but if I enter a two digit number, the if statement fails and the else condition prevails. tsReading = input(" Enter the " + Brand + " test strip reading: ")

Re: A problem with str VS int.

On 12/9/2023 9:42 PM, Steve GS via Python-list wrote: If I enter a one-digit input or a three-digit number, the code works but if I enter a two digit number, the if statement fails and the else condition prevails. tsReading = input(" Enter the " + Brand + " test strip reading: ")

RE: A problem with str VS int.

user can enter any text, they might enter ".01" or "hello" or al kinds of nonsense. If you converted to numbers and tested whether it failed, ... -Original Message- From: Python-list On Behalf Of Steve GS via Python-list Sent: Saturday, December 9, 2023 9:42 PM To: pyth

A problem with str VS int.

If I enter a one-digit input or a three-digit number, the code works but if I enter a two digit number, the if statement fails and the else condition prevails. tsReading = input(" Enter the " + Brand + " test strip reading: ") if tsReading == "": tsReading = "0" print(t

Re: type annotation vs working code

Am Wed, Oct 04, 2023 at 05:25:04PM +1300 schrieb dn via Python-list: > The first question when dealing with the Singleton Pattern is what to do when > more than > one instantiation is attempted: > > - silently return the first instance This, in my case. > and so, returning to the matter of 'rea

Re: type annotation vs working code

On 04/10/2023 19.41, Chris Angelico via Python-list wrote: On Wed, 4 Oct 2023 at 15:27, dn via Python-list wrote: - should the class have been called either; class SomethingSingleton(): or a Singleton() class defined, which is then sub-classed, ie class Something( Singleton ): i

Re: type annotation vs working code

On Wed, 4 Oct 2023 at 17:47, Greg Ewing via Python-list wrote: > > On 4/10/23 5:25 pm, dn wrote: > > The first question when dealing with the Singleton Pattern is what to do > > when more than one instantiation is attempted > > My preferred way of handling singletons is not to expose the class > i

Re: type annotation vs working code

On 4/10/23 5:25 pm, dn wrote: The first question when dealing with the Singleton Pattern is what to do when more than one instantiation is attempted My preferred way of handling singletons is not to expose the class itself, but a function that creates an instance the first time it's called, and

Re: type annotation vs working code

On Wed, 4 Oct 2023 at 15:27, dn via Python-list wrote: > - should the class have been called either; > > class SomethingSingleton(): > > or a Singleton() class defined, which is then sub-classed, ie > > class Something( Singleton ): > > in order to better communicate the coder's intent t

Re: type annotation vs working code

On 02/10/2023 00.57, Karsten Hilbert via Python-list wrote: Sorry for having conflated the core of the matter with all the Borg shenanigans, that's where I found the problem in my real code, so there :-) The first question when dealing with the Singleton Pattern is what to do when more than on

Re: type annotation vs working code

On Mon, 2 Oct 2023 at 09:10, Barry via Python-list wrote: > > > > > On 1 Oct 2023, at 19:36, Richard Damon via Python-list > > wrote: > > > > Perhaps a better method would be rather than just using the name and > > catching the exception, use a real already_initialized flag (set to True > > wh

Re: type annotation vs working code

> On 1 Oct 2023, at 19:36, Richard Damon via Python-list > wrote: > > Perhaps a better method would be rather than just using the name and catching > the exception, use a real already_initialized flag (set to True when you > initialize), and look it up with getattr() with a default value of

Re: type annotation vs working code

My view of the issue is that the "trick" of "evaluating" a name to see if the object has been initialized is just a tad on the "tricky" side, and the annotation/value is really incorrect. The name at the point you are annotating it, isn't really a "bool" because a bool will always have either

Re: type annotation vs working code

On Sun, 1 Oct 2023 at 22:58, Karsten Hilbert via Python-list wrote: > > Sorry for having conflated the core of the matter with all > the Borg shenanigans, that's where I found the problem in my > real code, so there :-) > > Consider this: > > # >

Re: type annotation vs working code

Sorry for having conflated the core of the matter with all the Borg shenanigans, that's where I found the problem in my real code, so there :-) Consider this: # class Surprise: def __init__(self, with_type_annotation=False):

Re: type annotation vs working code

On 01/10/2023 11.25, Karsten Hilbert via Python-list wrote: Am Sun, Oct 01, 2023 at 09:04:05AM +1300 schrieb dn via Python-list: class WorkingSingleton(Borg): def __init__(self): print(self.__class__.__name__, ':') try: self.alrea

Re: type annotation vs working code

Am Sun, Oct 01, 2023 at 09:04:05AM +1300 schrieb dn via Python-list: > >class WorkingSingleton(Borg): > > > > def __init__(self): > > print(self.__class__.__name__, ':') > > try: > > self.already_initialized > > print('already ini

Re: type annotation vs working code

On 01/10/2023 08.00, Karsten Hilbert via Python-list wrote: A type annotation isn't supposed to change what code does, or so I thought: # class Borg: _instances:dict = {} def __new__(cls, *args, **kargs):

Re: type annotation vs working code

On 9/30/23 13:00, Karsten Hilbert via Python-list wrote: A type annotation isn't supposed to change what code does, or so I thought: # class Borg: _instances:dict = {} def __new__(cls, *args, **kargs): #

type annotation vs working code

A type annotation isn't supposed to change what code does, or so I thought: # class Borg: _instances:dict = {} def __new__(cls, *args, **kargs): # look up subclass instance cache if Borg._i

Re: Compiling python on windows with vs

On 6/15/23, Thomas Schweikle via Python-list wrote: > > No. This flag is not inherited. Someone has to set it for created > directories. It is easy to confirm: take a directory not under MSYS or > cygwin control (because it is mounted by MSYS or cygwin), set the flag, > then create directories. Th

Re: Compiling python on windows with vs

Am Do., 15.Juni.2023 um 16:28:21 schrieb Eryk Sun: On 6/15/23, Thomas Schweikle via Python-list wrote: In this case: not sure what is going on. Possibly you have a setting configured that affects the behavior of Git via the MinGW-w64 runtime, such that calling mkdir() ends up calling NtSet

Re: Compiling python on windows with vs

Am Do., 15.Juni.2023 um 15:44:42 schrieb Inada Naoki: Then, git doesn't enable Windows NTFS case sensitivity. You enabled NTFS case sensitivity on "C:\Users\user\K". And Windows enabled case sensitivity for all new directories under the directory. No. This flag is not inherited. Someone has t

Re: Compiling python on windows with vs

On 6/15/23, Thomas Schweikle via Python-list wrote: > > In this case: not sure what is going on. Possibly you have a setting configured that affects the behavior of Git via the MinGW-w64 runtime, such that calling mkdir() ends up calling NtSetInformationFile() to set the FileCaseSensitiveInformat

Re: Compiling python on windows with vs

Then, git doesn't enable Windows NTFS case sensitivity. You enabled NTFS case sensitivity on "C:\Users\user\K". And Windows enabled case sensitivity for all new directories under the directory. Since it is not default and minor setting, it is not a bug that current Python doesn't support building

Re: Compiling python on windows with vs

Am Mi., 14.Juni.2023 um 15:10:50 schrieb Eryk Sun: On 6/14/23, Inada Naoki via Python-list wrote: Since Git enables Windows NTFS case sensitivity while checking out sources I didn't know that. Would you give us a link to this feature? As far as I know, `git config core.ignorecase` doesn't m

Re: Compiling python on windows with vs

On 6/14/23, Inada Naoki via Python-list wrote: >> Since Git enables Windows NTFS case sensitivity while checking out sources > > I didn't know that. Would you give us a link to this feature? > As far as I know, `git config core.ignorecase` doesn't mean NTFS case > sensitive. If a repo is cloned i

Re: Compiling python on windows with vs

> Since Git enables Windows NTFS case sensitivity while checking out sources I didn't know that. Would you give us a link to this feature? As far as I know, `git config core.ignorecase` doesn't mean NTFS case sensitive. On Wed, Jun 14, 2023 at 1:57 AM Thomas Schweikle via Python-list < python-lis

Re: Compiling python on windows with vs

Am Di., 13.Juni.2023 um 20:36:17 schrieb Mats Wichmann via Python-list: On 6/13/23 12:12, Thomas Schweikle via Python-list wrote: Am Di., 13.Juni.2023 um 19:20:38 schrieb Jim Schwartz: What version of visual studio are you using? Visual Studio 2022, aka 17.6.2. What version of python?

Re: Compiling python on windows with vs

On 6/13/23, Thomas Schweikle via Python-list wrote: > > Since Git enables Windows NTFS case sensitivity while checking out > sources ... is it a bug or a "feature"? And: is there a simple AFAIK the Windows version of Git (you're not using the Linux version of Git via WSL, right?) does not automat

RE: Compiling python on windows with vs

Sent: Tuesday, June 13, 2023 1:12 PM To: Python Cc: Thomas Schweikle Subject: Re: Compiling python on windows with vs Am Di., 13.Juni.2023 um 19:20:38 schrieb Jim Schwartz: > What version of visual studio are you using? Visual Studio 2022, aka 17.6.2. > What version of python? python 3.10.1

Re: Compiling python on windows with vs

On 6/13/23 12:12, Thomas Schweikle via Python-list wrote: Am Di., 13.Juni.2023 um 19:20:38 schrieb Jim Schwartz: What version of visual studio are you using? Visual Studio 2022, aka 17.6.2. What version of python? python 3.10.11 or 3.11.4 I’ve had success with using the cython package i

Re: Compiling python on windows with vs

Am Di., 13.Juni.2023 um 19:20:38 schrieb Jim Schwartz: What version of visual studio are you using? Visual Studio 2022, aka 17.6.2. What version of python? python 3.10.11 or 3.11.4 I’ve had success with using the cython package in python and cl from visual studio, but I haven’t tried v

Re: Compiling python on windows with vs

What version of visual studio are you using? What version of python? I’ve had success with using the cython package in python and cl from visual studio, but I haven’t tried visual studio alone. Sent from my iPhone > On Jun 13, 2023, at 11:59 AM, Thomas Schweikle via Python-list > wrote: >

Compiling python on windows with vs

Hi! Trying to compile python on windows leads to following error: _testimportmultiple.vcxproj -> C:\Users\sct-muc\Documents\Projekte\cpython\PCbuild\amd64\_testimportmultiple.pyd _testmultiphase.c Bibliothek "C:\Users\sct-muc\Documents\Projekte\cpython\PCbuild\amd64\_testmultiphase.l

Re: built-in pow() vs. math.pow()

On 2023-04-01 at 08:16:46 -0700, Andreas Eisele wrote: > BTW, there is another difference: built-in pow() deals with complex > arguments, while functions in math won't accept them at all. See also . -- https://mail.python.org/mailman/listinfo/python

Re: built-in pow() vs. math.pow()

Andreas Eisele schrieb am Donnerstag, 30. März 2023 um 11:16:02 UTC+2: > I sometimes make use of the fact that the built-in pow() function has an > optional third argument for modulo calculation, which is handy when dealing > with tasks from number theory, very large numbers, problems from Projec

Re: built-in pow() vs. math.pow()

On Fri, 31 Mar 2023 at 20:24, Peter J. Holzer wrote: > > On 2023-03-31 07:39:25 +0100, Barry wrote: > > On 30 Mar 2023, at 22:30, Chris Angelico wrote: > > > It's called math.pow. That on its own should be a strong indication > > > that it's designed to work with floats. > > > > So long as you kn

Re: built-in pow() vs. math.pow()

On 2023-03-31 07:39:25 +0100, Barry wrote: > On 30 Mar 2023, at 22:30, Chris Angelico wrote: > > It's called math.pow. That on its own should be a strong indication > > that it's designed to work with floats. > > So long as you know that the math module is provided to give access > the C math.h f

Re: built-in pow() vs. math.pow()

, why is it even there? >> >> It is useful for when you want the pure floating point power which has >> an approximately fixed computational cost (unlike integer powers). >> Perhaps it would have been better if it was named fpow similar to fsum >> vs sum. >> > > It

Re: built-in pow() vs. math.pow()

ational cost (unlike integer powers). > Perhaps it would have been better if it was named fpow similar to fsum > vs sum. > It's called math.pow. That on its own should be a strong indication that it's designed to work with floats. ChrisA -- https://mail.python.org/mailman/listinfo/python-list

Re: built-in pow() vs. math.pow()

at the built-in version can not do, and > if not, why is it even there? It is useful for when you want the pure floating point power which has an approximately fixed computational cost (unlike integer powers). Perhaps it would have been better if it was named fpow similar to fsum vs sum. -- Osca

RE: built-in pow() vs. math.pow()

n pow() vs. math.pow() I sometimes make use of the fact that the built-in pow() function has an optional third argument for modulo calculation, which is handy when dealing with tasks from number theory, very large numbers, problems from Project Euler, etc. I was unpleasantly surprised that math.pow()

Re: built-in pow() vs. math.pow()

On Thu, 30 Mar 2023 19:22:53 +0200, Roel Schroeven declaimed the following: >Either import the things you need explicitly: "from math import sin, >cos, exp" (for example). >Or a plain import: "import math" combined with "math.sin", "math.cos". >Or use an abbreviation: "import math as m" combined

Re: built-in pow() vs. math.pow()

On 2023-03-30, Thomas Passin wrote: > On 3/30/2023 5:15 AM, Andreas Eisele wrote: >> [...] I was unpleasantly surprised that math.pow() does not have >> this feature, hence "from math import *" overwrites the built-in >> pow() function with a function that lacks functionality. [...] > > Not an an

Re: built-in pow() vs. math.pow()

On 3/30/2023 5:15 AM, Andreas Eisele wrote: I sometimes make use of the fact that the built-in pow() function has an optional third argument for modulo calculation, which is handy when dealing with tasks from number theory, very large numbers, problems from Project Euler, etc. I was unpleasantl

Re: built-in pow() vs. math.pow()

Andreas Eisele schreef op 30/03/2023 om 11:15: I sometimes make use of the fact that the built-in pow() function has an optional third argument for modulo calculation, which is handy when dealing with tasks from number theory, very large numbers, problems from Project Euler, etc. I was unpleasa

Re: built-in pow() vs. math.pow()

> On 30 Mar 2023, at 18:11, Barry Scott wrote: > > > >> On 30 Mar 2023, at 10:15, Andreas Eisele wrote: >> >> I sometimes make use of the fact that the built-in pow() function has an >> optional third argument for modulo calculation, which is handy when dealing >> with tasks from number

Re: built-in pow() vs. math.pow()

> On 30 Mar 2023, at 10:15, Andreas Eisele wrote: > > I sometimes make use of the fact that the built-in pow() function has an > optional third argument for modulo calculation, which is handy when dealing > with tasks from number theory, very large numbers, problems from Project > Euler, et

built-in pow() vs. math.pow()

I sometimes make use of the fact that the built-in pow() function has an optional third argument for modulo calculation, which is handy when dealing with tasks from number theory, very large numbers, problems from Project Euler, etc. I was unpleasantly surprised that math.pow() does not have thi

Re: Usenet vs. Mailing-list (was: evaluation question)

On 2023-01-31, Alan Gauld wrote: > On 28/01/2023 21:36, Dennis Lee Bieber wrote: > >> Now -- last time I checked the gmane server says posting is prohibited. >> I used to use gmane as it retrieved directly from the mailing list > > I still use gmane but its no posting thing is a pain because

Re: Usenet vs. Mailing-list (was: evaluation question)

On 28/01/2023 21:36, Dennis Lee Bieber wrote: > Now -- last time I checked the gmane server says posting is prohibited. > I used to use gmane as it retrieved directly from the mailing list I still use gmane but its no posting thing is a pain because responding (or posting new stuff) is a n

Re: Usenet vs. Mailing-list

On 2023-01-31, Anssi Saari wrote: > Grant Edwards writes: > >> No. FWIW, it's the mailing list that's blocking them, not Gmane. >> >> That's why I wrote this: >> >> https://github.com/GrantEdwards/hybrid-inews >> >> It's an inews work-alike that submits most posts via gmanes NNTP >> server, b

Re: Usenet vs. Mailing-list

Grant Edwards writes: > No. FWIW, it's the mailing list that's blocking them, not Gmane. > > That's why I wrote this: > > https://github.com/GrantEdwards/hybrid-inews > > It's an inews work-alike that submits most posts via gmanes NNTP > server, but will deal with particular groups > (e.g. gm

Re: Usenet vs. Mailing-list

On 2023-01-28, Dennis Lee Bieber wrote: > On Sat, 28 Jan 2023 20:07:44 +, Chris Green declaimed the > following: > > >>As far as I am aware the mirroring of the Python mailing list on >>comp.lan.python works perfectly. I love gmane! :-) > > Is gmane's gmane.comp.python.general allowing

Re: Usenet vs. Mailing-list

On 2023-01-28, Chris Green wrote: > As far as I am aware the mirroring of the Python mailing list on > comp.lan.python works perfectly. I love gmane! :-) If gmane stopped working, I'd have to retire and give up on computers. I supposed I might be able to hammer procmail and mutt into something

Re: Usenet vs. Mailing-list

On 2023-01-29, Peter J. Holzer wrote: > On 2023-01-29 02:09:28 -, Jon Ribbens via Python-list wrote: >> I'm not aware of any significant period in the last twenty-one years >> that > [the gateway] >> hasn't been working. Although sometimes it does feel like it isn't, in >> that I reply to a po

Re: Usenet vs. Mailing-list

Igor Berger writes: > On Saturday, January 28, 2023 at 10:02:57 PM UTC-5, Ben Bacarisse wrote: >> Jon Ribbens writes: >> >> > On 2023-01-29, Ben Bacarisse wrote: >> >> "Peter J. Holzer" writes: >> >> >> >>> On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: >> mut...@dastardlyhq.com

Re: Usenet vs. Mailing-list

On Saturday, January 28, 2023 at 10:02:57 PM UTC-5, Ben Bacarisse wrote: > Jon Ribbens writes: > > > On 2023-01-29, Ben Bacarisse wrote: > >> "Peter J. Holzer" writes: > >> > >>> On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: > mut...@dastardlyhq.com writes: > > > Hi

Re: Usenet vs. Mailing-list

On 2023-01-29 02:09:28 -, Jon Ribbens via Python-list wrote: > I'm not aware of any significant period in the last twenty-one years > that [the gateway] > hasn't been working. Although sometimes it does feel like it isn't, in > that I reply to a post with an answer and then several other people

Re: Usenet vs. Mailing-list

Jon Ribbens writes: > On 2023-01-29, Ben Bacarisse wrote: >> "Peter J. Holzer" writes: >> >>> On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: mutt...@dastardlyhq.com writes: > Hi It looks like you posted this question via Usenet. comp.lang.python is essential

Re: Usenet vs. Mailing-list

On 2023-01-29, Ben Bacarisse wrote: > "Peter J. Holzer" writes: > >> On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: >>> mutt...@dastardlyhq.com writes: >>> >>> > Hi >>> >>> It looks like you posted this question via Usenet. comp.lang.python is >>> essentially dead as a Usenet group. It ex

Re: Usenet vs. Mailing-list

"Peter J. Holzer" writes: > On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: >> mutt...@dastardlyhq.com writes: >> >> > Hi >> >> It looks like you posted this question via Usenet. comp.lang.python is >> essentially dead as a Usenet group. It exists, and gets NNTP versions >> of mail sent to

Re: Usenet vs. Mailing-list

On Sun, 29 Jan 2023 at 12:07, Chris Green wrote: > > Chris Green wrote: > > Jon Ribbens wrote: > > > On 2023-01-28, Peter J. Holzer wrote: > > > > On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: > > > >> It looks like you posted this question via Usenet. comp.lang.python is > > > >> essenti

Re: Usenet vs. Mailing-list

On Sat, 28 Jan 2023 20:07:44 +, Chris Green declaimed the following: >As far as I am aware the mirroring of the Python mailing list on >comp.lan.python works perfectly. I love gmane! :-) Is gmane's gmane.comp.python.general allowing posts to go through again? I had to revert to com

Re: Usenet vs. Mailing-list

Chris Green wrote: > Jon Ribbens wrote: > > On 2023-01-28, Peter J. Holzer wrote: > > > On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: > > >> It looks like you posted this question via Usenet. comp.lang.python is > > >> essentially dead as a Usenet group. It exists, and gets NNTP versions

Re: Usenet vs. Mailing-list

Jon Ribbens wrote: > On 2023-01-28, Peter J. Holzer wrote: > > On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: > >> It looks like you posted this question via Usenet. comp.lang.python is > >> essentially dead as a Usenet group. It exists, and gets NNTP versions > >> of mail sent to the maili

Re: Usenet vs. Mailing-list (was: evaluation question)

On 2023-01-28, Peter J. Holzer wrote: > On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: >> It looks like you posted this question via Usenet. comp.lang.python is >> essentially dead as a Usenet group. It exists, and gets NNTP versions >> of mail sent to the mailing list, but nothing posted to

Re: Usenet vs. Mailing-list (was: evaluation question)

On Sat, 28 Jan 2023 15:30:59 +0100, "Peter J. Holzer" declaimed the following: >On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: >> mutt...@dastardlyhq.com writes: >> >> > Hi >> >> It looks like you posted this question via Usenet. comp.lang.python is >> essentially dead as a Usenet group.

Usenet vs. Mailing-list (was: evaluation question)

On 2023-01-27 21:04:58 +, Ben Bacarisse wrote: > mutt...@dastardlyhq.com writes: > > > Hi > > It looks like you posted this question via Usenet. comp.lang.python is > essentially dead as a Usenet group. It exists, and gets NNTP versions > of mail sent to the mailing list, but nothing posted

Re: How to fix Python error, The term '.../python.exe' is not recognized as the name of a cmdlet, function, script file, or operable program, in VS Code?

On Tue, 11 Oct 2022 16:40:31 -0700, LouisAden Capellupo declaimed the following: > So basically, I get, "The term '...\python.exe' is not recognized as the >name of a cmdlet, function, script, file, or operable program... At line: 1 >char: 3." It works the first way I showed with Code Runne

Re: How to fix Python error, The term '.../python.exe' is not recognized as the name of a cmdlet, function, script file, or operable program, in VS Code?

On 10/11/22, LouisAden Capellupo via Python-list wrote: > Variables. > C:\Users\It'sMeLil'Loui\AppData\Local\Programs\Python\Python310\Scripts\, > and C:\Users\It'sMeLil'Loui\AppData\Local\Programs\Python\Python310\. I suggest that you switch to a user account that doesn't have single quotes in

How to fix Python error, The term '.../python.exe' is not recognized as the name of a cmdlet, function, script file, or operable program, in VS Code?

Hi! I've just downloaded and installed Python 3.10.7 (64-bit) for Windows 10 from python.org. I'm quite new but, I've already downloaded and installed Visual Studio Code as well. I have included the two paths for python under User Variables.  C:\Users\It'sMeLil'Loui\AppData\Local\Programs\P

Re: python 3.10 vs breakage

On Fri, 26 Aug 2022 17:36:39 -0400, gene heskett declaimed the following: > >Bullseye is the current debian-11, buster is last years, bookworm is next. > >Linuxcnc builds just fine on armhf buster, with its python-3.9.4. fails >from 3.10 in bullseye. Pronterface.py can't find wxPython 4.0 or >g

  1   2   3   4   5   6   7   8   9   10   >