On Monday, February 8, 2016 at 1:05:08 AM UTC-7, shaunak...@gmail.com wrote:
> On Sunday, February 7, 2016 at 1:23:32 AM UTC-7, dieter wrote:
> > Shaunak Bangale writes:
> > > ...
> > > while (count > 0):
> > > try :
> > > # read line from file:
> > > print(file.readline())
> >
On Sunday, February 7, 2016 at 1:23:32 AM UTC-7, dieter wrote:
> Shaunak Bangale writes:
> > ...
> > while (count > 0):
> > try :
> > # read line from file:
> > print(file.readline())
> > # parse
> > parse_json(file.readline())
> > count = count - 1
> >
Shaunak Bangale writes:
> ...
> while (count > 0):
> try :
> # read line from file:
> print(file.readline())
> # parse
> parse_json(file.readline())
> count = count - 1
> except socket.error as e:
> print('Connection fail', e)
> print
I do have the initiation command defined. Just that I am not allowed to
make the username, pwd public.
I am absolutely sure I am running the same code. Now opened the same file
with Python 3.5 shell and I get following error:
from _ssl import RAND_status, RAND_egd, RAND_add
ImportError: cannot
Hi Martin,
Answering your questions below:
On Fri, Feb 5, 2016 at 1:50 PM, Shaunak Bangale
wrote:
> Hi Martin,
>
> Thanks for the detailed reply. I edited, saved and opened the file again.
> Still I am getting exactly the same error.
>
> Putting bigger chunk of code and the error again:
>
>
>
Hi Martin,
Thanks for the detailed reply. I edited, saved and opened the file again.
Still I am getting exactly the same error.
Putting bigger chunk of code and the error again:
# create socket
s = socket.socket(socket.AF_INET)
#create a SSL context with the recommended security settings for c
On Sat, Feb 6, 2016 at 9:35 AM, wrote:
> On Friday, February 5, 2016 at 12:58:37 PM UTC-7, shaunak...@gmail.com wrote:
>> I am running this python script on R-studio. I have Python 3.5 installed on
>> my system.
>>
>> count = 10
>> while (count > 0):
>> try :
>> # read line from file
On Friday, February 5, 2016 at 12:58:37 PM UTC-7, shaunak...@gmail.com wrote:
> I am running this python script on R-studio. I have Python 3.5 installed on
> my system.
>
> count = 10
> while (count > 0):
> try :
> # read line from file:
> print(file.readline())
> # pa
On Friday, February 5, 2016 at 12:58:37 PM UTC-7, shaunak...@gmail.com wrote:
> I am running this python script on R-studio. I have Python 3.5 installed on
> my system.
>
> count = 10
> while (count > 0):
> try :
> # read line from file:
> print(file.readline())
> # pa
On Sat, Feb 6, 2016 at 8:08 AM, Bernardo Sulzbach
wrote:
> On 02/05/2016 07:01 PM, Chris Angelico wrote:
>>
>> On Sat, Feb 6, 2016 at 6:58 AM, wrote:
>>>
>>> I am running this python script on R-studio. I have Python 3.5 installed
>>> on my system.
>>>
>>
>> Let's just try a quick smoke test. Ru
On 02/05/2016 07:26 PM, shaunak.bang...@gmail.com wrote:
from _ssl import RAND_status, RAND_egd, RAND_add
ImportError: cannot import name 'RAND_egd'
I believe I've already seen this issue myself. It has to do with
LibreSSL not having RAND_egd for some reason I can't recall.
This seems
On Friday, February 5, 2016 at 2:09:11 PM UTC-7, Bernardo Sulzbach wrote:
> On 02/05/2016 07:01 PM, Chris Angelico wrote:
> > On Sat, Feb 6, 2016 at 6:58 AM, wrote:
> >> I am running this python script on R-studio. I have Python 3.5 installed
> >> on my system.
> >>
> >
> > Let's just try a quic
On 02/05/2016 07:01 PM, Chris Angelico wrote:
On Sat, Feb 6, 2016 at 6:58 AM, wrote:
I am running this python script on R-studio. I have Python 3.5 installed on my
system.
Let's just try a quick smoke test. Run this script:
import sys
print(sys.version)
input("Press Enter to exit...")
Th
Hi there,
>Thanks for the detailed reply. I edited, saved and opened the file
>again. Still I am getting exactly the same error.
>
>Putting bigger chunk of code and the error again:
[snipped; thanks for the larger chunk]
>Error:
>except socket.error as e:
> ^
>SyntaxErr
On Sat, Feb 6, 2016 at 6:58 AM, wrote:
> I am running this python script on R-studio. I have Python 3.5 installed on
> my system.
>
Let's just try a quick smoke test. Run this script:
import sys
print(sys.version)
input("Press Enter to exit...")
That'll tell you a few things about how your sy
Hi there Shaunak,
I saw your few replies to my (and Nathan's) quick identification of
syntax error. More comments follow, here.
>I am running this python script on R-studio. I have Python 3.5 installed on my
>system.
>
>count = 10
>while (count > 0):
>try :
># read line from file:
On Friday, February 5, 2016 at 1:09:35 PM UTC-7, Martin A. Brown wrote:
> >except socket.error as e
>
> >line 53 except socket.error as e ^ SyntaxError: invalid syntax
> >
> >I tried changing socket.error to ConnectionRefusedError. and still
> >got the same error.
>
> >Please tell me if the
On Friday, February 5, 2016 at 1:11:19 PM UTC-7, shaunak...@gmail.com wrote:
> On Friday, February 5, 2016 at 1:08:11 PM UTC-7, Nathan Hilterbrand wrote:
> > On Feb 5, 2016 15:01, wrote:
> > >
> > > I am running this python script on R-studio. I have Python 3.5 installed
> > on my system.
> > >
>
On Friday, February 5, 2016 at 1:08:11 PM UTC-7, Nathan Hilterbrand wrote:
> On Feb 5, 2016 15:01, wrote:
> >
> > I am running this python script on R-studio. I have Python 3.5 installed
> on my system.
> >
> > count = 10
> > while (count > 0):
> > try :
> > # read line from file:
> >
>except socket.error as e
>line 53 except socket.error as e ^ SyntaxError: invalid syntax
>
>I tried changing socket.error to ConnectionRefusedError. and still
>got the same error.
>Please tell me if the problem is with Rstudio, Python version or
>the syntax.
Syntax.
Your code has, unfor
On Feb 5, 2016 15:01, wrote:
>
> I am running this python script on R-studio. I have Python 3.5 installed
on my system.
>
> count = 10
> while (count > 0):
> try :
> # read line from file:
> print(file.readline())
> # parse
> parse_json(file.readline())
>
Palpandi writes:
> Thanks for your responses. And I have one more question.
> This is the situation. A python application which reads data from one .xml
> file and generates some other file. Here what kind of exceptions occur?
Ideally, you would not get any exceptions.
In the not ideal case, y
On Thu, 9 Apr 2015 07:31 pm, Palpandi wrote:
> Hi all,
>
> Is there any way to roll back or undo changes which are all done before
> exception occurs.
Not automatically. You have to program it yourself.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, Apr 9, 2015 at 7:31 PM, Palpandi wrote:
> Hi all,
>
> Is there any way to roll back or undo changes which are all done before
> exception occurs.
In Python itself? Not directly; there are no facilities for undoing
Python code. But if you're serious about integrity, you probably want
to b
Hi Steven,
Yea this is great. Thanks for the feedback.
On Saturday, August 24, 2013 3:27:45 AM UTC-7, Steven D'Aprano wrote:
> On Fri, 23 Aug 2013 22:25:55 -0700, snarf wrote:
>
>
>
> [...]
>
> > * Seems like exception handing within Classes is largely avoided and is
>
> > typically only use
Appreciate the feedback. I was hoping to get as much perspective as possible.
On Saturday, August 24, 2013 12:18:59 AM UTC-7, Dave Angel wrote:
> snarf wrote:
>
>
>
> > Greetings,
>
> >
>
> > As I tread through my journey of OO I am trying to determine if there is a
> > good approach for ex
On Sat, 24 Aug 2013 15:57:55 -0400, Terry Reedy wrote:
>> # Worst
>> except:
>>
>> Don't use the last one, except maybe in the interactive interpreter,
>
> Stick with never. "except:" means the same thing as "except
> BaseException:", except that the latter indicates a deliberate choice
> rather
On 8/24/2013 6:27 AM, Steven D'Aprano wrote:
On Fri, 23 Aug 2013 22:25:55 -0700, snarf wrote:
[...]
* Seems like exception handing within Classes is largely avoided and is
typically only used when calling external libraries.
There is certainly no rule "avoid exceptions inside classes". Method
On 24/08/2013 11:27, Steven D'Aprano wrote:
On Fri, 23 Aug 2013 22:25:55 -0700, snarf wrote:
[snip]
* Using
Exception is typically a bad. More specific the better.
Yes, you should always try to catch the specific exceptions you care
about:
# Best
except ValueError, OverflowError, ZeroDivisi
On Fri, 23 Aug 2013 22:25:55 -0700, snarf wrote:
[...]
> * Seems like exception handing within Classes is largely avoided and is
> typically only used when calling external libraries.
There is certainly no rule "avoid exceptions inside classes". Methods
often raise exceptions to signal an error
snarf wrote:
> Greetings,
>
> As I tread through my journey of OO I am trying to determine if there is a
> good approach for exception handling within classes.
>
> From my readings and gatherings - it seems I have found a common theme, but I
> am trying to solicit from the experts.
>
> Here is w
Ulrich Eckhardt, 25.10.2011 08:49:
Am 23.10.2011 14:41, schrieb Stefan Behnel:
That's just fine. If you are interested in the inner mechanics of the
CPython runtime, reading the source is a very good way to start getting
involved with the project.
However, many extension module authors don't ca
Am 23.10.2011 14:41, schrieb Stefan Behnel:
That's just fine. If you are interested in the inner mechanics of the
CPython runtime, reading the source is a very good way to start getting
involved with the project.
However, many extension module authors don't care about these inner
mechanics and j
For a moment, back to the basics...
I am using the example provided by docs at 2.1.2
"Providing finer control...". Using say:
mynoddy = noddy2.Noddy()
mynoddy.first = "a"
mynoddy.last = 0
the last line causes an ugly crash (on python 2.6.5 on winxp).
No way to catch the exception.
As I understa
Hi,
note that I reformatted your posting to get the replies back into order.
Lee, 23.10.2011 13:32:
On Oct 23, 10:06 pm, Stefan Behnel wrote:
Lee, 23.10.2011 06:09:
Where does PyExc_TypeError (and alike) points to? I can see its
declaration - PyAPI_DATA(PyObject *) PyExc_TypeError; - in pyerr
Am 23.10.2011 06:09, schrieb Lee:
> Hi all,
>
> Where does PyExc_TypeError (and alike) points to? I can see its
> declaration - PyAPI_DATA(PyObject *) PyExc_TypeError; - in pyerrors.h
> but I cannot figure out what it is its value, where it is
> initialized.
It's initialized in Objects/exceptions
Thanks Stefan,
I am just interested to understand the mechanism inside python.
If it points to an object that means I can defered it (through
ob_type).
>From there, how a function like PyErr_SetString knows what exception
is?
Where its value is kept?
Lee
On Oct 23, 10:06 pm, Stefan Behnel wro
Lee, 23.10.2011 06:09:
Where does PyExc_TypeError (and alike) points to? I can see its
declaration - PyAPI_DATA(PyObject *) PyExc_TypeError; - in pyerrors.h
but I cannot figure out what it is its value, where it is
initialized.
It gets initialised inside of the interpreter core and then points
Ethan Furman writes:
> Ethan Furman wrote:
>> Arnaud Delobelle wrote:
>>>
>>> I missed the start of this discussion but there are two simpler ways:
>>>
>>> def func(iterable):
>>> for x in iterable:
>>> print(x)
>>> return
>>> raise ValueError("... empty iterable")
>>
>>
>
Ethan Furman wrote:
Arnaud Delobelle wrote:
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError("... empty iterable")
For the immediate case this is a cool solution.
Drat --
Ethan Furman wrote:
Please don't top-post.
Rob Richardson wrote:
-Original Message-
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError("... empty iterable")
Or using 3
Arnaud Delobelle wrote:
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError("... empty iterable")
For the immediate case this is a cool solution.
Unfortunately, it doesn't fix t
"Rob Richardson" writes:
You shouldn't top-post!
> Arnaud,
>
> Wouldn't your first suggestion exit after the first element in iterable?
Yes, after printing that element, which is what the code I quoted did.
> And would your second suggestion throw an exception after normal
> processing of all
Please don't top-post.
Rob Richardson wrote:
-Original Message-
I missed the start of this discussion but there are two simpler ways:
def func(iterable):
for x in iterable:
print(x)
return
raise ValueError("... empty iterable")
Or using 3.x's next's optional
Arnaud,
Wouldn't your first suggestion exit after the first element in iterable?
And would your second suggestion throw an exception after normal
processing of all elements in the interator?
RobR
-Original Message-
I missed the start of this discussion but there are two simpler ways:
Paul Rubin writes:
> Steven D'Aprano writes:
>> Apart from this horrible idiom:
>>
>> def func(iterable):
>> it = iter(iterable)
>> failed = False
>> try:
>> x = next(it)
>> except StopIteration:
>> failed = True
>> if failed:
>> raise ValueError("can'
On 12/7/2010 1:48 AM, MRAB wrote:
> Perhaps Python could use Guido's time machine to check whether the
> sequence will yield another object in the future. :-)
Since there's only one time machine that would effectively be a lock
across all Python interpreters.
regards
Steve
--
Steve Holden
On 12/7/2010 5:58 AM, John Nagle wrote:
>PEP 255, like too much Python literature, doesn't distinguish clearly
> between the language definition and implementation detail. It says
> "The mechanics of StopIteration are low-level details, much like the
> mechanics of IndexError in Python 2.1". A
John Nagle writes:
>PEP 255, like too much Python literature, doesn't distinguish
> clearly between the language definition and implementation detail. It
> says "The mechanics of StopIteration are low-level details, much like
> the mechanics of IndexError in Python 2.1". Applications should
On 12/6/2010 4:23 PM, Steven D'Aprano wrote:
On Mon, 06 Dec 2010 13:13:40 -0800, Paul Rubin wrote:
It's really unfortunate, though, that Python 3 didn't offer a way to
peek at the next element of an iterable and test emptiness directly.
This idea of peekable iterables just won't die, despite
On 12/6/2010 2:24 PM, Mark Wooding wrote:
John Nagle writes:
Right. You're not entitled to assume that StopIteration is how a
generator exits. That's a CPyton thing; generators were a retrofit,
and that's how they were hacked in. Other implementations may do
generators differently.
This i
On 07/12/2010 00:23, Steven D'Aprano wrote:
On Mon, 06 Dec 2010 13:13:40 -0800, Paul Rubin wrote:
It's really unfortunate, though, that Python 3 didn't offer a way to
peek at the next element of an iterable and test emptiness directly.
This idea of peekable iterables just won't die, despite t
On Mon, 06 Dec 2010 13:13:40 -0800, Paul Rubin wrote:
> It's really unfortunate, though, that Python 3 didn't offer a way to
> peek at the next element of an iterable and test emptiness directly.
This idea of peekable iterables just won't die, despite the obvious flaws
in the idea.
There's no g
John Nagle writes:
> Right. You're not entitled to assume that StopIteration is how a
> generator exits. That's a CPyton thing; generators were a retrofit,
> and that's how they were hacked in. Other implementations may do
> generators differently.
This is simply wrong. The StopIteration exc
Steven D'Aprano writes:
> Apart from this horrible idiom:
>
> def func(iterable):
> it = iter(iterable)
> failed = False
> try:
> x = next(it)
> except StopIteration:
> failed = True
> if failed:
> raise ValueError("can't process empty iterable")
> p
On 12/3/2010 5:04 AM, Steven D'Aprano wrote:
Consider the following common exception handling idiom:
def func(iterable):
it = iter(iterable)
try:
x = next(it)
except StopIteration:
raise ValueError("can't process empty iterable")
print(x)
The intention is:
On Fri, 03 Dec 2010 17:08:38 +0100, Peter Otten wrote:
> After rereading the original post I still don't get why the workarounds
> provided in those links aren't worth considering.
The first work-around:
http://mail.python.org/pipermail/python-list/2010-October/1258606.html
is unsuitable beca
On Fri, 03 Dec 2010 16:26:19 +0100, Hrvoje Niksic wrote:
> Peter Otten <__pete...@web.de> writes:
>
>>> Note that StopIteration is an internal detail of no relevance
>>> whatsoever to the caller. Expose this is unnecessary at best and
>>> confusing at worst.
>>
>> http://mail.python.org/pipermail
On Fri, 03 Dec 2010 10:15:58 -0800, Paul Rubin wrote:
> Steven D'Aprano writes:
>> def func(iterable):
>> it = iter(iterable)
>> failed = False
>> try:
>> x = next(it)
>> except StopIteration:
>> failed = True
>> if failed:
>> raise ValueError("can't pr
Peter Otten wrote:
Hrvoje Niksic wrote:
Peter Otten <__pete...@web.de> writes:
Note that StopIteration is an internal detail of no relevance whatsoever
to the caller. Expose this is unnecessary at best and confusing at
worst.
http://mail.python.org/pipermail/python-list/2010-October/1258606.
Peter Otten wrote:
> http://mail.python.org/pipermail/python-list/2010-October/1258606.html
http://mail.python.org/pipermail/python-list/2010-October/1259024.html
I found #6210 on bugs.python.org -- does anyone know if there are any
others regarding this issue? Or any progress on MRAB's idea
Steven D'Aprano writes:
> def func(iterable):
> it = iter(iterable)
> failed = False
> try:
> x = next(it)
> except StopIteration:
> failed = True
> if failed:
> raise ValueError("can't process empty iterable")
> print(x)
Untested:
from itertoo
Hrvoje Niksic wrote:
> Peter Otten <__pete...@web.de> writes:
>
>>> Note that StopIteration is an internal detail of no relevance whatsoever
>>> to the caller. Expose this is unnecessary at best and confusing at
>>> worst.
>>
>> http://mail.python.org/pipermail/python-list/2010-October/1258606.ht
Peter Otten <__pete...@web.de> writes:
>> Note that StopIteration is an internal detail of no relevance whatsoever
>> to the caller. Expose this is unnecessary at best and confusing at worst.
>
> http://mail.python.org/pipermail/python-list/2010-October/1258606.html
> http://mail.python.org/piperm
Steven D'Aprano wrote:
> Consider the following common exception handling idiom:
>
> def func(iterable):
> it = iter(iterable)
> try:
> x = next(it)
> except StopIteration:
> raise ValueError("can't process empty iterable")
> print(x)
>
> The intention is:
>
> *
Steven D'Aprano writes:
> Consider the following common exception handling idiom:
>
> def func(iterable):
> it = iter(iterable)
> try:
> x = next(it)
> except StopIteration:
> raise ValueError("can't process empty iterable")
> print(x)
Not exactly what you're look
Zeynel wrote:
> On Nov 5, 1:26 pm, Peter Otten <__pete...@web.de> wrote:
>
>> Of course I'm only guessing because you don't provide enough context.
>>
>> Peter
>
> Thanks.
>
> This is the problem I am having, in general:
>
> K = [] # a container list
> K = ["A", "B"]
>
> ARCHIVE = [] # a lis
Dennis Lee Bieber wrote:
>> The problem I am having is this: If I do:
>>
>> K = []
>> ARCHIVE = []
>> ARCHIVE.append(K)
>>
>> any time K is updated (user submits new input) the content of ARCHIVE
>> is erased:
>>
> No, it is NOT erased... It is MUTATED...
But he rebinds the ARCHIVE name.
--
ht
On Oct 29, 8:53 am, rantingrick wrote:
> I am the programmer, and when i say to my interpretor "show this
> exception instead of that exception" i expect my interpretor to do
> exactly as i say or risk total annihilation!! I don't want my
> interpreter "interpreting" my intentions and then doing
On Nov 5, 1:26 pm, Peter Otten <__pete...@web.de> wrote:
> Of course I'm only guessing because you don't provide enough context.
>
> Peter
Thanks.
This is the problem I am having, in general:
K = [] # a container list
K = ["A", "B"]
ARCHIVE = [] # a list where items from K is archived
ARCHIV
Zeynel wrote:
> I want to append new input to list SESSION_U without erasing its
> content. I try this:
>
> ...
> try:
> SESSION_U.append(UNIQUES)
> except NameError:
> SESSION_U = []
> SESSION_U.append(UNIQUES)
> ...
> I would think that at fir
On 10/24/2010 5:36 AM, Steve Holden wrote:
On 10/24/2010 2:22 AM, Lawrence D'Oliveiro wrote:
In message, Steve
Holden wrote:
Yes, *if the exception is caught* then it doesn't make any difference.
If the exception creates a traceback, however, I maintain that the
additional information is conf
In message , Antoine
Pitrou wrote:
> If you want to present exceptions to users in a different way ...
sys.stderr.write \
(
"Traceback (most recent call last):\n"
...
"AttributeError: blah blah blah ...\n"
)
--
http://mail.python.org/mailman/listinfo/python-list
Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
wrote:
I think what's disturbing about this is that the two halves of
the extended traceback are printed in the wrong order. We're
True, but swapping the order would only worsen Steve's problem.
Yes, I can see that what S
MRAB wrote:
On 29/10/2010 11:24, Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
wrote:
Chris Rebert wrote:
Your Traceback is merely being made slightly longer/more
complicated than you'd prefer; however, conversely, what if a bug was
to be introduced into your exception
MRAB wrote:
On 24/10/2010 13:28, Steve Holden wrote:
On 10/24/2010 4:48 AM, Martin v. Loewis wrote:
Am 24.10.2010 07:01, schrieb Steve Holden:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it
reports it
as a s
On 24/10/2010 13:28, Steve Holden wrote:
On 10/24/2010 4:48 AM, Martin v. Loewis wrote:
Am 24.10.2010 07:01, schrieb Steve Holden:
I was somewhat surprised to discover that Python 3 no longer allows an
exception to be raised in an except clause (or rather that it reports it
as a separate except
On 29/10/2010 11:24, Chris Rebert wrote:
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
wrote:
Chris Rebert wrote:
Your Traceback is merely being made slightly longer/more
complicated than you'd prefer; however, conversely, what if a bug was
to be introduced into your exception handler? Then
On Oct 24, 7:36 am, Steve Holden wrote:
> I don't want people to think this is a big deal, however.
Nonsense, this IS a big deal. (and Steve grow a spine already!) I was
not even aware of this issue until you brought it up -- although i
will admit your choice of title is completely misleading!
On Fri, Oct 29, 2010 at 2:30 AM, Gregory Ewing
wrote:
> Chris Rebert wrote:
>>
>> Your Traceback is merely being made slightly longer/more
>> complicated than you'd prefer; however, conversely, what if a bug was
>> to be introduced into your exception handler? Then you'd likely very
>> much apprec
Chris Rebert wrote:
Your Traceback is merely being made slightly longer/more
complicated than you'd prefer; however, conversely, what if a bug was
to be introduced into your exception handler? Then you'd likely very
much appreciate the "superfluous" Traceback info.
I think what's disturbing abo
Steve Holden wrote:
Yeah, that's a given. Ruby would probably let you do that, but Python
insists that you don't dick around with the built-in types. And roghtly
so, IMHO.
Some restrictions on this are necessary -- it obviously
wouldn't be safe to allow replacing the class of an
object with on
On 10/25/2010 2:57 AM, Martin v. Loewis wrote:
> Am 24.10.2010 23:48, schrieb Steve Holden:
>> On 10/24/2010 4:44 PM, John Nagle wrote:
>>> Are exception semantics changing in a way which would affect
>>> that?
>>
>> No, I don't believe so. I simply felt that the traceback gives too
>> much info
Am 24.10.2010 23:48, schrieb Steve Holden:
> On 10/24/2010 4:44 PM, John Nagle wrote:
>> Are exception semantics changing in a way which would affect that?
>
> No, I don't believe so. I simply felt that the traceback gives too much
> information in the case where an exception is specifically being
On 10/24/2010 7:51 PM, Ben Finney wrote:
> which means, AFAICT, that re-binding ‘__class__’ is only allowed for
> objects of a type defined in the Python run-time heap, not those defined
> in C code (like the built-in-exception types).
Yeah, that's a given. Ruby would probably let you do that, but
In message , Steve
Holden wrote:
> Yes, *if the exception is caught* then it doesn't make any difference.
> If the exception creates a traceback, however, I maintain that the
> additional information is confusing to the consumer (while helpful to
> the debugger of the consumed code).
Who needs t
Steve Holden writes:
> I simply felt that the traceback gives too much information in the
> case where an exception is specifically being raised to replace the
> one currently being handled.
Ideally, that description of the problem would suggest the obvious
solution: replace the class of the exc
On 10/24/2010 4:44 PM, John Nagle wrote:
> Are exception semantics changing in a way which would affect that?
No, I don't believe so. I simply felt that the traceback gives too much
information in the case where an exception is specifically being raised
to replace the one currently being handled.
On 10/23/2010 10:42 PM, Steve Holden wrote:
On 10/24/2010 1:26 AM, Chris Rebert wrote:
I was somewhat surprised to discover that Python 3 no longer
allows an
exception to be raised in an except clause (or rather that it
reports it as a separate exception that occurred during the
handling of the
On 10/24/10 16:01, Steve Holden wrote:
> I was somewhat surprised to discover that Python 3 no longer allows an
> exception to be raised in an except clause (or rather that it reports it
> as a separate exception that occurred during the handling of the first).
FYI, Java has a similar behavior. In
On 10/24/2010 2:22 AM, Lawrence D'Oliveiro wrote:
> In message , Steve
> Holden wrote:
>
>> I was somewhat surprised to discover that Python 3 no longer allows an
>> exception to be raised in an except clause (or rather that it reports it
>> as a separate exception that occurred during the handli
On 10/24/2010 4:48 AM, Martin v. Loewis wrote:
> Am 24.10.2010 07:01, schrieb Steve Holden:
>> I was somewhat surprised to discover that Python 3 no longer allows an
>> exception to be raised in an except clause (or rather that it reports it
>> as a separate exception that occurred during the handl
Steve Holden wrote:
> On 10/24/2010 1:26 AM, Chris Rebert wrote:
>>> I was somewhat surprised to discover that Python 3 no longer allows an
>>> > exception to be raised in an except clause (or rather that it reports
>>> > it as a separate exception that occurred during the handling of the
>>> > fi
Am 24.10.2010 07:01, schrieb Steve Holden:
> I was somewhat surprised to discover that Python 3 no longer allows an
> exception to be raised in an except clause (or rather that it reports it
> as a separate exception that occurred during the handling of the first).
I think you are misinterpreting
In message , Steve
Holden wrote:
> I was somewhat surprised to discover that Python 3 no longer allows an
> exception to be raised in an except clause (or rather that it reports it
> as a separate exception that occurred during the handling of the first).
So what exactly is the problem? Exceptio
On 10/24/2010 1:26 AM, Chris Rebert wrote:
>> I was somewhat surprised to discover that Python 3 no longer allows an
>> > exception to be raised in an except clause (or rather that it reports it
>> > as a separate exception that occurred during the handling of the first).
>
[snip]
>> > What
>> > i
On Sat, Oct 23, 2010 at 10:01 PM, Steve Holden wrote:
> I was somewhat surprised to discover that Python 3 no longer allows an
> exception to be raised in an except clause (or rather that it reports it
> as a separate exception that occurred during the handling of the first).
> Give the traceback
On Aug 12, 3:31 pm, a...@pythoncraft.com (Aahz) wrote:
> In article
> <2a47b306-45d1-474a-9f8e-5b71eba62...@p11g2000prf.googlegroups.com>,
>
> CM wrote:
>
> >Maybe it's not much of an issue, but I think it would be a shame if
> >occasional hangs/crashes could be caused by these (rare?) database
>
In article <2a47b306-45d1-474a-9f8e-5b71eba62...@p11g2000prf.googlegroups.com>,
CM wrote:
>
>Maybe it's not much of an issue, but I think it would be a shame if
>occasional hangs/crashes could be caused by these (rare?) database
>conflicts if there is a good approach for avoiding them. I guess I
Lie a écrit :
On Aug 21, 12:59 am, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
On Wed, 20 Aug 2008 09:23:22 -0700, [EMAIL PROTECTED] wrote:
On Aug 19, 4:12 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
On Tue, 19 Aug 2008 11:07:39 -0700, [EMAIL PROTECTED]
1 - 100 of 175 matches
Mail list logo
