On 3/1/21 10:46 AM, [email protected] wrote:
Hello Python Team,
i tried to install SW above; the installation stopped with the
message
"one or more issues caused the setup to fail.
Please the issues and then retry
0x80070642 installation stopped by user"
What must i do go get the SW in
Hello Python Team,
i tried to install SW above; the installation stopped with the
message
"one or more issues caused the setup to fail.
Please the issues and then retry
0x80070642 installation stopped by user"
What must i do go get the SW installed?
Windows 10, file "python-3.9.2-amd64.exe"
Be
I had to do this with a different API the toehr year, and made this
method:
def auth_token(self):
''' Obtain a current auth token [...]
Refreshes the cached token if stale.
'''
while True:
with self._auth_token_lock:
token = self
>
>
>> I'm using the Box API (
>> https://developer.box.com/guides/tooling/sdks/python/).
>> I can get an access token, though it expires after a certain amount of
>> time. My plan is to store the access token on the filesystem and use it
>> until it expires, then fetch a new one. In the example be
On Fri, Nov 27, 2020, 6:06 PM Jason Friedman wrote:
> I'm using the Box API (
> https://developer.box.com/guides/tooling/sdks/python/).
> I can get an access token, though it expires after a certain amount of
> time. My plan is to store the access token on the filesystem and use it
> until it exp
[email protected]
Asunto: Re: try..except or type() or isinstance()?
On Sun, 16 Aug 2020 09:40:12 +0200
Manfred Lotz wrote:
> On Sat, 15 Aug 2020 12:20:48 -0400
> Dennis Lee Bieber wrote:
>
> > On Sat, 15 Aug 2020 15:31:56 +0200, Manfred Lotz
> > declaimed the following:
&
On Sun, 16 Aug 2020 09:40:12 +0200
Manfred Lotz wrote:
> On Sat, 15 Aug 2020 12:20:48 -0400
> Dennis Lee Bieber wrote:
>
> > On Sat, 15 Aug 2020 15:31:56 +0200, Manfred Lotz
> > declaimed the following:
> >
> > >On Sat, 15 Aug 2020 11:47:03 +0200
> > >Sibylle Koczian wrote:
> > >
> >
On 15 Aug 2020 14:49:48 GMT
[email protected] (Stefan Ram) wrote:
> Manfred Lotz writes:
> >Here a minimal example
>
> main.py
>
> source="""
> sehr gut
> 1
> """[ 1: -1 ].split( "\n" )
>
> class grades:
> names =[ "sehr gut" ]
> @staticmethod
> def is_numeric( text ):
>
On Sat, 15 Aug 2020 12:20:48 -0400
Dennis Lee Bieber wrote:
> On Sat, 15 Aug 2020 15:31:56 +0200, Manfred Lotz
> declaimed the following:
>
> >On Sat, 15 Aug 2020 11:47:03 +0200
> >Sibylle Koczian wrote:
> >
>
> >> if the value comes from a file, isn't it a
> >> string in any case? A string
On Sat, 15 Aug 2020 11:47:03 +0200
Sibylle Koczian wrote:
> Am 15.08.2020 um 10:14 schrieb Manfred Lotz:
> > Hi Chris,
> > Thanks a lot for you advice.
> >
> > On Sat, 15 Aug 2020 16:15:29 +1000
> > Chris Angelico wrote:
> >
> >> On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz
> >> wrote:
> >>
Am 15.08.2020 um 10:14 schrieb Manfred Lotz:
Hi Chris,
Thanks a lot for you advice.
On Sat, 15 Aug 2020 16:15:29 +1000
Chris Angelico wrote:
On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz
wrote:
I have an object which I could initialize providind an int or a str.
...
For my use case I do
On Sat, 15 Aug 2020 08:33:58 +0200
Peter Otten <[email protected]> wrote:
> Chris Angelico wrote:
>
> > On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz
> > wrote:
> >>
> >> I have an object which I could initialize providind an int or a
> >> str.
> >>
> >> I am not sure which of the following is b
Hi Chris,
Thanks a lot for you advice.
On Sat, 15 Aug 2020 16:15:29 +1000
Chris Angelico wrote:
> On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz
> wrote:
> >
> > I have an object which I could initialize providind an int or a str.
> >
> > I am not sure which of the following is best to use
> > -
Chris Angelico wrote:
> On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz wrote:
>>
>> I have an object which I could initialize providind an int or a str.
>>
>> I am not sure which of the following is best to use
>> - try/except
>> - if type(int)...
>> - if isinstance(v, int)
>>
>> Here a minimal
On Sat, Aug 15, 2020 at 3:36 PM Manfred Lotz wrote:
>
> I have an object which I could initialize providind an int or a str.
>
> I am not sure which of the following is best to use
> - try/except
> - if type(int)...
> - if isinstance(v, int)
>
> Here a minimal example
>
> def get_id(fromname):
Please try to preserve the attribution lines of previous authors. The inner
quote below comes from Steven D'Aprano.
On 21Jul2018 15:13, Ganesh Pal wrote:
(1) Since this function always returns True (if it returns at all), what
is the point? There's no point checking the return result, since it
>
>
>
> (1) Since this function always returns True (if it returns at all), what
> is the point? There's no point checking the return result, since it's
> always true, so why bother returning anything?
>
>
If I don't return anything from a function it returns None. But would it
be better if for
On Fri, 20 Jul 2018 23:29:21 +0530, Ganesh Pal wrote:
> Dear python Friends,
>
>
> I need a quick suggestion on the below code.
>
> def modify_various_line(f):
> """ Try modifiying various line """
> try:
> f.write('0123456789abcdef')
> f.seek(5) # Go to the 6th byte
On 2018-07-20 18:59, Ganesh Pal wrote:
Dear python Friends,
I need a quick suggestion on the below code.
def modify_various_line(f):
""" Try modifiying various line """
try:
f.write('0123456789abcdef')
f.seek(5) # Go to the 6th byte in the file
print f.
Steven D'Aprano wrote:
imp.find_module is deprecated and should not be used in new code.
...
try:
block
except (ImportError, RuntimeError):
block
Thanks Steven and others who replied. Looks more elegant.
By the way, RuntimeError is almost never something you want t
On Thu, 05 Apr 2018 23:04:18 +0200, ElChino wrote:
> I'm trying to simplify a try-except construct. E.g. how come this:
>try:
> _x, pathname, _y = imp.find_module (mod, mod_path)
> return ("%s" % pathname)
imp.find_module is deprecated and should not be used in new code.
Putting th
Ben Bacarisse wrote:
Anyway, to coalesce two or more exception handlers, you are probably
looking for
except (ImportError, RuntimeError):
To the OP: Are you sure you really want to mask RuntimeError here?
Usually it means something has gone seriously wrong, and is a
symptom that shouldn't be
ElChino writes:
> I'm trying to simplify a try-except construct. E.g. how come
> this:
> try:
> _x, pathname, _y = imp.find_module (mod, mod_path)
> return ("%s" % pathname)
> except ImportError:
> pass
> except RuntimeError:
> pass
> return ("")
>
> Cannot be simplified
On Thu, Apr 5, 2018 at 3:04 PM, ElChino wrote:
> I'm trying to simplify a try-except construct. E.g. how come
> this:
> try:
> _x, pathname, _y = imp.find_module (mod, mod_path)
> return ("%s" % pathname)
> except ImportError:
> pass
> except RuntimeError:
> pass
> return
On 04/05/2018 02:04 PM, ElChino wrote:
I'm trying to simplify a try-except construct. E.g. how come
this:
try:
_x, pathname, _y = imp.find_module (mod, mod_path)
return ("%s" % pathname)
except ImportError:
pass
except RuntimeError:
pass
return ("")
Cannot be si
On Sat, Nov 04, 2017 at 05:07:26PM +0100, Karsten Hilbert wrote:
> Try in an interactive interpreter:
>
>python> "a string" is True
Or, rather,
python> if 'a string': print 'success'
Sorry,
Karsten
--
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD 4537
On Sun, 5 Nov 2017 02:31 am, brandon wallace wrote:
>
> I have this code that tests a server to see if it is listening on port 123
> runs and evaluates to True every time. Even if the server does not exist but
> it is not supposed to do that. I am getting no error message at all. What is
> going
On Sun, Nov 5, 2017 at 2:31 AM, brandon wallace wrote:
>
> I have this code that tests a server to see if it is listening on port 123
> runs and evaluates to True every time. Even if the server does not exist but
> it is not supposed to do that. I am getting no error message at all. What is
> g
On Thu, 13 Oct 2016 15:06:25 +0100, Daiyue Weng wrote:
> I know that such try-catch usage is generally a bad practice, since it
> can't locate the root of the exceptions.
>
> I am wondering how to correct the code above
Either identify the specific exceptions you're expecting, or if you're
inter
Daiyue Weng writes:
> I am wondering how to correct the code above (what it tries to do is
> basically trying one processing block, if not working, running another
> block of code in except). Also a warning 'Too broad exception clause'
> will be generated.
Yes. You need to be *very* clear about
Daiyue Weng wrote:
> Hi, I have seen code using try_except with no exceptions,
>
> from dateutil import parser
>
> try:
> from_date = datetime.datetime.strptime(parameters['from_date'],
> '%Y-%m-%d %H:%M:%S.%f')
> to_date = datetime.datetime.strptime(parameters['to_date'],
> '%Y-%m-%d %H
Daiyue Weng writes:
> Hi, I have seen code using try_except with no exceptions,
>
> from dateutil import parser
>
> try:
> from_date = datetime.datetime.strptime(parameters['from_date'],
> '%Y-%m-%d %H:%M:%S.%f')
> to_date = datetime.datetime.strptime(parameters['to_date'],
> '%Y-%m-%d %H:
On 12/14/2015 11:38 PM, Vincent Davis wrote:
In the code below try is used to check if handle has the attribute name. It
seems an if statement could be used. Is there reason one way would be
better than another?
def write_header(self):
handle = self.handle
try:
handle.write("#
On 15Dec2015 17:11, Cameron Simpson wrote:
On 14Dec2015 16:48, Vincent Davis wrote:
[...]
I think the intent of the original code was to check if handle had the
attribute "name", I don't think the attribute "write" was the issue.
[...]
Secondly, for your use case "print the name if it has o
On 14Dec2015 16:48, Vincent Davis wrote:
On Mon, Dec 14, 2015 at 4:14 PM, Cameron Simpson wrote:
First, notice that the code inside the try/except _only_ fetches the
attribute. Your version calls the "write" attribute, and also accesses
handle.name. Either of those might also emit AttributeE
On Mon, Dec 14, 2015 at 4:53 PM, Ian Kelly wrote:
>
> Except that catching an exception just to immediately re-raise it is
> silly. This would be better:
>
> try:
> name = handle.name
> except AttributeError:
> pass
> else:
> handle.write("# Report_file: %s\n" % name)
Ya that would
On Mon, Dec 14, 2015 at 4:48 PM, Vincent Davis wrote:
> On Mon, Dec 14, 2015 at 4:14 PM, Cameron Simpson wrote:
>
>> First, notice that the code inside the try/except _only_ fetches the
>> attribute. Your version calls the "write" attribute, and also accesses
>> handle.name. Either of those migh
On Tue, Dec 15, 2015 at 10:48 AM, Vincent Davis
wrote:
> try:
> write = handel.write
> except AttributeError:
> raise
Just "write = handel.write" :)
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Dec 14, 2015 at 4:14 PM, Cameron Simpson wrote:
> First, notice that the code inside the try/except _only_ fetches the
> attribute. Your version calls the "write" attribute, and also accesses
> handle.name. Either of those might also emit AttributeError, and should
> probably not be sile
On 14Dec2015 15:38, Vincent Davis wrote:
In the code below try is used to check if handle has the attribute name. It
seems an if statement could be used.
Only by using hasattr(), which IIRC does a try/except internally.
Is there reason one way would be
better than another?
try/except is mo
On Mon, Dec 14, 2015 at 3:38 PM, Vincent Davis wrote:
> In the code below try is used to check if handle has the attribute name. It
> seems an if statement could be used. Is there reason one way would be
> better than another?
http://www.oranlooney.com/lbyl-vs-eafp/
--
https://mail.python.org/ma
On 04/30/2015 04:27 PM, brandon wallace wrote:
Hi,
I am try to get more specific error messages using try/except.
I ran this code with the cable unplugged to see the error message. I got
#!/usr/bin/env python3
import urllib.request
webpage = urllib.request.urlopen("http://fakewebsite.com/"
On 12Apr2015 17:00, Chris Angelico wrote:
On Sun, Apr 12, 2015 at 4:33 PM, Cameron Simpson wrote:
[...]
That's what try/finally is for. You can do your cleanup without caring
exactly what was raised.
Hmm, yes.
[...]
However, my Asynchron class really is a little special. I use Asynchron t
On Sun, Apr 12, 2015 at 4:33 PM, Cameron Simpson wrote:
> On 12Apr2015 09:21, Chris Angelico wrote:
>> Fair enough. Do you know how often you actually catch stuff that
>> wouldn't be caught by "except BaseException:"?
>
>
> I don't know and I'm not sure I care (but discussion below). I would need
On 12Apr2015 14:18, Steven D'Aprano
wrote:
On Sun, 12 Apr 2015 09:08 am, Cameron Simpson wrote:
Also, IMO, a bare "except:" syntax is far more pleasing to the eye than
"except magic_exception_name_that+gets_everything:".
And that is exactly what makes bare excepts an attractive nuisance!
I'
On 12Apr2015 16:33, Cameron Simpson wrote:
Finally, if we were to expunge support for "except:", one would also need a
cast iron guarrentee that no exception could possibly occur which was not a
subclass of BaseException. I'd expect that to mean that "raise" of a
non-instance of BaseException
On 12Apr2015 09:21, Chris Angelico wrote:
On Sun, Apr 12, 2015 at 9:08 AM, Cameron Simpson wrote:
Catching all exceptions isn't terribly common, _except_ in service routines
that wrap "unknown" operations. Classic example from my Asynchron class: [...]
try:
r = func(*a, **kw)
On Sun, 12 Apr 2015 09:08 am, Cameron Simpson wrote:
> Also, IMO, a bare "except:" syntax is far more pleasing to the eye than
> "except magic_exception_name_that+gets_everything:".
And that is exactly what makes bare excepts an attractive nuisance!
I'm going to channel a newbie, cowboy or just
On Sun, 12 Apr 2015 07:37 am, Cameron Simpson wrote:
> On 11Apr2015 21:21, Chris Angelico wrote:
>>But I agree, it would be very nice if Python 3 could have abolished
>>the truly confusing part of this, where "except:" catches everything.
>>Forcing people to spell it "except BaseException:" would
On Sun, Apr 12, 2015 at 9:08 AM, Cameron Simpson wrote:
> Catching all exceptions isn't terribly common, _except_ in service routines
> that wrap "unknown" operations. Classic example from my Asynchron class:
>
>def call(self, func, *a, **kw):
> ''' Have the Asynchron call `func(*a,**kw)`
On 12Apr2015 07:52, Chris Angelico wrote:
On Sun, Apr 12, 2015 at 7:37 AM, Cameron Simpson wrote:
On 11Apr2015 21:21, Chris Angelico wrote:
But I agree, it would be very nice if Python 3 could have abolished
the truly confusing part of this, where "except:" catches everything.
Forcing people
On Sun, Apr 12, 2015 at 7:37 AM, Cameron Simpson wrote:
> On 11Apr2015 21:21, Chris Angelico wrote:
>>
>> But I agree, it would be very nice if Python 3 could have abolished
>> the truly confusing part of this, where "except:" catches everything.
>> Forcing people to spell it "except BaseExceptio
On 11Apr2015 21:21, Chris Angelico wrote:
But I agree, it would be very nice if Python 3 could have abolished
the truly confusing part of this, where "except:" catches everything.
Forcing people to spell it "except BaseException:" would fix all of
this. How hard is it to deprecate and then remov
On Sun, Apr 12, 2015 at 6:04 AM, Chris Angelico wrote:
> On Sun, Apr 12, 2015 at 4:49 AM, Ian Kelly wrote:
>> On Apr 11, 2015 5:06 AM, "Steven D'Aprano"
>> wrote:
>>>
>>> Yes, I agree that Python's behaviour here is better than the alternative.
>>> Having "except ()" catch nothing is consistent
On Sun, Apr 12, 2015 at 4:49 AM, Ian Kelly wrote:
> On Apr 11, 2015 5:06 AM, "Steven D'Aprano"
> wrote:
>>
>> Yes, I agree that Python's behaviour here is better than the alternative.
>> Having "except ()" catch nothing is consistent with the behaviour with
>> other tuples, so I'm okay with that.
On Apr 11, 2015 5:06 AM, "Steven D'Aprano" <
[email protected]> wrote:
>
> Yes, I agree that Python's behaviour here is better than the alternative.
> Having "except ()" catch nothing is consistent with the behaviour with
> other tuples, so I'm okay with that. But it still surpri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/15 08:11, Steven D'Aprano wrote:
> But with try...except, an empty exception list means to catch
> *everything*, not nothing:
>
> try: ... except a,b,c: # catches a, b, c
>
> try: ... except a,b: # catches a, b
This example is incorrect. In
On Sat, Apr 11, 2015 at 9:00 PM, Steven D'Aprano
wrote:
> Yes, I agree that Python's behaviour here is better than the alternative.
> Having "except ()" catch nothing is consistent with the behaviour with
> other tuples, so I'm okay with that. But it still surprised me :-)
It's worth noting that
On Sat, 11 Apr 2015 07:27 pm, Cameron Simpson wrote:
> If the empty tuple were to mean "catch everything" then there would not be
> a way to express "catch nothing". Bad bad bad!
# Catch everything:
try:
spam()
except:
pass
# Catch nothing:
spam()
:-)
> Consider this a proof that Py
On Sat, 11 Apr 2015 06:22 pm, Serhiy Storchaka wrote:
> On 11.04.15 10:11, Steven D'Aprano wrote:
>> Anyway, in modern Python (2.6 onwards), now that string exceptions are
>> gone, you can supply something to catch everything. Or nothing, for that
>> matter:
>>
>> BaseException # catch everything
On 04/11/2015 06:14 AM, Dave Angel wrote:
On 04/11/2015 03:11 AM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 12:23 pm, Dave Angel wrote:
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 05:31 am, [email protected] wrote:
It isn't document because it is expected. Why w
On 04/11/2015 03:11 AM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 12:23 pm, Dave Angel wrote:
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 05:31 am, [email protected] wrote:
It isn't document because it is expected. Why would the exception get
caught if you're not
On 10Apr2015 19:38, Rustom Mody wrote:
On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote:
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
> On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote:
>> It isn't document because it is expected. Why would the exception get
>> caught if y
On 4/10/2015 9:42 PM, Steven D'Aprano wrote:
try:
spam()
except:
# Implicitly an empty tuple.
pass
No, specified as equivalent to 'except BaseException:' (or 'except
(BaseException,):', either of which are different from 'except ():'.
"An expression-less except clause, if prese
On 11.04.15 10:11, Steven D'Aprano wrote:
Anyway, in modern Python (2.6 onwards), now that string exceptions are gone,
you can supply something to catch everything. Or nothing, for that matter:
BaseException # catch everything
Not everything.
>>> class A: pass
...
>>> try: raise A
... except
On Sat, 11 Apr 2015 12:23 pm, Dave Angel wrote:
> On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
>> On Sat, 11 Apr 2015 05:31 am, [email protected] wrote:
>>
>>> It isn't document because it is expected. Why would the exception get
>>> caught if you're not writing code to catch it? If you wr
On Saturday, April 11, 2015 at 9:47:36 AM UTC+5:30, Rustom Mody wrote:
> On Saturday, April 11, 2015 at 9:17:16 AM UTC+5:30, Dave Angel wrote:
> > On 04/10/2015 10:38 PM, Rustom Mody wrote:
> > > On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote:
> > >> On 04/10/2015 09:42 PM, St
On Saturday, April 11, 2015 at 9:17:16 AM UTC+5:30, Dave Angel wrote:
> On 04/10/2015 10:38 PM, Rustom Mody wrote:
> > On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote:
> >> On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
> >>> On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote:
> >
On 04/10/2015 10:38 PM, Rustom Mody wrote:
On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote:
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote:
It isn't document because it is expected. Why would the exception get
caught if you
On Saturday, April 11, 2015 at 7:53:31 AM UTC+5:30, Dave Angel wrote:
> On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
> > On Sat, 11 Apr 2015 05:31 am, sohcahtoa82 wrote:
> >
> >> It isn't document because it is expected. Why would the exception get
> >> caught if you're not writing code to catch
On 04/10/2015 09:42 PM, Steven D'Aprano wrote:
On Sat, 11 Apr 2015 05:31 am, [email protected] wrote:
It isn't document because it is expected. Why would the exception get
caught if you're not writing code to catch it? If you write a function
and pass it a tuple of exceptions to catch, I'
On Friday, April 10, 2015 at 2:18:22 PM UTC+5:30, Pavel S wrote:
> Hi,
>
> I noticed interesting behaviour. Since I don't have python3 installation
> here, I tested that on Python 2.7.
>
> Well known feature is that try..except block can catch multiple exceptions
> listed in a tuple:
>
>
> ex
On Sat, 11 Apr 2015 05:31 am, [email protected] wrote:
> It isn't document because it is expected. Why would the exception get
> caught if you're not writing code to catch it? If you write a function
> and pass it a tuple of exceptions to catch, I'm not sure why you would
> expect it to catc
On 04/10/2015 04:48 AM, Pavel S wrote:
Hi,
I noticed interesting behaviour. Since I don't have python3 installation here,
I tested that on Python 2.7.
Well known feature is that try..except block can catch multiple exceptions
listed in a tuple:
exceptions = ( TypeError, ValueError )
try:
On Sat, 21 Feb 2015 16:22:36 +0100, Peter Otten <[email protected]>
wrote:
>
>Why would you care about a few lines? You don't repeat them, do you? Put the
>code into a function or a context manager and invoke it with
Thanks for the suggestions that followed.
--
https://mail.python.org/mailman/li
On Sun, 22 Feb 2015 13:15:09 -0600, Skip Montanaro
wrote:
>
>Sorry, I haven't paid careful attention to this thread, so perhaps
>this has already been suggested, however... Can't you write your own
>class which delegates to the necessary sqlite3 bits and has a context
>manager with the desired be
On Sun, 22 Feb 2015 19:07:03 +, Mark Lawrence
wrote:
>
>Looks like you're correct. Knock me down with a feather, Clevor Trevor.
It took me by surprise when I first encountered it too. The rationale
apparently is that the context manager is strictly a transactional
feature, allowing for mult
On Sun, Feb 22, 2015 at 12:41 PM, Mario Figueiredo wrote:
> The sqlite context manager doesn't close a database connection on
> exit. It only ensures, commits and rollbacks are performed.
Sorry, I haven't paid careful attention to this thread, so perhaps
this has already been suggested, however..
On 22/02/2015 18:41, Mario Figueiredo wrote:
On Sat, 21 Feb 2015 12:22:58 +, Mark Lawrence
wrote:
Use your context manager at the outer level.
import sqlite3 as lite
try:
with lite.connect('data.db') as db:
try:
db.execute(sql, parms)
except lite.IntegrityError:
On Sat, 21 Feb 2015 12:22:58 +, Mark Lawrence
wrote:
>
>Use your context manager at the outer level.
>
>import sqlite3 as lite
>
>try:
> with lite.connect('data.db') as db:
> try:
> db.execute(sql, parms)
> except lite.IntegrityError:
> raise ValueError('invalid da
Ian Kelly wrote:
> On Sat, Feb 21, 2015 at 8:27 AM, Peter Otten <[email protected]> wrote:
>> Ian Kelly wrote:
>>
>>> On Sat, Feb 21, 2015 at 5:22 AM, Mark Lawrence
>>> wrote:
try:
with lite.connect('data.db') as db:
try:
db.execute(sql, parms)
except l
On Sat, Feb 21, 2015 at 8:27 AM, Peter Otten <[email protected]> wrote:
> Ian Kelly wrote:
>
>> On Sat, Feb 21, 2015 at 5:22 AM, Mark Lawrence
>> wrote:
>>> try:
>>> with lite.connect('data.db') as db:
>>> try:
>>> db.execute(sql, parms)
>>> except lite.IntegrityError:
>>>
Ian Kelly wrote:
> On Sat, Feb 21, 2015 at 5:22 AM, Mark Lawrence
> wrote:
>> On 21/02/2015 02:42, Mario Figueiredo wrote:
>>>
>>> Hello all,
>>>
>>> I'm using the following pattern for db access that requires me to
>>> close the connection as soon as it is not needed:
>>>
>>> import sq
Mario Figueiredo wrote:
> Hello all,
>
> I'm using the following pattern for db access that requires me to
> close the connection as soon as it is not needed:
>
> import sqlite3 as lite
>
> try:
> db = lite.connect('data.db')
> except lite.DatabaseError:
>
On Sat, Feb 21, 2015 at 5:22 AM, Mark Lawrence wrote:
> On 21/02/2015 02:42, Mario Figueiredo wrote:
>>
>> Hello all,
>>
>> I'm using the following pattern for db access that requires me to
>> close the connection as soon as it is not needed:
>>
>> import sqlite3 as lite
>>
>> t
On 21/02/2015 02:42, Mario Figueiredo wrote:
Hello all,
I'm using the following pattern for db access that requires me to
close the connection as soon as it is not needed:
import sqlite3 as lite
try:
db = lite.connect('data.db')
except lite.DatabaseErro
On Fri, Feb 20, 2015 at 6:42 PM, Mario Figueiredo wrote:
> import sqlite3 as lite
>
> try:
> db = lite.connect('data.db')
> except lite.DatabaseError:
> raise OSError('database file corrupt or not found.')
> else:
> try:
>
On 03Aug2014 10:39, Roy Smith wrote:
In article ,
bruce wrote:
I'm posting the test code I'm using. Pointers/comments would be
helpful/useful.
It would be really helpful if you could post a minimal code example
which demonstrates the problem you're having. Leave out everything
(including th
On 2014-08-03, Roy Smith wrote:
> In article ,
> Mark Lawrence wrote:
>
>> How to go about this is at "Short, Self Contained, Correct (Compilable),
>> Example" at http://sscce.org/
>
> It says there, "most readers will stop reading by 100 lines of code". I
> guess I have a short attention spa
You also posted this question to the [email protected] mailing list, which is
where I gave an answer. This is a much better place, so I'll re-post the
most important parts of my answer here. If you read nothing else, scroll
down to the end and read the last part of my comment.
bruce wrote:
> I ha
bruce wrote:
> Hi.
>
> I have a long running process, it generates calls to a separate py
> app. The py app appears to generate errors, as indicated in the
> /var/log/messages file for the abrtd daemon.. The errors are
> intermittent.
>
> So, to quickly capture all possible exceptions/errors, I
Hi Alan.
Yep, the err file in the exception block gets created. and the weird
thing is it matches the time of the abrtd information in the
/var/log/messages log..
Just nothing in the file!
On Sun, Aug 3, 2014 at 4:01 PM, Alan Gauld wrote:
> On 03/08/14 18:52, bruce wrote:
>
>>> but in all tha
On Sunday, August 3, 2014 10:39:19 PM UTC+8, Roy Smith wrote:
> In article ,
>
> bruce wrote:
>
>
>
> > I'm posting the test code I'm using. Pointers/comments would be
>
> > helpful/useful.
>
>
>
> It would be really helpful if you could post a minimal code example
>
> which demonstrat
On 03/08/14 18:52, bruce wrote:
but in all that.. no one could tell me .. why i'm not getting any
errs/exceptions in the err file which gets created on the exception!!!
Does the file actually get created?
Do you see the print statement output - are they what you expect?
Did you try the things
On Mon, Aug 4, 2014 at 3:52 AM, bruce wrote:
> chris.. my bad.. I wasnt intending to mail you personally.
>
> Or I wouldn't have inserted the "thanks guys"!
>
>
>> thanks guys...
>>
>> but in all that.. no one could tell me .. why i'm not getting any
>> errs/exceptions in the err file which gets c
chris.. my bad.. I wasnt intending to mail you personally.
Or I wouldn't have inserted the "thanks guys"!
> thanks guys...
>
> but in all that.. no one could tell me .. why i'm not getting any
> errs/exceptions in the err file which gets created on the exception!!!
>
> but thanks for the informat
On Mon, Aug 4, 2014 at 2:27 AM, Roy Smith wrote:
> It says there, "most readers will stop reading by 100 lines of code". I
> guess I have a short attention span relative to "most readers", because
> my tl;dnr threshold is a lot shorter than that.
"by" 100 lines includes everyone who stops at 10
In article ,
Mark Lawrence wrote:
> How to go about this is at "Short, Self Contained, Correct (Compilable),
> Example" at http://sscce.org/
It says there, "most readers will stop reading by 100 lines of code". I
guess I have a short attention span relative to "most readers", because
my tl;
On 03/08/2014 15:29, bruce wrote:
[snipped to bits]
Please see this http://sscce.org/ as already requested on the main
mailing list.
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/lis
On 03/08/2014 15:39, Roy Smith wrote:
In article ,
bruce wrote:
I'm posting the test code I'm using. Pointers/comments would be
helpful/useful.
It would be really helpful if you could post a minimal code example
which demonstrates the problem you're having. Leave out everything
(including
1 - 100 of 401 matches
Mail list logo
