Re: permission denied using python 3.8
On 11/5/19, robin deatherage wrote: > > MS Windows uses a UAC User Control. So it is best to not add a package > to an Admin user on Windows. The OP would have to install Python in a location that that's inaccessible to standard users and add this directory to the system PATH. It's dysfunctional to add directories to the system PATH that do not grant read and execute access to standard users, so that would be a simple installation error. (Unlike Unix, Windows does not keep searching PATH until it finds a file that it's allowed to execute. It tries to execute the first match it finds, even if it's not permitted to do so.) Also, this does not explain why the 3.7 installation works, assuming the OP follows a similar installation procedure in that case. For both 3.7 and 3.8, we need to know how Python is executed, including the fully-qualified path of python.exe (e.g. from running `where.exe python`). Also, from an administrator command prompt, we need the discretionary access control list (DACL) of the Python installation directory and executable (e.g. `icacls.exe ""` and `icacls.exe "\python.exe"`). Also, from a standard command prompt, we need the current user's list of groups (e.g. `whoami.exe /groups /fo list`). > Also there is no limit to how many different versions of Python you use on > Windows---As long as you have a different UAC Control user logged in Windows > for each one you add. I have 2.75, 3.5, 3.6, 3.7.0 and now 3.8 on my Windows > now and all work fine. My user UAC logins may number five but that is is how > it is suppose to be done anyways in Windows. Each minor release of Python can be installed to the same user profile and/or the system profile, and you can even install both the 32-bit and 64-bit builds of a minor release. An installation can also be updated in place to a newer micro release (e.g. 3.7.4 -> 3.7.5) since minor releases guarantee ABI compatibility for extension modules. There's no conflict with other installed releases as long as we use the py.exe launcher to run a particular version (e.g. `py -3.7` and `py -3.7-32`) and associate .py scripts with the launcher and use shebangs (e.g. "#!python3.7" and "#!python3.7-32"). If you need multiple micro releases (e.g. 3.7, 3.7.1, 3.7.2, ...), on the other hand, it's probably for continuous-integration testing, for which you can use the provided nuget packages instead of a standard installation. -- https://mail.python.org/mailman/listinfo/python-list
Re: permission denied using python 3.8
On 11/5/19, robin deatherage wrote: > > MS Windows uses a UAC User Control. So it is best to not add a package > to an Admin user on Windows. The OP would have to install Python in a location that that's inaccessible to standard users and add this directory to the system PATH. It's dysfunctional to add directories to the system PATH that do not grant read and execute access to standard users, so that would be a simple installation error. (Unlike Unix, Windows does not keep searching PATH until it finds a file that it's allowed to execute. It tries to execute the first match it finds, even if it's not permitted to do so.) Also, this does not explain why the 3.7 installation works, assuming the OP follows a similar installation procedure in that case. For both 3.7 and 3.8, we need to know how Python is executed, including the fully-qualified path of python.exe (e.g. from running `where.exe python`). Also, from an administrator command prompt, we need the discretionary access control list (DACL) of the Python installation directory and executable (e.g. `icacls.exe ""` and `icacls.exe "\python.exe"`). Also, from a standard command prompt, we need the current user's list of groups (e.g. `whoami.exe /groups /fo list`). > Also there is no limit to how many different versions of Python you use on > Windows---As long as you have a different UAC Control user logged in Windows > for each one you add. I have 2.75, 3.5, 3.6, 3.7.0 and now 3.8 on my Windows > now and all work fine. My user UAC logins may number five but that is is how > it is suppose to be done anyways in Windows. Each minor release of Python can be installed to the same user profile and/or the system profile, and you can even install both the 32-bit and 64-bit builds of a minor release. An installation can also be updated in place to a newer micro release (e.g. 3.7.4 -> 3.7.5) since minor releases guarantee ABI compatibility for extension modules. There's no conflict with other installed releases as long as we use the py.exe launcher to run a particular version (e.g. `py -3.7` and `py -3.7-32`) and associate .py scripts with the launcher and use shebangs (e.g. "#!python3.7" and "#!python3.7-32"). If you need multiple micro releases (e.g. 3.7, 3.7.1, 3.7.2, ...), on the other hand, it's probably for continuous-integration testing, for which you can use the provided nuget packages instead of a standard installation. -- https://mail.python.org/mailman/listinfo/python-list
Re: What PEPs are worth reading after you've read a textbook/Beazley but want to understand details/innerworkings
Gilmeh Serda wrote: Can't wait until we get to PEP 84657675, or PEP 33 PEP TREE(3) promises to be even more exciting! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: OOP - how to abort an __init__ when the initialisation code fails ?
Peter J. Holzer wrote:
On 2019-11-04 18:18:39 -0300, Luciano Ramalho wrote:
In addition, as Rob said, it is usually a bad idea to wrap several
lines of code in a single try/except block
I disagree with this. While it is sometimes useful to wrap a single
line, in my experience it rarely is. The scope of the try ... except
should be a unit from a semantic point of view. For example, if you
open a file and write some data to it, you could write:
try:
f = open("a.file", "w")
except OSError as e:
... handle exception
try:
f.write("some")
except OSError as e:
... handle exception
try:
f.write("data")
except OSError as e:
... handle exception
try:
close(f)
except OSError as e:
... handle exception
But not only is this hard to read and ugly as heck, what would be the
point?
Much better to write:
try:
with open("a.file", "w") as f:
f.write("some")
f.write("data")
except OSError as e:
... handle exception
Or maybe don't catch it here at all but just let it bubble up until it
hits a level where dealing with it makes sense from the user's point of
view
Often it makes sense to do both -- catch the exception and
re-raise it with a more informative error message, e.g.
try:
with open(filename, "w") as f:
f.write("some")
f.write("data")
except OSError as e:
raise OSError("Couldn't write fibble data to %s: %s" % (filename, e))
That way you don't get frustrating Microsoft style error
messages which say "The system could not open the specified file"
while giving no clue about *which* file was specified... aarggh!
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: OOP - how to abort an __init__ when the initialisation code fails ?
On 11/5/19 11:52 AM, Peter J. Holzer wrote:
On 2019-11-04 18:18:39 -0300, Luciano Ramalho wrote:
In addition, as Rob said, it is usually a bad idea to wrap several
lines of code in a single try/except block
I disagree with this. While it is sometimes useful to wrap a single
line, in my experience it rarely is. The scope of the try ... except
should be a unit from a semantic point of view. For example, if you
open a file and write some data to it, you could write:
try:
f = open("a.file", "w")
except OSError as e:
... handle exception
try:
f.write("some")
except OSError as e:
... handle exception
try:
f.write("data")
except OSError as e:
... handle exception
try:
close(f)
except OSError as e:
... handle exception
But not only is this hard to read and ugly as heck, what would be the
point?
Much better to write:
try:
with open("a.file", "w") as f:
f.write("some")
f.write("data")
except OSError as e:
... handle exception
Or maybe don't catch it here at all but just let it bubble up until it
hits a level where dealing with it makes sense from the user's point of
view (who may not care about an individual file, but about the task they
instructed the program to perform).
hp
I mean, you sort of want "the right amount of stuff" in a try block. Lines that
may exhibit a common failure, that you want to route to a common exception
handler go into the same try block (per your example above). Things that are
going to raise unrelated errors for unrelated reasons should be in different try
blocks. Code that should only execute if the try block was error-free, but that
you expect to not be able to raise errors itself, should go into the else block.
Like most of programming, hard-and-fast rules turn out to be impossible.
Reality has squishy edges.
--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order. See above to fix.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Pip not available
On 11/5/2019 5:22 AM, Ethan Woo wrote: [image: image.png] This, like most PSF lists, is text only. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: permission denied using python 3.8
On 11/5/2019 12:26 PM, robin deatherage wrote: Also there is no limit to how many different versions of Python you use on Windows---As long as you have a different UAC Control user logged in Windows for each one you add. I have 2.75, 3.5, 3.6, 3.7.0 and now 3.8 on my Windows now and all work fine. My user UAC logins may number five but that is is how it is suppose to be done anyways in Windows. No it is not. I and many people have multiple versions of versions of Python on one user account installed either for just that user or for all users. The latter requires admin access. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: How execute at least two python files at once when imported?
On 11/5/2019 1:33 PM, Spencer Du wrote: I want to execute at least two python files at once when imported but I dont know how to do this. Currently I can only import each file one after another but what i want is each file to be imported at the same time. Can you help me write the code for this? embedded.py is the main file to execute. [snip about 150 lines of example code] We don't understand what you mean other than something impossible. Your example code iswa ytoo long. It should be the minimum needed to illustrate the idea. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: OOP - how to abort an __init__ when the initialisation code fails ?
On 2019-11-04 18:18:39 -0300, Luciano Ramalho wrote:
> In addition, as Rob said, it is usually a bad idea to wrap several
> lines of code in a single try/except block
I disagree with this. While it is sometimes useful to wrap a single
line, in my experience it rarely is. The scope of the try ... except
should be a unit from a semantic point of view. For example, if you
open a file and write some data to it, you could write:
try:
f = open("a.file", "w")
except OSError as e:
... handle exception
try:
f.write("some")
except OSError as e:
... handle exception
try:
f.write("data")
except OSError as e:
... handle exception
try:
close(f)
except OSError as e:
... handle exception
But not only is this hard to read and ugly as heck, what would be the
point?
Much better to write:
try:
with open("a.file", "w") as f:
f.write("some")
f.write("data")
except OSError as e:
... handle exception
Or maybe don't catch it here at all but just let it bubble up until it
hits a level where dealing with it makes sense from the user's point of
view (who may not care about an individual file, but about the task they
instructed the program to perform).
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | h...@hjp.at |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: Friday finking: TDD and EAFP
> On 1 Nov 2019, at 05:40, DL Neil via Python-list > wrote: > > Is the practice of TDD fundamentally, if not philosophically, somewhat > contrary to Python's EAFP approach? > > > TDD = Test-Driven Development > EAFP = it's easier to ask forgiveness than permission > * WebRefs as footnote > > > The practice of TDD* is that one writes test routines to prove a unit of > code, eg method or function; BEFORE actually writing said function. > > The rationale is that TDD encourages proper identification and consideration > of the routine's specification, and attempts to ensure that exceptions and > "edge-cases" are not quietly forgotten. > (in a broad-brush, nut-shell) The practice of creating software is a social activity where those involved have foibles. Managing all the social interactions and foibles is what the methodologies are trying to help with. Any methodology that is easier to follow then avoid will tend to be taken up and provide a benefit. We all know that tests are a must have, but often those tests that we all know are a must have do not get written. It can often seem like a chore, after all the code works right? By starting with the tests the social engineering means that you make having the tests the easy part of the process. Methodologies like Agile address other foibles. Given a far off dead line the tendency is to delay getting the bulk of the work done until at the last moment. So is TDD contrary to EAFP? Not as such its two sorts of social engineering. TDD helps get the tests, EAPF give permission to take risks, necessary to innovate. Barry > > However, I quite possibly like yourself, come from a time-before - before > TDD, and before Python. So, have had to not only learn these things, but > sometimes, un-learn points and habits (if not vices). Accordingly, I came > (quite unknowing of the term, or that there might be an alternative) from the > world of LBYL* (look before you leap). > > In other words, before you do anything with some data, check that it is what > you think it is. Whereas in Python we "try" by assuming everything is > compos-mentis* and handle the "except" when things are not how we'd like. > > That adaptation was not too difficult. After all, aren't programmers an > optimistic bunch - I mean, I *never* introduce bugs into *my* code! Do you? > > Which brings us to TDD. Here we assume the likelihood of bugs, as-if (cue: > manic giggling); and code a bunch of tests first - in an attempt to prove > that the code is up-to-spec. > > In encouraging my mind to think about testing the code, I find myself > searching for edge-cases, and attempting to anticipate the unusual. > Accordingly to the gospel of TDD: so far, so good. > > The 'problem' is, that it puts my mind onto LBYL-rails before the > Python-coding train (of thought) has even left the station. It then seems > natural to start putting a bunch of if-then-else's up-front and before the > 'main line' of code. > > Does TDD bend your mind in this (apparently) non-Pythonic fashion? > Have you developed an answer? > (other than: "@dn is 'nuts'*", which is not worthy of debate) > > > WebRefs: > https://duckduckgo.com/?q=TDD&ia=web > https://devblogs.microsoft.com/python/idiomatic-python-eafp-versus-lbyl/ > https://docs.python.org/3/glossary.html#term-eafp > but: https://mail.python.org/pipermail/python-dev/2014-March/133118.html > https://docs.python.org/3/glossary.html#term-lbyl > Latin/legal term "compos mentis" > https://www.thefreedictionary.com/compos+mentis > English slang term "nuts": https://www.thefreedictionary.com/nuts > -- > Regards, > =dn > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: How execute at least two python files at once when imported?
On 05/11/2019 18:33, Spencer Du wrote: I want to execute at least two python files at once when imported but I dont know how to do this. Currently I can only import each file one after another but what i want is each file to be imported at the same time. That is a very odd requirement. Why would you want to do this? What exactly does "at the same time" mean here? -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: How execute at least two python files at once when imported?
On Nov 5, 2019 1:35 PM, "Spencer Du" wrote: > > Hi > > I want to execute at least two python files at once when imported but I dont know how to do this. Currently I can only import each file one after another but what i want is each file to be imported at the same time. Can you help me write the code for this? Please explain what you mean by "imported at the same time". As far as I know that is physically impossible. -- https://mail.python.org/mailman/listinfo/python-list
Aw: How execute at least two python files at once when imported?
> I want to execute at least two python files at once when imported but I dont > know how to do this. > Currently I can only import each file one after another but what i want is > each file to be imported > at the same time. Can you explain why that seems necessary ? Karsten -- https://mail.python.org/mailman/listinfo/python-list
How execute at least two python files at once when imported?
Hi
I want to execute at least two python files at once when imported but I dont
know how to do this. Currently I can only import each file one after another
but what i want is each file to be imported at the same time. Can you help me
write the code for this? embedded.py is the main file to execute.
embedded.py
import paho.mqtt.client as mqtt
from mqtt2 import *
import os
import time
import json
import configparser
from threading import Thread
def start():
try:
os.remove("list_of_device(s)_currently_active.txt")
os.remove("laser.ini")
print("Awaiting device(s) to be activated")
except:
print("Awaiting device(s) to be activated")
start()
devices = list(map(str,input("Device(s) to be activated: ").split(",")))
client = embedded()
client.run()
client.loop_start()
print("Connected to broker")
time.sleep(1)
print("Subscribing to topic", "microscope/light_sheet_microscope/UI")
client.subscribe("microscope/light_sheet_microscope/UI")
print("Publishing message to topic", "microscope/light_sheet_microscope/UI")
client.publish("microscope/light_sheet_microscope/UI", json.dumps({"type":
"system", "payload":{"name": devices, "cmd": "activating device(s)"}},
indent=2))
time.sleep(1)
def active_devices():
for item in devices:
device = (item + "Embedded")
deviceImport = __import__(device)
with open("list_of_device(s)_currently_active.txt", "a+") as myfile:
for item in devices:
myfile.write(item + "\n")
active_devices()
def readFile(fname):
print("List of device(s) currently active:")
try:
with open(fname, "r") as f:
for item in f:
print(item.rstrip("\n"))
except:
print("No device(s) added yet")
readFile("list_of_device(s)_currently_active.txt")
# print("Connected to broker")
# time.sleep(1)
# client.subscribe("microscope/light_sheet_microscope/UI/laser/#")
# if os.path.exists:
# parser = configparser.ConfigParser()
# parser.read("laser.ini")
# try:
# subscriptions = dict(parser.items("Subscriptions"))
# print("Subscribing to topics", subscriptions)
# client.subscribe(subscriptions)
# except:
# pass
# else:
# pass
client.loop_forever()
laserEmbedded.py
import random
import asyncio
from actorio import Actor, Message, DataMessage, ask, EndMainLoop, Reference
from mqtt2 import *
class Laser(Actor):
async def handle_message(self, message: Message):
print("Laser")
await asyncio.sleep(2)
print("Unitialised")
await asyncio.sleep(2)
print("Initialising")
await asyncio.sleep(2)
print("Initialised")
await asyncio.sleep(2)
print("Configuring")
await asyncio.sleep(2)
print("Configured")
await asyncio.sleep(2)
await message.sender.tell(DataMessage(data="Hello World Im a laser!" +
"\n", sender=self))
async def main():
# Let's create an instance of a Greeter actor and start it.
async with Laser() as laser:
# Then we'll just send it an empty message and wait for a response
reply : DataMessage = await ask(laser, Message())
print(reply.data)
asyncio.get_event_loop().run_until_complete(main())
def subscribe():
client = embedded()
client.run()
client.loop_start()
client.subscribe("microscope/light_sheet_microscope/UI/laser/#")
subscribe()
camerasEmbedded.py
import random
import asyncio
from actorio import Actor, Message, DataMessage, ask, EndMainLoop, Reference
class Cameras(Actor):
async def handle_message(self, message: Message):
print("Cameras")
await asyncio.sleep(2)
print("Unitialised")
await asyncio.sleep(2)
print("Initialising")
await asyncio.sleep(2)
print("Initialised")
await asyncio.sleep(2)
print("Configuring")
await asyncio.sleep(2)
print("Configured")
await asyncio.sleep(2)
await message.sender.tell(DataMessage(data="Hello World Im a camera!" +
"\n", sender=self))
async def main():
# Let's create an instance of a Greeter actor and start it.
async with Cameras() as cameras:
# Then we'll just send it an empty message and wait for a response
reply : DataMessage = await ask(cameras, Message())
print(reply.data)
asyncio.get_event_loop().run_until_complete(main())
filterwheelEmbedded.py
import random
import asyncio
from actorio import Actor, Message, DataMessage, ask, EndMainLoop, Reference
class FW(Actor):
async def handle_message(self, message: Message):
print("Filter wheel")
await asyncio.sleep(2)
print("Unitialised")
await asyncio.sleep(2)
print("Initialising")
await asyncio.sleep(2)
print("Initialised")
await asyncio.sleep(2)
print("Configuring")
await asyncio.sleep(2)
print("Configured")
await asyncio.sleep(2)
Re: permission denied using python 3.8
On Tuesday, November 5, 2019 at 10:06:49 AM UTC+8, Francois van Lieshout wrote: > Hi, i installed python 3.8 the latest version but it doesn’t work, i get > “permission denied” when trying to acces python in the CLI and also i can’t > run my code from my python files in the command-line nor in IDLE. I’d like to > know why this is so. I’ve tried the 64 bit and the 32 bit executable version > of 3.8 but without succes. So i reinstalled version 3.7.2 and now everything > works fine again. > > Can you tell me why i can’t use python 3.8, i’m using windows as OS. YES---MS Windows uses a UAC User Control. So it is best to not add a package to an Admin user on Windows. Now in answer to this question first either your python interpreter remained in the system32 directory or you have an installed software using another version of an interpreter also located in the system directory interfering. And as pointed out with the UAC User Control on Windows. Log out of the current Windows User or Admin. Log into another Windows new user and add a different version of Python. But if you installed any Python in the Admin you will have to delete all traces of Python and or any interpreters to do so. Also there is no limit to how many different versions of Python you use on Windows---As long as you have a different UAC Control user logged in Windows for each one you add. I have 2.75, 3.5, 3.6, 3.7.0 and now 3.8 on my Windows now and all work fine. My user UAC logins may number five but that is is how it is suppose to be done anyways in Windows. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there some python libary for edit iso file drectly?
On Tuesday, November 5, 2019 at 7:11:30 AM UTC+8, Hongyi Zhao wrote: > Is there some python libary for edit iso file drectly? You can use batch .bat files and have Python execute them. Honestly Batch will do all you are asking on MS Windows. Use its XCOPY to copy the IO file or the entire IO Directory, move or copy it to another directory as a non IO. Then have the batch make changes to the file then save it where and as you wish back to an IO. -- https://mail.python.org/mailman/listinfo/python-list
Re: Pip not available
Ethan Woo writes: > I was using Python 3.7.4 for a project, and I needed to install the > *playsound* function. I looked through online and saw that I needed to use > pip. However, it didn't work. I looked online and saw that I needed to > install it through the application, however, now this problem pops up. > [image: image.png] > Can you help me with this? > python3 -m pip install -- Pankaj Jangid -- https://mail.python.org/mailman/listinfo/python-list
Re: __instancecheck__ metaclasses, how do they work: why do I get True when I tuple, why doesn't print run?
Chris Angelico writes:
> On Tue, Nov 5, 2019 at 5:43 PM dieter wrote:
>> I suppose that "isinstance" (at least under Python 2) does not
>> behave exactly as stated in PEP 3119. Instead, "isinstance"
>> first directly checks for the instance to be an instance of the
>> class *AND ONLY IF THIS FAILS* calls the class' "__instancecheck__".
>
> PEP 3119 is specifically about Python 3.0; I don't know how much, if
> any, was backported into Python 2.
Yes, it has been there since Python 2.6.
I looked in the implementation, and isinstance(inst, cls) first checks if the
class of ins is cls, then the result is True.
There are a few other shortcut cases, and only at the end the __instancecheck__
method is called.
You can check this with the original example:
In [88]: class MA(type):
...: def __instancecheck__(cls, inst):
...: print "MA", cls, inst
...:
...: class AM(list): __metaclass__ = MA
...: class AM2(AM): pass
...:
...: am = AM2()
In [89]: isinstance(am, AM)
MA []
Out[89]: False
It returns False because __instancecheck__ returns None
Same for Python3:
In [8]: class MA(type):
...: def __instancecheck__(cls, inst):
...: print ("MA", cls, inst)
...:
...: class AM(list, metaclass = MA): pass
...: class AM2(AM): pass
...:
...: am = AM2()
In [9]: isinstance(am, AM)
MA []
Out[9]: False
--
Pieter van Oostrum
WWW: http://pieter.vanoostrum.org/
PGP key: [8DAE142BE17999C4]
--
https://mail.python.org/mailman/listinfo/python-list
Pip not available
Dear person reading this, I was using Python 3.7.4 for a project, and I needed to install the *playsound* function. I looked through online and saw that I needed to use pip. However, it didn't work. I looked online and saw that I needed to install it through the application, however, now this problem pops up. [image: image.png] Can you help me with this? *P.S. I am a schoolkid who needs some help, not very experienced.* -- https://mail.python.org/mailman/listinfo/python-list
Re: Is there some python libary for edit iso file drectly?
On 2019-11-05, Michael Torrie wrote: > On 11/4/19 4:11 PM, Hongyi Zhao wrote: >> Is there some python libary for edit iso file drectly? > > Isn't an ISO image a read-only sort of thing? Yes. > If you want to modify files don't you have to create a whole new > image? Yes. "Edit an ISO image" comprises the following steps. 1. Mount the ISO image[*]. 2. Copy the tree of files to a read-write filesystem. 3. Change the files in the read-write filesystem. 4. Create a new ISO image from the read-write filesystem. [*] IIRC, there are utilities that allow you to combine steps 1-2 into a single step: "Extract files from ISO image into a read-write filesystem". But, I can't ever remember how to do that, so I just do the two steps. -- Grant Edwards grant.b.edwardsYow! I invented skydiving at in 1989! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: __instancecheck__ metaclasses, how do they work: why do I get True when I tuple, why doesn't print run?
On 04/11/2019 22:23, Peter J. Holzer wrote: On 2019-11-04 14:54:23 +, Rhodri James wrote: On 04/11/2019 14:33, Veek M wrote: __metaclass__ = whatever; # is python2.x syntax But not Python3: see PEP 3115 Doesn't "X is python2.x syntax" imply "X is not python3 syntax"? Not necessarily, the OP might have (and apparently was) assuming that it was also Python3 syntax. Also it gave me an opportunity to point him to the appropriate PEP. That said, we've reached the limits of my knowledge here and I'm bowing out of the discussion. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: OOP - how to abort an __init__ when the initialisation code fails ?
On Tue, Nov 5, 2019 at 8:46 PM R.Wieser wrote: > > Chris, > > > "Control flow" is anything that changes the order that your code runs. > > My apologies, I should have said "a control flow mechanism" /in this > context/ (though I assumed that as implicite, as I quoted the text from the > OP). > > Case in point, the __init__ code (of a class object) can result in an > exception, and I need to deal with it. But I should /not/ wrap whole blocks > of code into a "try ... except" construction - which definitily is what will > happen when I want to catch, in the calling program, exceptions thrown by > the object while its initialising. > > So, I was wondering if the "a control flow mechanism" reference was aimed at > something that would alleviate the above "you must, but you shouldn't" > conundrum. > Gotcha. The usual solution to this conundrum is a specific exception. You don't have to catch all arbitrary exceptions that might be thrown; you can define your own custom exception and catch only that. That way, you can use "raise SomeSpecificException" as a form of control flow, without disrupting the ability to detect other sorts of errors. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: OOP - how to abort an __init__ when the initialisation code fails ?
Chris, > "Control flow" is anything that changes the order that your code runs. My apologies, I should have said "a control flow mechanism" /in this context/ (though I assumed that as implicite, as I quoted the text from the OP). Case in point, the __init__ code (of a class object) can result in an exception, and I need to deal with it. But I should /not/ wrap whole blocks of code into a "try ... except" construction - which definitily is what will happen when I want to catch, in the calling program, exceptions thrown by the object while its initialising. So, I was wondering if the "a control flow mechanism" reference was aimed at something that would alleviate the above "you must, but you shouldn't" conundrum. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list
