Re: how to discover what values produced an exception?

On Tue, 7 May 2024 at 03:38, Alan Bawden via Python-list wrote: > A good error message shouldn't withhold any information that can > _easily_ be included. Debugging is more art than science, so there is > no real way to predict what information might prove useful in solving > the crime. I emphas

Re: how to discover what values produced an exception?

local variables etc.) It's tedious and prone to errors. So, if you really want to do this automatically for every error that's going to be quite a bit of work. On Fri, May 3, 2024 at 6:58 PM Johanne Fairchild via Python-list wrote: > > How to discover what values produced an excepti

Re: how to discover what values produced an exception?

Thomas Passin writes: On 5/3/2024 9:56 AM, Johanne Fairchild via Python-list wrote: > How to discover what values produced an exception? Or perhaps---why > doesn't the Python traceback show the values involved in the TypeError? > For instance:

Re: how to discover what values produced an exception?

On 2024-05-03 at 10:56:39 -0300, Johanne Fairchild via Python-list wrote: > How to discover what values produced an exception? Or perhaps---why > doesn't the Python traceback show the values involved in the TypeError? > For inst

Re: how to discover what values produced an exception?

Johanne Fairchild wrote at 2024-5-3 10:56 -0300: >How to discover what values produced an exception? Or perhaps---why >doesn't the Python traceback show the values involved in the TypeError? >For instance: > >--8<-

Re: how to discover what values produced an exception?

On 5/3/2024 9:56 AM, Johanne Fairchild via Python-list wrote: How to discover what values produced an exception? Or perhaps---why doesn't the Python traceback show the values involved in the TypeError? For instance: --8<>8---

how to discover what values produced an exception?

How to discover what values produced an exception? Or perhaps---why doesn't the Python traceback show the values involved in the TypeError? For instance: --8<>8--- >>> (0,0) < 4 Traceback (most recent call last)

How to get insight in the relations between tracebacks of exceptions in an exception-chain

