On Aug 13, 2024 15:29, Barry Scott via Python-list
wrote:
> Could not find file 'C:\Users\Charl\OneDrive\Documents\The Sims 4 Mod
Constructor\Projects\MetalMummysMods_Ehlers-DanlosMod\Python\__pycache__\MetalMummysMods_Ehlers-DanlosMod.cpython-37.pyc'.
> Element ID: (No Elem
> On 11 Aug 2024, at 13:06, Charlotte Plant via Python-list
> wrote:
>
> Hiya, I'm using the sims 4 mod constructor by Zerbu, and when saving I'm
> getting these error codes.
> I'm going around in circles trying to figure out what is causing it, and I&
Hiya, I'm using the sims 4 mod constructor by Zerbu, and when saving I'm
getting these error codes.
I'm going around in circles trying to figure out what is causing it, and I'm
stuck!
Can you help please?
Thank you.
Errors:
There was an error compiling the generated Pyt
Steven D'Aprano wrote:
> I have a script that can be broken up into four subtasks. If any of those
> subtasks fail, I wish to exit with a different exit code and error.
>
> Assume that the script is going to be run by system administrators who
> know no Python and are terrified of tracebacks, and
On Mon, Nov 21, 2016 at 6:09 PM, Steven D'Aprano
wrote:
> try:
> begin()
> except BeginError:
> print("error in begin")
> sys.exit(3)
Do you control the errors that are getting thrown?
class BeginExit(SystemExit, BeginError): pass
It'll behave like SystemExit, but still be catchable
On Monday 21 November 2016 19:01, Ben Finney wrote:
[...]
> The next improvement I'd make is to use the “strategy” pattern, and come
> up with some common key that determines what exit status you want. Maybe
> the key is a tuple of (function, exception):
>
> exit_status_by_problem_key = {
>
On Monday 21 November 2016 18:39, Jussi Piitulainen wrote:
> Steven D'Aprano writes:
[...]
>> It's not awful, but I don't really like the look of all those
>> try...except blocks. Is there something cleaner I can do, or do I just
>> have to suck it up?
>
> Have the exception objects carry the mes
Steven D'Aprano writes:
> I have a script that can be broken up into four subtasks. If any of those
> subtasks fail, I wish to exit with a different exit code and error.
>
> Assume that the script is going to be run by system administrators who
> know no Python and are terrified of tracebacks, a
Steven D'Aprano writes:
> I have a script that can be broken up into four subtasks. If any of
> those subtasks fail, I wish to exit with a different exit code and
> error.
>
> Assume that the script is going to be run by system administrators who
> know no Python and are terrified of tracebacks, a
I have a script that can be broken up into four subtasks. If any of those
subtasks fail, I wish to exit with a different exit code and error.
Assume that the script is going to be run by system administrators who know no
Python and are terrified of tracebacks, and that I'm logging the full trace
On 29 May 2013 00:44, "Dennis Lee Bieber" wrote:
>
> On Tue, 28 May 2013 17:15:51 +1000, Chris Angelico
> declaimed the following in gmane.comp.python.general:
>
>
> > Can we internationalize English instead of localizing Python?
> >
> > Not-entirely-joking-ly yours,
> >
> All that is req
On 28 May 2013 09:22, "Chris Angelico" wrote:
>
> On Tue, May 28, 2013 at 6:10 PM, Fábio Santos
wrote:
> > Just to clarify, I am suggesting to have the unchanged messages in
> > tracebacks, but having some methods in the exception to get the
exception
> > and message localised. Just like repr() a
28.05.13 11:17, Chris Angelico написав(ла):
On Tue, May 28, 2013 at 6:10 PM, Fábio Santos wrote:
Just to clarify, I am suggesting to have the unchanged messages in
tracebacks, but having some methods in the exception to get the exception
and message localised. Just like repr() and str() are dir
On Tue, 28 May 2013 17:15:51 +1000, Chris Angelico wrote:
> Can we internationalize English instead of localizing Python?
We have. English is the primary international language for programmers.
(For which I am profoundly grateful.)
Japanese is also a pretty important language, but mostly in Jap
On Tue, May 28, 2013 at 6:10 PM, Fábio Santos wrote:
> Just to clarify, I am suggesting to have the unchanged messages in
> tracebacks, but having some methods in the exception to get the exception
> and message localised. Just like repr() and str() are directed at different
> audiences (the progr
On 28 May 2013 08:19, "Chris Angelico" wrote:
>
> On Tue, May 28, 2013 at 4:57 PM, Fábio Santos
wrote:
> >
> > On 28 May 2013 05:17, "Vito De Tullio" wrote:
> >> I really hope really far... have you never tried to google a localized
> >> error
> >> message? :\
> >
> > Never. I don't even try.
>
On Tue, May 28, 2013 at 4:57 PM, Fábio Santos wrote:
>
> On 28 May 2013 05:17, "Vito De Tullio" wrote:
>> I really hope really far... have you never tried to google a localized
>> error
>> message? :\
>
> Never. I don't even try.
Same happens when someone pastes an error onto a mailing list like
On 28 May 2013 05:17, "Vito De Tullio" wrote:
>
> Fábio Santos wrote:
>
> >> > > Speaking of PEPs and exceptions. When do we get localized
exceptions?
> >> >
> >> > What do you mean by "localized exceptions"?
> >> >
> >> > Please, tell me it's *NOT* a proposal to send the exception message
in
> >>
Fábio Santos wrote:
>> > > Speaking of PEPs and exceptions. When do we get localized exceptions?
>> >
>> > What do you mean by "localized exceptions"?
>> >
>> > Please, tell me it's *NOT* a proposal to send the exception message in
>> > the
>> > locale language!
>> It is. I think I read it mention
On 27 May 2013 19:36, "Fábio Santos" wrote:
>
>
> On 27 May 2013 19:23, "Vito De Tullio" wrote:
> >
> > Fábio Santos wrote:
> >
> > >> This should make life easier for us
> > >
http://docs.python.org/3/whatsnew/3.3.html#pep-3151-reworking-the-os-and-io-exception-hierarchy
> > >
> > > Speaking of
On 27 May 2013 19:23, "Vito De Tullio" wrote:
>
> Fábio Santos wrote:
>
> >> This should make life easier for us
> >
http://docs.python.org/3/whatsnew/3.3.html#pep-3151-reworking-the-os-and-io-exception-hierarchy
> >
> > Speaking of PEPs and exceptions. When do we get localized exceptions?
>
> Wha
Fábio Santos wrote:
>> This should make life easier for us
> http://docs.python.org/3/whatsnew/3.3.html#pep-3151-reworking-the-os-and-io-exception-hierarchy
>
> Speaking of PEPs and exceptions. When do we get localized exceptions?
What do you mean by "localized exceptions"?
Please, tell me it's
On 5/27/2013 12:54 PM, Carlos Nepomuceno wrote:
I think PEP 3151 is a step ahead! That's almost exactly what I was looking for.
Why did it take so long to have that implemented?
Since this PEP involved changing existing features, rather than adding
som
On 27/05/2013 17:54, Carlos Nepomuceno wrote:
I think PEP 3151 is a step ahead! That's almost exactly what I was looking for.
Why did it take so long to have that implemented?
Lack of volunteers.
--
If you're using GoogleCrap™ please read this
http:/
Thanks so much guys!
I'm not planning to prepare for every possible situation, but I certainly am
responsible to handle most common errors. So it's really important to know what
a function/method returns when called.
Exception handling may take lots of code, but I'm used to it. It's much better
On Mon, May 27, 2013 at 2:11 PM, Steven D'Aprano
wrote:
> On Mon, 27 May 2013 13:46:50 +0100, Fábio Santos wrote:
>
>> Speaking of PEPs and exceptions. When do we get localized exceptions?
>
>
> We're waiting for you to volunteer. When can you start?
I'd love to work on that but my C is too shabb
On Mon, 27 May 2013 13:46:50 +0100, Fábio Santos wrote:
> Speaking of PEPs and exceptions. When do we get localized exceptions?
We're waiting for you to volunteer. When can you start?
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
On 27 May 2013 12:41, "Mark Lawrence" wrote:
> This should make life easier for us
http://docs.python.org/3/whatsnew/3.3.html#pep-3151-reworking-the-os-and-io-exception-hierarchy
Speaking of PEPs and exceptions. When do we get localized exceptions?
--
http://mail.python.org/mailman/listinfo/pyth
On 27/05/2013 07:11, Cameron Simpson wrote:
BTW, I recommend importing "errno" and using symbolic names. It makes things
much more readable, and accomodates the situation where the symbols map to different
numbers on different platforms. And have a catch-all. For example:
Cheers,
This shou
On Mon, May 27, 2013 at 4:11 PM, Cameron Simpson wrote:
> On 27May2013 04:49, Carlos Nepomuceno wrote:
> | That's bad! I'd like to check all the IOError codes that may be
> | raised by a function/method but the information isn't there.
>
> No, you really don't.
Heh. I concur. Opening a file can
On 27May2013 04:49, Carlos Nepomuceno wrote:
| > From: steve+comp.lang.pyt...@pearwood.info
| > On Mon, 27 May 2013 02:13:54 +0300, Carlos Nepomuceno wrote:
| >> Where can I find all error codes and messages that Python throws (actual
| >> codes and messages from exception
On 27May2013 00:53, Steven D'Aprano
wrote:
| On Mon, 27 May 2013 02:13:54 +0300, Carlos Nepomuceno wrote:
| > Where can I find all error codes and messages that Python throws (actual
| > codes and messages from exceptions raised by stdlib)?
|
| There is no list. It is subject to
> From: steve+comp.lang.pyt...@pearwood.info
> Subject: Re: Python error codes and messages location
> Date: Mon, 27 May 2013 00:53:41 +
> To: python-list@python.org
>
> On Mon, 27 May 2013 02:13:54 +0300, Carlos Nepomuceno wrote:
>
On Mon, 27 May 2013 02:13:54 +0300, Carlos Nepomuceno wrote:
> Where can I find all error codes and messages that Python throws (actual
> codes and messages from exceptions raised by stdlib)?
There is no list. It is subject to change from version to version,
including point releases.
Where can I find all error codes and messages that Python throws (actual codes
and messages from exceptions raised by stdlib)?
I've already found the module 'errno' and got a dictionary (errno.errorcode)
and some system error messages (os.strerror(errno.ENAMETOOLONG)) but
On 2011.05.26 10:02 AM, Thomas Heller wrote:
> On Windows, you can use ctypes.FormatError(code) to map error codes
> to strings:
>
> >>> import ctypes
> >>> ctypes.FormatError(32)
> 'Der Prozess kann nicht auf die Datei zugreifen, da sie vo
specific error code, so I
could put in an if...elif...else clause inside the except clause if I
needed to, but I don't know what all the different errors are.
On Windows, you can use ctypes.FormatError(code) to map error codes
to strings:
>>> import ctypes
>>> ctypes.Forma
Genstein invalid.invalid> writes:
>
> > Andrew Berg gmail.com> writes:
> > Since Python 2.5, the errno attribute maps the Windows error to error
> > codes that match the attributes of module errno.
>
> Good point, I completely misread that. At least t
On 2011.05.21 06:46 AM, John J Lee wrote:
> Since Python 2.5, the errno attribute maps the Windows error to error
> codes that match the attributes of module errno.
I was able to whip up a nifty little function that takes the output of
sys.exc_info() after a WindowsError and return the erro
Andrew Berg writes:
Since Python 2.5, the errno attribute maps the Windows error to error
codes that match the attributes of module errno.
Good point, I completely misread that. At least the Windows error code
is still available as the winerror attribute.
As an aside - call me stupid, but I
ecific error code, so I
> could put in an if...elif...else clause inside the except clause if I
> needed to, but I don't know what all the different errors are.
Since Python 2.5, the errno attribute maps the Windows error to error
codes that match the attributes of module errno.
http://
On 2011.05.20 02:47 PM, Genstein wrote:
> On 20/05/2011 18:56, Andrew Berg wrote:
> > This is probably somewhat off-topic, but where would I find a list of
> > what each error code in WindowsError means?
>
> Assuming it's a Win32 error code, winerror.h from the Platform SDK holds
> the answer. One
On 20/05/2011 18:56, Andrew Berg wrote:
This is probably somewhat off-topic, but where would I find a list of
what each error code in WindowsError means? WindowsError is so broad
that it could be difficult to decide what to do in an except clause.
Fortunately, sys.exc_info()[1][0] holds the speci
On 20/05/2011 18:56, Andrew Berg wrote:
This is probably somewhat off-topic, but where would I find a list of
what each error code in WindowsError means?
Assuming it's a Win32 error code, winerror.h from the Platform SDK holds
the answer. One version is linked below, it's in theory out of date
This is probably somewhat off-topic, but where would I find a list of
what each error code in WindowsError means? WindowsError is so broad
that it could be difficult to decide what to do in an except clause.
Fortunately, sys.exc_info()[1][0] holds the specific error code, so I
could put in an if...
Albert van der Horst writes:
> But I greatly prefer a set
>
> "
> for i in {point1,point2,point3}:
> statements
> "
Agreed, for the reasons you cite. I think this idiom can be expected to
become more common and hopefully displace using a tuple literal or list
literal, as the
In article ,
>
>
>But practicality beats purity -- there are many scenarios where we make
>compromises in our meaning in order to get correct, efficient code. E.g.
>we use floats, despite them being a poor substitute for the abstract Real
>numbers we mean.
>
>In addition, using a tuple or a list in
Mel writes:
> The immutability makes it easier to talk about the semantic meanings.
> After you do
> > event_timestamp = (2009, 06, 04, 05, 02, 03)
> there's nothing that can happen to the tuple to invalidate
> > (year, month, day, hour, minute, second) = event_timestamp
> even though, as
Gunter Henriksen wrote:
[ ... ]
> I guess to me, fundamentally, the interpretation of
> tuple as a sequence whose elements have semantic meaning
> implicitly defined by position is a relatively abstract
> intrepretation whose value is dubious relative to the
> value of immutability, since it seems
> > >event_timestamp = (2009, 06, 04, 05, 02, 03)
> > >(year, month, day, hour, minute, second) = event_timestamp
> >
> > [...]
>
> The point of each position having a different semantic meaning is that
> tuple unpacking works as above. You need to know the meaning of each
> position in ord
Gunter Henriksen writes:
> > Try, then, this tuple:
> >
> >event_timestamp = (2009, 06, 04, 05, 02, 03)
> >(year, month, day, hour, minute, second) = event_timestamp
>
> I totally agree about anything to do with immutability, I think the
> relative ordering of the elements in this exampl
> Try, then, this tuple:
>
>event_timestamp = (2009, 06, 04, 05, 02, 03)
>(year, month, day, hour, minute, second) = event_timestamp
>
> A list would be wrong for this value, because each position in the
> sequence has a specific meaning beyond its mere sequential position. Yet
> it also ma
Gunter Henriksen writes:
> I think I would have difficulty holding a position that this should
> not be a class (or equivalent via namedtuple()) or a dict. It seems to
> me like a case could be made that there are far more situations where
> it makes sense to use tuples as immutable sequences tha
> [In this tuple]
>dodge_city = (1781, 1870, 1823)
>(population, feet_above_sea_level, establishment_year) = dodge_city
> each index in the sequence implies something very
> different about each value. The semantic meaning
> of each index is *more* than just the position in
> the sequence;
En Tue, 09 Jun 2009 05:02:33 -0300, Steven D'Aprano
escribió:
[...] As tuples are defined in Python, they quack like immutable lists,
they
walk like immutable lists, and they swim like immutable lists. Why
shouldn't we treat them as immutable lists?
Phillip Eby states that "Lists are intende
On Tue, 09 Jun 2009 04:57:48 -0700, samwyse wrote:
> Time to test things! I'm going to compare three things using Python
> 3.0:
> X={...}\nS=lambda x: x in X
> S=lambda x: x in {...}
> S=lambda x: x in (...)
> where the ... is replaced by lists of integers of various lengths.
> Here's the
m...@pixar.com wrote:
John Machin wrote:
T=lambda x:x in(25401,25402,25408);import dis;dis.dis(L);dis.dis(T)
I've learned a lot from this thread, but this is the
niftiest bit I've picked up... thanks!
If you are doing a lot of dissing, starting with
from dis import dis
saves subsequent typi
Steven D'Aprano wrote:
James Tauber explains this at
http://jtauber.com/blog/2006/04/15/
python_tuples_are_not_just_constant_lists/>.
He doesn't really explain anything though, he merely states it as
revealed wisdom. The closest he comes to an explanation is to declare
that in tuples "the i
John Machin wrote:
> T=lambda x:x in(25401,25402,25408);import dis;dis.dis(L);dis.dis(T)
I've learned a lot from this thread, but this is the
niftiest bit I've picked up... thanks!
--
Mark Harrison
Pixar Animation Studios
--
http://mail.python.org/mailman/listinfo/python-list
On Jun 9, 8:20 am, samwyse wrote:
> On Jun 9, 12:30 am, Emile van Sebille wrote:
>
> > On 6/8/2009 8:43 PM Ben Finney said...
> > > The fact that literal set syntax is a relative newcomer is the primary
> > > reason for that, I'd wager.
>
> > Well, no. It really is more, "that's odd... why use s
On Jun 9, 4:57 am, samwyse wrote:
> On Jun 8, 8:57 pm, samwyse wrote:
>
> > I conclude that using constructors is generally a bad idea, since the
> > compiler doesn't know if you're calling the builtin or something with
> > an overloaded name. I presume that the compiler will eventually
> > opti
On Jun 9, 12:30 am, Emile van Sebille wrote:
> On 6/8/2009 8:43 PM Ben Finney said...
> > The fact that literal set syntax is a relative newcomer is the primary
> > reason for that, I'd wager.
>
> Well, no. It really is more, "that's odd... why use set?"
Until I ran some timing tests this morni
Steven D'Aprano writes:
> On Tue, 09 Jun 2009 09:43:45 +1000, Ben Finney wrote:
>
> > Use a list when the semantic meaning of an item doesn't depend on
> > all the other items: it's “only” a collection of values.
> >
> > Your list of message codes is a good example: if a value appears at
> > in
On Jun 8, 8:57 pm, samwyse wrote:
> I conclude that using constructors is generally a bad idea, since the
> compiler doesn't know if you're calling the builtin or something with
> an overloaded name. I presume that the compiler will eventually
> optimize the second example to match the last, but
On Jun 8, 10:06 pm, Chris Rebert wrote:
> On Mon, Jun 8, 2009 at 6:57 PM, samwyse wrote:
> > On Jun 8, 7:37 pm, Carl Banks wrote:
> >> On Jun 8, 4:43 pm, Ben Finney wrote:
> >> > m...@pixar.com writes:
> >> > > Is there any reason to prefer one or the other of these statements?
>
> >> > >
On Tue, 09 Jun 2009 09:43:45 +1000, Ben Finney wrote:
> Use a list when the semantic meaning of an item doesn't depend on all
> the other items: it's “only” a collection of values.
>
> Your list of message codes is a good example: if a value appears at
> index 3, that doesn't make it mean somethi
On 6/8/2009 8:43 PM Ben Finney said...
Steven D'Aprano writes:
In addition, using a tuple or a list in this context:
if e.message.code in (25401,25402,25408):
is so idiomatic, that using a set in it's place would be distracting.
I think a list in that context is fine, and that's the id
Steven D'Aprano writes:
> In addition, using a tuple or a list in this context:
>
> if e.message.code in (25401,25402,25408):
>
> is so idiomatic, that using a set in it's place would be distracting.
I think a list in that context is fine, and that's the idiom I see far
more often than a t
On Tue, 09 Jun 2009 11:02:54 +1000, Ben Finney wrote:
> Carl Banks writes:
>
>> If you want to go strictly by the book, I would say he ought to be
>> using a set since his collection of numbers has no meaningful order nor
>> does it make sense to list any item twice.
>
> Yes, a set would be bes
On Mon, Jun 8, 2009 at 6:57 PM, samwyse wrote:
> On Jun 8, 7:37 pm, Carl Banks wrote:
>> On Jun 8, 4:43 pm, Ben Finney wrote:
>> > m...@pixar.com writes:
>> > > Is there any reason to prefer one or the other of these statements?
>>
>> > > if e.message.code in [25401,25402,25408]:
>> > >
On Jun 8, 2009, at 9:28 PM, Carl Banks wrote:
On Jun 8, 6:02 pm, Ben Finney wrote:
Carl Banks writes:
If you want to go strictly by the book, I would say he ought to be
using a set since his collection of numbers has no meaningful order
nor does it make sense to list any item twice.
Yes,
On Jun 8, 7:37 pm, Carl Banks wrote:
> On Jun 8, 4:43 pm, Ben Finney wrote:
> > m...@pixar.com writes:
> > > Is there any reason to prefer one or the other of these statements?
>
> > > if e.message.code in [25401,25402,25408]:
> > > if e.message.code in (25401,25402,25408):
>
> If
On Jun 8, 6:02 pm, Ben Finney wrote:
> Carl Banks writes:
> > If you want to go strictly by the book, I would say he ought to be
> > using a set since his collection of numbers has no meaningful order
> > nor does it make sense to list any item twice.
>
> Yes, a set would be best for this specifi
Carl Banks writes:
> If you want to go strictly by the book, I would say he ought to be
> using a set since his collection of numbers has no meaningful order
> nor does it make sense to list any item twice.
Yes, a set would be best for this specific situation.
> I don't think it's very importan
On Jun 8, 4:43 pm, Ben Finney wrote:
> m...@pixar.com writes:
> > Is there any reason to prefer one or the other of these statements?
>
> > if e.message.code in [25401,25402,25408]:
> > if e.message.code in (25401,25402,25408):
>
> > I'm currently using [], but only coz I think it'
m...@pixar.com writes:
> Is there any reason to prefer one or the other of these statements?
>
> if e.message.code in [25401,25402,25408]:
> if e.message.code in (25401,25402,25408):
>
> I'm currently using [], but only coz I think it's prettier
> than ().
Use a list when the se
pixar.com> writes:
>
> Is there any reason to prefer one or the other of these statements?
>
> if e.message.code in [25401,25402,25408]:
> if e.message.code in (25401,25402,25408):
>
>From the viewpoint of relative execution speed, in the above case
if it matters at all it ma
m...@pixar.com wrote:
Is there any reason to prefer one or the other of these statements?
if e.message.code in [25401,25402,25408]:
if e.message.code in (25401,25402,25408):
I'm currently using [], but only coz I think it's prettier
than ().
context: these are database errors and
On Mon, Jun 8, 2009 at 2:36 PM, wrote:
> Is there any reason to prefer one or the other of these statements?
>
>if e.message.code in [25401,25402,25408]:
>if e.message.code in (25401,25402,25408):
>
> I'm currently using [], but only coz I think it's prettier
> than ().
I like t
Is there any reason to prefer one or the other of these statements?
if e.message.code in [25401,25402,25408]:
if e.message.code in (25401,25402,25408):
I'm currently using [], but only coz I think it's prettier
than ().
context: these are database errors and e is database excepti
80 matches
Mail list logo