097b00
>> Note: Task completed successfully.
>> Note: CRC:algo = 2, split_crc = 1, unused = 0, initiator_crc = d976d35e,
>> journal_crc = a176af10
>>
>>
>> I have the below piece of code but would like to make this better more
>> pythonic , I found regex pattern
have the below piece of code but would like to make this better more
pythonic , I found regex pattern and exception handling poor here , any
quick suggestion in your spare time is welcome.
#open the existing file if the flag is set and check if there is a match
log_file='/file.txt'
fl
; journal_crc = a176af10
>
>
> I have the below piece of code but would like to make this better more
> pythonic , I found regex pattern and exception handling poor here , any
> quick suggestion in your spare time is welcome.
>
>
> #open the existing file if t
regex pattern and exception handling poor here , any
quick suggestion in your spare time is welcome.
#open the existing file if the flag is set and check if there is a match
log_file='/file.txt'
flag_is_on=1
Use "True" instead of "1". A flag is a Boolean thing, a
ompleted successfully.
> Note: CRC:algo = 2, split_crc = 1, unused = 0, initiator_crc = d976d35e,
> journal_crc = a176af10
>
>
> I have the below piece of code but would like to make this better more
> pythonic , I found regex pattern and exception handling poor here , any
>
exception handling poor here , any
quick suggestion in your spare time is welcome.
#open the existing file if the flag is set and check if there is a match
log_file='/file.txt'
flag_is_on=1
data = None
with open(log_file, 'r') as f:
data = f.readlines()
if flag_is_o
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())
> >
Ian Kelly wrote:
> On Mon, Feb 8, 2016 at 2:17 AM, Veek. M wrote:
>>
>> Exceptions can be raised inside a coroutine using the throw(
>>
>> Exceptions raised in this manner will originate at the currently
>> executing yield state-ment in the coroutine.A coroutine can e
On Mon, Feb 8, 2016 at 2:17 AM, Veek. M wrote:
>
> Exceptions can be raised inside a coroutine using the throw(
>
> Exceptions raised in this manner will originate at the currently
> executing yield state-ment in the coroutine.A coroutine can elect to
> catch exception
Veek. M wrote:
>
> Exceptions can be raised inside a coroutine using the throw(
>
> Exceptions raised in this manner will originate at the currently
> executing yield state-ment in the coroutine.A coroutine can elect to
> catch exceptions and handle them as appropriat
Exceptions can be raised inside a coroutine using the throw(
Exceptions raised in this manner will originate at the currently
executing yield state-ment in the coroutine.A coroutine can elect to
catch exceptions and handle them as appropriate. It is not safe to use
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())
>
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())
count = count - 1
except socket.error as e
Chris Angelico writes:
> Aside from string exceptions and the "except Type, e:" syntax, I would
> agree with you. Actually, I can't think of any "obsolete
> exception-handling practices" in any language.
I'd say that context managers are a big recent im
On Tue, Nov 3, 2015 at 6:22 PM, Steven D'Aprano wrote:
> A lot can happen in the few microseconds between
> checking for the existence of the file and actually opening it -- the file
> could be renamed or deleted.
And a lot of microseconds can happen between two opcodes, too. Even
inside a Python
On Tue, 3 Nov 2015 06:16 pm, Chris Angelico wrote:
> Not to mention having race condition possibilities.
Arrggghhh! I knew there was something else I wanted to say.
You're right. Sometimes you *have* to use exception handling code. Take this
for example:
if os.path.exists(pathname
On Tue, Nov 3, 2015 at 5:47 PM, Steven D'Aprano wrote:
> On Fri, 30 Oct 2015 04:43 am, vasudevram wrote:
>
>> Are there any modern (i.e. for current versions of Python 2 and 3)
>> recommended exception handling practices?
>
> When you say "modern", it sou
Hi Vasudev, and welcome.
Sorry for the delay in replying to your questions. My answers inline, below.
On Fri, 30 Oct 2015 04:43 am, vasudevram wrote:
> Are there any modern (i.e. for current versions of Python 2 and 3)
> recommended exception handling practices?
When you say "
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 all,
Is there any way to roll back or undo changes which are all done before
exception occurs.
--
https://mail.python.org/mailman/listinfo/python-list
It's been answered here:
http://stackoverflow.com/questions/26924045/python-3-x-beazley-context-vs-
cause-attributes-in-exception-handling?noredirect=1#comment42403467_26924045
--
https://mail.python.org/mailman/listinfo/python-list
In 'Chained Exceptions' - Beazley pg:626
try:
pass
except ValueError as e:
raise SyntaxError('foo bar') from e
-
Here, if ValueError is raised and SyntaxError is then raised.. 'e' contains
__cause__ which points to the ValueError Traceback. He goes on to say:
--
On Tue, 27 Aug 2013 00:00:36 -0500, Skip Montanaro wrote:
> I found this question/answer on Stack Overflow:
>
> http://stackoverflow.com/questions/15123137
>
> but after fiddling around with it, I can't find a solution that works
> for Python 3.2 and 3.3, let alone 2.x. In 3.2, exceptions have
I found this question/answer on Stack Overflow:
http://stackoverflow.com/questions/15123137
but after fiddling around with it, I can't find a solution that works
for Python 3.2 and 3.3, let alone 2.x. In 3.2, exceptions have both
__cause__ and __context__ attributes. I tried setting both to Non
On 08/26/2013 07:49 PM, Skip Montanaro wrote:
Do this:
raise LockFailed("Failed to create %s" % self.path) from None
Thanks. Is there some construct which will work in 2.x and 3.x?
Something like this (untested):
exc = None
try:
write_pid_to_lockfile(somefile)
excep
> Do this:
>
> raise LockFailed("Failed to create %s" % self.path) from None
Thanks. Is there some construct which will work in 2.x and 3.x?
Skip
--
http://mail.python.org/mailman/listinfo/python-list
led: failed to create /tmp/skip/lock
When I rung the same code with Python 2.7, I get the exception output
I anticipate:
lock.acquire()
Traceback (most recent call last):
File "", line 1, in
File "lockfile/pidlockfile.py", line 94, in acquire
raise LockFailed("
When I rung the same code with Python 2.7, I get the exception output
I anticipate:
>>> lock.acquire()
Traceback (most recent call last):
File "", line 1, in
File "lockfile/pidlockfile.py", line 94, in acquire
raise LockFailed("failed to create %s" % self.p
gt;
> > statements seem to be used more within modules, main functions, wrapper
>
> > scripts.
>
>
>
> It depends on whose code you are reading. I don't write a lot of classes,
>
> but when I do, I often use try...except inside them.
>
>
>
>
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 wh
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
sort of things that you do at the top level often needs
exception handling. For example, you might have a fallback module:
try:
import this_module
except ImportError:
import that_module as this_module
You will very rarely see that inside a class, since you very rarely
import modules insi
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
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 what I have found (I
Steven D'Aprano wrote:
> try:
> main()
> except Exception as err:
> log(err)
> print("Sorry, an unexpected error has occurred.")
> print("Please contact support for assistance.")
> sys.exit(-1)
>
>
I like the traceback[0] module for logging last exception thrown.
See tracebac
On Tue, Apr 9, 2013 at 5:41 AM, wrote:
> try:
> response = urllib.request.urlopen(request)
> content = response.read()
> except BaseException as ue:
> if (isinstance(ue, socket.timeout) or (hasattr(ue, "reason") and
> isinstance(ue.reason, sock
On Wed, Apr 10, 2013 at 1:05 AM, Steven D'Aprano
wrote:
> One exception to this rule (no pun intended) is that sometimes you want
> to hide the details of unexpected tracebacks from your users. In that
> case, it may be acceptable to wrap your application's main function in a
> try block, catch an
On Tue, 09 Apr 2013 06:19:09 -0700, cabbar wrote:
> How do I
> handle all other exceptions, just say Exception: and handle them? I want
> to silently ignore them.
Please don't. That is normally poor practice, since it simply hides bugs
in your code.
As a general rule, you should only catch exce
cab...@gmail.com wrote:
> Ah, looks better.
>
> But, 2 questions:
>
> 1. I should also catch ConnectionResetError I am guessing.
Does it need a special reaction? If so give it its own except suite.
> 2. How do I handle all other exceptions, just say Exception: and handle
> them? I want to sile
On 4/9/2013 7:41 AM, cab...@gmail.com wrote:
Hi,
I have been using Java/Perl professionally for many years and have been trying
to learn python3 recently. As my first program, I tried writing a class for a
small project, and I am having really hard time understanding exception
handling in
Hi,
>
>
>
> I have been using Java/Perl professionally for many years and have been
> trying to learn python3 recently. As my first program, I tried writing a
> class for a small project, and I am having really hard time understanding
> exception handling in urllib
cab...@gmail.com wrote:
> Hi,
>
> I have been using Java/Perl professionally for many years and have been
> trying to learn python3 recently. As my first program, I tried writing a
> class for a small project, and I am having really hard time understanding
> exception handlin
Hi,
I have been using Java/Perl professionally for many years and have been trying
to learn python3 recently. As my first program, I tried writing a class for a
small project, and I am having really hard time understanding exception
handling in urllib and in python in general...
Basically
On Mon, Dec 3, 2012 at 6:30 PM, Steven D'Aprano
wrote:
> Yeah, in hindsight it was a pretty crappy example. But this sort of
> dynamism really is useful:
>
> def testRaises(exc, func, *args):
> try:
> result = func(*args)
> except exc:
> return
> raise AssertionError("e
On Mon, 03 Dec 2012 16:24:50 +1100, Chris Angelico wrote:
> On Mon, Dec 3, 2012 at 8:31 AM, Steven D'Aprano
> wrote:
>> Consider this piece of legal Python code:
>>
>> Err = None
>> if condition(x) > 100:
>> Err = OneException
>> elif another_condition(x):
>> Err = AnotherException
>> try
On Mon, Dec 3, 2012 at 8:31 AM, Steven D'Aprano
wrote:
> Consider this piece of legal Python code:
>
> Err = None
> if condition(x) > 100:
> Err = OneException
> elif another_condition(x):
> Err = AnotherException
> try:
> spam(a, b, c)
> except Err:
> recover()
Legal it may be, b
On Sun, 02 Dec 2012 12:25:22 -0500, Roy Smith wrote:
> This is kind of weird (Python 2.7.3):
>
> try:
> print "hello"
> except foo:
> print "foo"
>
> prints "hello". The problem (IMHO) is that apparently the except clause
> doesn't get evaluated until after some exception is caught. Wh
On 12/2/2012 12:25 PM, Roy Smith wrote:
This is kind of weird (Python 2.7.3):
try:
print "hello"
except foo:
print "foo"
prints "hello". The problem (IMHO) is that apparently the except clause
doesn't get evaluated until after some exception is caught. Which means
it never notices t
On 2/12/12 18:25:22, Roy Smith wrote:
> This is kind of weird (Python 2.7.3):
>
> try:
> print "hello"
> except foo:
> print "foo"
>
> prints "hello". The problem (IMHO) is that apparently the except clause
> doesn't get evaluated until after some exception is caught. Which means
> it
This is kind of weird (Python 2.7.3):
try:
print "hello"
except foo:
print "foo"
prints "hello". The problem (IMHO) is that apparently the except clause
doesn't get evaluated until after some exception is caught. Which means
it never notices that foo is not defined until it's too late
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
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.
Any help is greatly appreciated.
Lee
--
http://mail.python.org/mailman/listinfo/py
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(
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
1 - 100 of 301 matches
Mail list logo