Hi, This question is best introduced example-first: Consider the following trivial program: ``` class OriginalException(Exception): pass class AnotherException(Exception): pass def raise_another_exception(): raise AnotherException() def show_something(): try: raise

Re: Too Broad of an exception

On 10/26/23 03:04, Rene Kita via Python-list wrote: Rene Kita wrote: rsutton wrote: Hi all, I am fairly new to python (ie < 2 years). I have a question about pylint. I am running on windows 10/11, python 3.10.11. [...] if p.returncode >= 8: raise Exception(f&#

Re: Too Broad of an exception

Rene Kita wrote: > rsutton wrote: >> Hi all, >> I am fairly new to python (ie < 2 years). I have a question about >> pylint. I am running on windows 10/11, python 3.10.11. > [...] >> if p.returncode >= 8: >> raise Exception(f&

Re: Too Broad of an exception

On 26/10/2023 04.49, rsutton via Python-list wrote: On 10/25/2023 11:06 AM, Stefan Ram wrote: r...@zedat.fu-berlin.de (Stefan Ram) writes: outer quotation marks) prints some prominent exception types. After ...    "Manually removing" above was meant to be a fast first pass,    wh

Re: Too Broad of an exception

On 10/25/2023 11:49 AM, rsutton via Python-list wrote: On 10/25/2023 11:06 AM, Stefan Ram wrote: r...@zedat.fu-berlin.de (Stefan Ram) writes: outer quotation marks) prints some prominent exception types. After manually removing those that do not seem to apply, I am left with: "Assertion

Re: Too Broad of an exception

On Wed, Oct 25 2023 at 11:49:12 AM, rsutton wrote: > On 10/25/2023 11:06 AM, Stefan Ram wrote: >> r...@zedat.fu-berlin.de (Stefan Ram) writes: >>> outer quotation marks) prints some prominent exception types. After >>> manually removing those that do not se

Re: Too Broad of an exception

On 10/25/2023 11:06 AM, Stefan Ram wrote: r...@zedat.fu-berlin.de (Stefan Ram) writes: outer quotation marks) prints some prominent exception types. After manually removing those that do not seem to apply, I am left with: "AssertionError", "ChildProcessError", ... "

Too Broad of an exception

# this is necessary because Windows Robocopy returns # various return codes for success. if p.returncode >= 8: raise Exception(f'Invalid result: {p.returncode}') It actually runs fine. But pylint is not having it. I get: win_get_put_tb_filters.py

Re: Too Broad of an exception

rsutton wrote: > Hi all, > I am fairly new to python (ie < 2 years). I have a question about > pylint. I am running on windows 10/11, python 3.10.11. [...] > if p.returncode >= 8: > raise Exception(f'Invalid result: {p.returncode}') > &g

Re: Why do I always get an exception raised in this __init__()?

Alan Gauld wrote: > On 31/08/2023 22:15, Chris Green via Python-list wrote: > > > class Gpiopin: > > > > def __init__(self, pin): > > # > > # > > # scan through the GPIO chips to find the line/pin we want > > # > > for

Re: Why do I always get an exception raised in this __init__()?

On 31/08/2023 22:15, Chris Green via Python-list wrote: > class Gpiopin: > > def __init__(self, pin): > # > # > # scan through the GPIO chips to find the line/pin we want > # > for c in ['gpiochip0', 'gpiochip1', 'gpioch

Re: Why do I always get an exception raised in this __init__()?

On Thu, Aug 31, 2023 at 3:19 PM Chris Green via Python-list wrote: > > I'm obviously doing something very silly here but at the moment I > can't see what. > > Here's the code:- > > #!/usr/bin/python3 > # > # > # GPIO > # > import gpiod > # > # > # Simple wrapper

Why do I always get an exception raised in this __init__()?

I'm obviously doing something very silly here but at the moment I can't see what. Here's the code:- #!/usr/bin/python3 # # # GPIO # import gpiod # # # Simple wrapper class for gpiod to make set and clearing outputs easier # class Gpiopin:

Re: Why do I always get an exception raised in this __init__()?

Chris Green wrote: [snip code and question] Sorry folks, it was a caching problem, I wasn't running the code I thought I was running! When I made sure I had cleared everything out and tried again it all worked as I expected. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python

Re: What sort of exception when a class can't find something?

Several helpful replies, thank you all. -- Chris Green · -- https://mail.python.org/mailman/listinfo/python-list

Re: What sort of exception when a class can't find something?

On Fri, 1 Sept 2023 at 06:39, Chris Green via Python-list wrote: > > What sort of exception should a class raise in __init__() when it > can't find an appropriate set of data for the parameter passed in to > the class instantiation? > > E.g. I have a database with some n

Re: What sort of exception when a class can't find something?

On 2023-08-31 21:32:04 +0100, Chris Green via Python-list wrote: > What sort of exception should a class raise in __init__() when it > can't find an appropriate set of data for the parameter passed in to > the class instantiation? > > E.g. I have a database with some names and

What sort of exception when a class can't find something?

What sort of exception should a class raise in __init__() when it can't find an appropriate set of data for the parameter passed in to the class instantiation? E.g. I have a database with some names and address in and have a class Person that gets all the details for a person given their

Re: WHAT THIS EXCEPTION MEANT? I ATTCHED SCREENSOHT

On 9/8/22 06:34, נתי שטרן wrote: [image: image.png] The mailing list strips attachments, replacing them by a placeholder as you see above. If you want to try again, please paste the text of the exception. -- https://mail.python.org/mailman/listinfo/python-list

RE: WHAT THIS EXCEPTION MEANT? I ATTCHED SCREENSOHT

Nati, If you thought a bit first, you might remember this mailing list does not forward attachments so we are not seeing the image you called image.png and you neglected to also give us some text telling us what exception you saw or lots of additional details that might help. And, just FYI

WHAT THIS EXCEPTION MEANT? I ATTCHED SCREENSOHT

[image: image.png] -- -- https://mail.python.org/mailman/listinfo/python-list

Re: matplotlib basemap colorbar exception : Given element not contained in the stack

在 2022年5月30日星期一 UTC+8 03:29:28， 写道： > On 2022-05-29 13:57, iMath wrote: > > please see the formated code at > > https://stackoverflow.com/questions/72423464/matplotlib-basemap-colorbar-exception-given-element-not-contained-in-the-stack > The problem might be that you're pa

Re: matplotlib basemap colorbar exception : Given element not contained in the stack

On 2022-05-29 13:57, iMath wrote: please see the formated code at https://stackoverflow.com/questions/72423464/matplotlib-basemap-colorbar-exception-given-element-not-contained-in-the-stack The problem might be that you're passing "ax=self.ax" when you create the basema

Re: matplotlib basemap colorbar exception : Given element not contained in the stack

please see the formated code at https://stackoverflow.com/questions/72423464/matplotlib-basemap-colorbar-exception-given-element-not-contained-in-the-stack -- https://mail.python.org/mailman/listinfo/python-list

Re: RuntimeError, or user defined exception

creating two exception classes for >this? You could reuse TimeoutError, a builtin exception raised by OS calls which time out: https://docs.python.org/3/library/exceptions.html#TimeoutError I wouldn't use RuntimeError. Its core purpose is interpreter failures IIRC, and I use it myself

RuntimeError, or user defined exception

I am creating a class that will call a user defined function on user defined intervals. In my opinion it is an error when the function takes more as 10% of interval, or more as half a second. What is better: just using RuntimeError, or creating two exception classes for this? -- Cecil Westerhof

Re: Log exception so traceback contains timestamp and level?

On 07/02/2021 16:12, Peter J. Holzer wrote: On 2021-02-06 21:01:37 -0600, Skip Montanaro wrote: The logging package can log exceptions and call stacks, but it does (in my opinion) a suboptimal job of it. Consider this simple example: import logging FORMAT = '%(asctime)-15s %(levelname)s %(messa

Re: Log exception so traceback contains timestamp and level?

On 2021-02-06 21:01:37 -0600, Skip Montanaro wrote: > The logging package can log exceptions and call stacks, but it does > (in my opinion) a suboptimal job of it. Consider this simple example: > >>> import logging > >>> FORMAT = '%(asctime)-15s %(levelname)s %(message)s' > >>> logging.basicConfig(

Log exception so traceback contains timestamp and level?

e formatStack or formatException, then construct the individual lines of output, set handler and formatter, blah blah blah. I'm pretty sure I've done this in the past by writing my own little log_exception method which formats the exception and calls log.error for each row of the traceback.

Re: Having trouble with Mock and exception side effects

You could attempt something like what is mentioned in https://docs.python.org/3/library/unittest.mock-examples.html#partial-mocking See below. "Joshua J. Kugler" writes: > Hello! I am using Mock to raise an exception in an function as a side > effect. > However,

Having trouble with Mock and exception side effects

Hello! I am using Mock to raise an exception in an function as a side effect. However, Mock is completely redefining the exception itself turning it in to a MagickMock object, which generates the Python exception TypeError: catching classes that do not inherit from BaseException is not

Re: ElementNotInteracable Exception for Selenium Chrome webdriver

emagnun writes: > I'm using latest python and latest Selenium chrome webdriver. I'm > trying to have a simple code to search in youtube but I'm getting the > below error. Can anyone help me? > > File "search.py", line 8, in searchBox.click() > Selenium.common.exceptions.ElementNotInteractableExce

ElementNotInteracable Exception for Selenium Chrome webdriver

I'm using latest python and latest Selenium chrome webdriver. I'm trying to have a simple code to search in youtube but I'm getting the below error. Can anyone help me? File "search.py", line 8, in searchBox.click() Selenium.common.exceptions.ElementNotInteractableException: Message: element

Re: How to cover connection exception errors, and exit

w do I trap this error, without invoking adapters.py? If requests catches the error -- I don't know. If you fail to catch the error in your code -- what happens if you use a bare except? Like try: ... # your code except: print(sys.exc_info()) This should print the type of exc

How to cover connection exception errors, and exit

ptions.Timeout as errt: print ("Timeout Error:",errt) except requests.exceptions.RequestException as err: print ("OOps: Something Else",err) It seems like the error should be trapped by the exception above requests.exceptions.ConnectionError, but

Re: Make warning an exception?

On 7/12/19 9:58 AM, Israel Brewster wrote: I was running some code and I saw this pop up in the console: 2019-12-06 11:53:54.087 Python[85524:39651849] WARNING: nextEventMatchingMask should only be called from the Main Thread! This will throw an exception in the future. The only problem is

Re: Make warning an exception?

On 12/6/19 12:58 PM, Israel Brewster wrote: I was running some code and I saw this pop up in the console: 2019-12-06 11:53:54.087 Python[85524:39651849] WARNING: nextEventMatchingMask should only be called from the Main Thread! This will throw an exception in the future. The only problem is

Make warning an exception?

I was running some code and I saw this pop up in the console: 2019-12-06 11:53:54.087 Python[85524:39651849] WARNING: nextEventMatchingMask should only be called from the Main Thread! This will throw an exception in the future. The only problem is, I have no idea what is generating that

Re: Exception

Le 24/09/2019 à 15:51, אורי a écrit : https://stackoverflow.com/a/24752607/1412564 thank you for link. it's clear now -- https://mail.python.org/mailman/listinfo/python-list

Re: Exception

() > Traceback (most recent call last): >File "", line 3, in func > ZeroDivisionError: division by zero > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): >File "", line 1, in >File &

RE: Exception

I believe the idea is that previously, if you were handling an exception, and your handling code caused its own exception, then you would get no info about the original exception. So all useful information about the original problem would get lost because of an oopsie in the handling code. So

Exception

1 / 0 ... except ZeroDivisionError: ... raise ArithmeticError ... >>> func() Traceback (most recent call last): File "", line 3, in func ZeroDivisionError: division by zero During handling of the above exception, another exception occurred: Traceback (most recent call

Re: Only a message at the highest exception

gt; in a try block calls the function append_row. This function has also a >>>> try block. When they get an exception they give message. But when >>>> append_row has already given a message then generate_report should >>>> not. To implement this I use the

Re: Only a message at the highest exception

exception they give message. But when append_row has already given a message then generate_report should not. To implement this I use the following class: class AlreadyHandledException(Exception): pass Then in append_row I have: except Exception as err

Re: Only a message at the highest exception

Chris Angelico writes: > On Fri, Jun 28, 2019 at 7:33 PM Cecil Westerhof wrote: >> >> I have a tkinter program where I have a function generate_report which >> in a try block calls the function append_row. This function has also a >> try block. When they get an excep

Re: Only a message at the highest exception

On Fri, Jun 28, 2019 at 7:33 PM Cecil Westerhof wrote: > > I have a tkinter program where I have a function generate_report which > in a try block calls the function append_row. This function has also a > try block. When they get an exception they give message. But when > append_

Only a message at the highest exception

I have a tkinter program where I have a function generate_report which in a try block calls the function append_row. This function has also a try block. When they get an exception they give message. But when append_row has already given a message then generate_report should not. To implement this

Re: FDs will be closed after exception automatically in python2.7?

D'Arcy Cain writes: > On 2019-06-10 15:46, Alan Bawden wrote: > > D'Arcy Cain writes: > >> with open("file","w+") as fd: > > > > That makes the window smaller, but it doesn't actually eliminate it. Look > > at the generated byte code. In both cases the call to open() is over and > > the open f

Re: FDs will be closed after exception automatically in python2.7?

On 2019-06-10 15:46, Alan Bawden wrote: > D'Arcy Cain writes: >> with open("file","w+") as fd: > > That makes the window smaller, but it doesn't actually eliminate it. Look > at the generated byte code. In both cases the call to open() is over and > the open file is created _before_ the SETUP_W

Re: FDs will be closed after exception automatically in python2.7?

D'Arcy Cain writes: > On 2019-06-10 10:48, Michael Torrie wrote: > > fd = open("file","w+") > > with fd: > > There is still a small window there if there are asynchronous events > happening. Use this instead: > > with open("file","w+") as fd: That makes the window smaller, but it doesn't actua

Re: FDs will be closed after exception automatically in python2.7?

On 2019-06-10 10:48, Michael Torrie wrote: > Probably you should be using Python 3, which uses a print() function. > But even in Python 2.7, the recommended way to do this is like this: > > fd = open("file","w+") > with fd: There is still a small window there if there are asynchronous events happ

Re: FDs will be closed after exception automatically in python2.7?

On 06/10/2019 04:18 AM, lampahome wrote: > as title, > > I confused will fd will be close after exception automatically? > Like: > try: > fd=open("file","w+") > fd.get() //any useless function of fd > except Exception: > print 'h

Re: FDs will be closed after exception automatically in python2.7?

On 10Jun2019 12:47, Peter J. Holzer wrote: On 2019-06-10 18:18:07 +0800, lampahome wrote: I confused will fd will be close after exception automatically? Like: try: fd=open("file","w+") fd.get() //any useless function of fd except Exception: print 'hi' Plea

Re: FDs will be closed after exception automatically in python2.7?

On 2019-06-10 18:18:07 +0800, lampahome wrote: > as title, > > I confused will fd will be close after exception automatically? > > Like: > try: > fd=open("file","w+") > fd.get() //any useless function of fd > except Exception: > print 'hi&#x

FDs will be closed after exception automatically in python2.7?

as title, I confused will fd will be close after exception automatically? Like: try: fd=open("file","w+") fd.get() //any useless function of fd except Exception: print 'hi' -- https://mail.python.org/mailman/listinfo/python-list

Re: [solved] C API version of str(exception) is not the same as pure python version

On Sunday, 10 February 2019 11:59:16 GMT Barry Scott wrote: > When I use the C API to get the str() of an execption I see this text: > > > > But python reports the following for the same exception: > > TypeError: unsupported operand type(s) for +: 'int

C API version of str(exception) is not the same as pure python version

When I use the C API to get the str() of an execption I see this text: But python reports the following for the same exception: TypeError: unsupported operand type(s) for +: 'int' and 'str' What do I need to do in the C API to get the the same text for the

Re: Why exception from os.path.exists()?

On 2018-06-13 23:56:09 +0300, Marko Rauhamaa wrote: > "Peter J. Holzer" : > > POSIX specifies a number of error codes which can be returned by stat(): [...] > > So none of these is a good choice for the errno parameter of an OSError > > to be thrown. > > The natural errno value would be EINVAL, wh

Re: Why exception from os.path.exists()?

"Peter J. Holzer" : > POSIX specifies a number of error codes which can be returned by stat(): > > [EACCES] > Search permission is denied for a component of the path prefix. > [EIO] > An error occurred while reading from the file system. > [ELOOP] > A loop exists in symbolic links enco

Re: Why exception from os.path.exists()?

On 2018-06-11 14:23:42 +0300, Marko Rauhamaa wrote: > "Peter J. Holzer" : > > On 2018-06-11 01:06:37 +, Steven D'Aprano wrote: > >> Baking a limitation of some file systems into the high-level > >> interface is simply a *bad idea*. > > > > We aren't talking about a high-level interface here. >

Re: Why exception from os.path.exists()?

a very thin wrapper around the syscall. On other systems, POSIX stat is basically emulated by invoking other system calls. A user on a POSIX system should therefore expect the result of os.stat() be the same as that of the stat() system call (i.e. if successful the fields should have the same

Re: Why exception from os.path.exists()?

On Wed, 13 Jun 2018 10:10:03 +0300, Marko Rauhamaa wrote: > "Peter J. Holzer" : [...] >> I wasn't entirely clear here. What I meant is that POSIX systems, as a >> group, provide no such way. > > I still don't see how POSIX is directly relevant here. Linux users like to sneer at Windows users for

Re: Why exception from os.path.exists()?

"Peter J. Holzer" : > On 2018-06-11 12:24:54 +, Steven D'Aprano wrote: >> It also clearly states: >> >> All functions in this module raise OSError in the case of >> invalid or inaccessible file names and paths, or other >> arguments that have the correct type, but are not accepted

Re: Why exception from os.path.exists()?

On 2018-06-11 12:24:54 +, Steven D'Aprano wrote: > On Mon, 11 Jun 2018 12:31:09 +0200, Peter J. Holzer wrote: > > On 2018-06-11 01:06:37 +, Steven D'Aprano wrote: > >> On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote: > > > > [Note: I was talking about os.stat here, not os.path.ex

Re: Why exception from os.path.exists()?

On 11-06-18 13:59, Steven D'Aprano wrote: > On Mon, 11 Jun 2018 09:55:06 +0200, Antoon Pardon wrote: > >> On 11-06-18 02:28, Steven D'Aprano wrote: > [...] >>> open(foo) raises an exception if foo doesn't exist; >>> >>> os.path.exist

Re: Why exception from os.path.exists()?

POSIX specifies a *minimum* set of functionality, not a maximum. > On such systems Python > MUST NOT simply pass a pointer to the start of the (utf-8 encoded) > string to the OS, it must take special action. It could fake an ENOENT > error, but that would be confusing in many situations

Re: Why exception from os.path.exists()?

On Mon, 11 Jun 2018 09:55:06 +0200, Antoon Pardon wrote: > On 11-06-18 02:28, Steven D'Aprano wrote: [...] >> open(foo) raises an exception if foo doesn't exist; >> >> os.path.exists(foo) returns False if foo doesn't exist. > > That is not corr

Re: Why exception from os.path.exists()?

not, we *are* talking about an interface ("os.path") whose whole raison d'être is abstracting OS specifics from basic pathname processing. > We are talking about low-level code which is just above the OS. THAT > code MUST make sure that it calls the OS API with meaningful >

Re: Why exception from os.path.exists()?

this is worth keeping, and "I couldn't pass that file name to > > the OS" is a different error than "the OS told me the file doesn't > > exist", so I think it should be a different exception. > > What makes you think that NUL bytes are a fundamental l

Re: Why exception from os.path.exists()?

On 11-06-18 10:35, Marko Rauhamaa wrote: > Antoon Pardon : >> On 11-06-18 02:28, Steven D'Aprano wrote: >>> The *whole point* of o.p.exists is to return False, not raise an >>> exception. >> And the price is that it will not always give the correct answer. &g

Re: Why exception from os.path.exists()?

Antoon Pardon : > On 11-06-18 02:28, Steven D'Aprano wrote: >> The *whole point* of o.p.exists is to return False, not raise an >> exception. > > And the price is that it will not always give the correct answer. Yes, but that's still the point of the function

Re: Why exception from os.path.exists()?

Barry Scott : > I think the rule is, if python can pass the string faithfully to the > OS, then do so, otherwise raise an exception that tells the programmer > that they are doing something that the OS does not allow for. Sure, but few application programmers would think of dealing

Re: Why exception from os.path.exists()?

> On 11 Jun 2018, at 01:03, Chris Angelico wrote: > > On Mon, Jun 11, 2018 at 9:52 AM, Steven D'Aprano > wrote: >> On Mon, 11 Jun 2018 06:10:26 +1000, Chris Angelico wrote: >> >>> Can you try creating "spam:ham" and "spam/ham"? If they're both legal, >>> I'd like to see what their file names

Re: Why exception from os.path.exists()?

to data > > The *mere existence* of os.path.exists means that there is not a > consistent response to file names: > >open(foo) raises an exception if foo doesn't exist; > >os.path.exists(foo) returns False if foo doesn't exist. > > There is no requir

Re: Why exception from os.path.exists()?

e* of os.path.exists means that there is not a > consistent response to file names: > > open(foo) raises an exception if foo doesn't exist; > > os.path.exists(foo) returns False if foo doesn't exist. That is not correct. The path can exist and os.path.exists

Re: Why exception from os.path.exists()?

Steven D'Aprano wrote: The evidence suggests that using the Carbon APIs, NUL is just another Unicode character. Whatever API replaces Carbon, it will have to deal with file names created under Carbon, and classic Mac, and so likely will support the same. Thsi raises the interesting quesion of

Re: Why exception from os.path.exists()?

Steven D'Aprano wrote: Besides, it is certainly not true that there are no OSes that can deal with NULs in file names. Classic Mac OS can, as filenames there are represented as Pascal strings (a length byte followed by an array of arbitrary bytes), not NUL-terminated C strings. There's even a

Re: Why exception from os.path.exists()?

Steven D'Aprano wrote: Hmmm... you know I might just be able to do that. Write a file to a floppy, then mount it under Linux. That still might not tell you much. The Linux system will need a filesystem driver that understands the Mac HFS file system, which is what your classic Mac system will b

Re: Why exception from os.path.exists()?

Chris Angelico wrote: I'd like to find out about that. If it doesn't work, it'll be easily provable that it can't be done. Using the shell: % touch colonic:name % ls colonic:name % touch slashy/name touch: slashy/name: No such file or directory (It's trying to create a file in a directory cal

NUL in file names verified [was Re: Why exception from os.path.exists()?]

Straight from the horse's mouth, Apple's HFS Plus volumes do indeed support NULs in file names. Quote: Indirect node files exist in a special directory called the metadata directory. This directory exists in the volume's root directory. The name of the metadata directory is four null

Re: Why exception from os.path.exists()?

doesn't >> exist", so I think it should be a different exception. > > What makes you think that NUL bytes are a fundamental limitation that no > OS could every cope with? I didn't say that. If you have an OS that can't handle more than 255 bytes o

Re: Why exception from os.path.exists()?

On Sun, 10 Jun 2018 23:57:35 +0200, Peter J. Holzer wrote: > I think this is worth keeping, and "I couldn't pass that file name to > the OS" is a different error than "the OS told me the file doesn't > exist", so I think it should be a different exception.

Re: Why exception from os.path.exists()?

On 06/07/2018 12:45 AM, Chris Angelico wrote: On Thu, Jun 7, 2018 at 1:55 PM, Steven D'Aprano wrote: On Tue, 05 Jun 2018 23:27:16 +1000, Chris Angelico wrote: And an ASCIIZ string cannot contain a byte value of zero. The parallel is exact. Why should we, as Python programmers, care one whit

Re: Why exception from os.path.exists()?

nse to file names: open(foo) raises an exception if foo doesn't exist; os.path.exists(foo) returns False if foo doesn't exist. There is no requirement that different functions do the same thing with the same bad input. The *whole point* of o.p.exists is to return False, not ra

Re: Why exception from os.path.exists()?

I accidentally did not send this to the list... > On Jun 10, 2018, at 7:10 PM, Bev in TX wrote: > > >> On Jun 10, 2018, at 3:10 PM, Chris Angelico > > wrote: >>> ... >> >> Can you try creating "spam:ham" and "spam/ham"? If they're both legal, >> I'd like to see what th

Re: Why exception from os.path.exists()?

On Mon, Jun 11, 2018 at 9:52 AM, Steven D'Aprano wrote: > On Mon, 11 Jun 2018 06:10:26 +1000, Chris Angelico wrote: > >> Can you try creating "spam:ham" and "spam/ham"? If they're both legal, >> I'd like to see what their file names are represented as. > > The Finder could very easily be substitut

Re: Why exception from os.path.exists()?

On Mon, 11 Jun 2018 06:10:26 +1000, Chris Angelico wrote: > Can you try creating "spam:ham" and "spam/ham"? If they're both legal, > I'd like to see what their file names are represented as. The Finder could very easily be substituting another character, like Konqueror (the KDE 3 file manager) d

Re: Why exception from os.path.exists()?

ot;", line 1, in PermissionError: [Errno 13] Permission denied: '/lost+found/foo' >>> os.stat("\0") Traceback (most recent call last): File "", line 1, in ValueError: embedded null byte I think this is worth keeping, and "I couldn't pass th

Re: Why exception from os.path.exists()?

Barry Scott : > Singling out os.path.exists as a special case I do think is > reasonable. I don't think anyone has proposed that. While I brought up os.path.exists() in my bug report, os.path.isfile(), os.path.isdir() etc should obviously be addressed simultaneously. It may even be that the fix ne

Re: Why exception from os.path.exists()?

> open('a\0b', 'w') Traceback (most recent call last): File "", line 1, in ValueError: embedded null character >>> Singling out os.path.exists as a special case I do think is reasonable. All functions that take paths need to have a consistent response to data that is impossible to pass to the OS. When it is impossible to get the OS to see all of the users data I'm not sure what else is reasonable for python to do then what it already does not NUL. With the exception that I do not think this is documented and the docs should be fixed. Barry -- https://mail.python.org/mailman/listinfo/python-list

Re: Why exception from os.path.exists()?

On 2018-06-10 09:45:06 -0500, Bev in TX wrote: > On Jun 10, 2018, at 5:49 AM, Peter J. Holzer wrote: > > On 2018-06-07 12:47:15 +, Steven D'Aprano wrote: > >> But it doesn't do that. "Pathnames cannot contain NUL" is a falsehood > >> that programmers wrongly believe about paths. HFS Plus and

Re: Why exception from os.path.exists()?

On Mon, Jun 11, 2018 at 6:22 AM, Marko Rauhamaa wrote: > Chris Angelico : >> Can you try creating "spam:ham" and "spam/ham"? If they're both legal, >> I'd like to see what their file names are represented as. > > I think Bev already explained it. At Unix level, you can't have slashes > in filename

Re: Why exception from os.path.exists()?

Chris Angelico : > Can you try creating "spam:ham" and "spam/ham"? If they're both legal, > I'd like to see what their file names are represented as. I think Bev already explained it. At Unix level, you can't have slashes in filenames. At GUI level, you can't have colons in filenames. Unix slashes

  1   2   3   4   5   6   7   8   9   10   >