FAQ
how to remove all number in our's document?

python-list-request at python.org wrote: Send Python-list mailing list submissions to
python-list at python.org

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-list
or, via email, send a message with subject or body 'help' to
python-list-request at python.org

You can reach the person managing the list at
python-list-owner at python.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-list digest..."
Today's Topics:

1. Re: GeneratorExit should derive from BaseException, not
Exception (Chad Austin)
2. Re: GeneratorExit should derive from BaseException, not
Exception (Chad Austin)
3. Re: Newbee Question (Asun Friere)
4. Re: Is there a way to change the default string encoding?
(Ron Garret)
5. Re: Is there a way to change the default string encoding?
(Fabio Z Tessitore)
6. Re: Newbee Question (Asun Friere)
7. Re: Is there a way to change the default string encoding?
(Peter Otten)
8. Re: Newbee Question (Asun Friere)
9. Re: yet another indentation proposal (Dennis Lee Bieber)
10. Re: datetime in microseconds (Dennis Lee Bieber)
11. Re: Newbee Question (Dennis Lee Bieber)
From: Chad Austin <chad at imvu.com>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:01:01 -0700
Subject: Re: GeneratorExit should derive from BaseException, not Exception

Hi Terry,

Thank you for your feedback. Responses inline:

Terry Reedy wrote:
"Chad Austin" wrote in message
news:46CA0EFE.6020103 at imvu.com...
try:
result = yield chatGateway.checkForInvite({'userId': userId})
logger.info('checkForInvite2 returned %s', result)
would not
except GeneratorExit:
solve your problem?
Yes, we could add an "except GeneratorExit: raise" clause to every place
we currently catch Exception, but I feel like this is one of those
things where it's hard to get it right in all places and also hard to
cover with unit tests. Instead, we'll have subtle bugs where finally
clauses don't run because the GeneratorExit was swallowed.

Also, SystemExit and KeyboardInterrupt were made into BaseExceptions for
the same reasons as I'm giving. (As I understand it, anyway.)
except Exception:
Such catchalls are known to be prone to catch too much
and are therefore not encouraged ;-).
As in 'use at your own risk'.
Guido encourages specific catches just for the reasons you give here.
More below:
There was a *long* discussion of the current 2.5 exception hierarchy on
pydev. Search either python.org's or gmane's archive if you want to pursue
this. But I expect the people involved would say much the same as above.
I've actually read the background on the exception hierarchy (and agree
with it all), especially other suggestions that GeneratorExit derive
from BaseException. As I understand it, Guido's objections are threefold:

1) The previous "generators as coroutines" examples were too
theoretical: I've wanted GeneratorExit to derive from BaseException for
months now, but didn't write this proposal until I actually wrote code
that failed in the presence of task cancellation.

2) You should avoid catching everything with except Exception: I think
that's too idealistic. Just do a search for try: except: through
publicly available Python. :) Sometimes, you really _do_ want to catch
everything. When you're making a network request that involves
xmlrpclib, urllib2, httplib, etc. you don't actually care what the error
was. (Well, except that the exceptions are submitted for automated
analysis.) Similarly, when loading a cache file with pickle, I don't
care what went wrong, because it's not critical and should not be turned
into a crash for the user. (We automatically report exceptions that
bubble into the main loop as crashes.)

3) If GeneratorExit escapes from the generator somehow and gets raised
in the main loop, then it will bubble out of the application like
SystemExit and KeyboardInterrupt would: I think this argument is
somewhat specious, because I can't imagine how that would happen. You'd
have to store exceptions in your generator and explicitly bubble them
out somehow. Our crash handling has to specially handle
KeyboardInterrupt and SystemExit anyway, since there are currently
non-Exception exceptions, such as strings and custom classes that forgot
to derive from Exception, that should count as crashes.

I personally can't think of any cases where I would _want_ to handle
GeneratorExit. I just want finally: and with: clauses to do the right
thing when a task is cancelled. Anyway, I haven't yet encountered any
serious bugs due to this yet... I'm just worried that if a task is
holding some resource and blocking on something, then the resource won't
get released. If this really does come up, then I do have a little bit
of python + ctypes that replaces GeneratorExit with ImvuGeneratorExit
(deriving from BaseException), but that's not very appealing.

Thanks again,

--
Chad Austin
http://imvu.com/technology


From: Chad Austin <chad at imvu.com>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:41:03 -0700
Subject: Re: GeneratorExit should derive from BaseException, not Exception

Oops, forgot to mention this:

I wouldn't be opposed to a different extension that would effectively
let me accomplish the same goals... arbitrary exception filters.
Imagine this:

try:
raise GeneratorExit
except ExceptionFilter:
# blah

where ExceptionFilter is any object that can be tested for containment.
Perhaps implemented like this:

class ExceptionFilter(object):
def __init__(self):
self.includes = set()
self.excludes = set()

self.include = self.includes.add
self.exclude = self.excludes.add

def __contains__(self, exc):
return any(isinstance(exc, cls) for cls in self.includes) and \
not any(isinstance(exc, cls) for cls in self.excludes)

ImvuExceptionFilter = ExceptionFilter()
ImvuExceptionFilter.include(Exception)
ImvuExceptionFilter.exclude(GeneratorExit)

Then, our code could just "catch" ImvuExceptionFilter. This type of
extension would be backwards compatible with the current except
(FooError, BarError) tuple syntax.

I've never hacked on CPython itself, so I don't know what kind of
changes there would be involved, but if there is sufficient pushback
against making GeneratorExit derive from BaseException, I think this is
a fine alternative. Thoughts?

Chad

Chad Austin wrote:
Hi Terry,

Thank you for your feedback. Responses inline:

Terry Reedy wrote:
"Chad Austin" wrote in message
news:46CA0EFE.6020103 at imvu.com...
try:
result = yield chatGateway.checkForInvite({'userId': userId})
logger.info('checkForInvite2 returned %s', result)
would not
except GeneratorExit:
solve your problem?
Yes, we could add an "except GeneratorExit: raise" clause to every place
we currently catch Exception, but I feel like this is one of those
things where it's hard to get it right in all places and also hard to
cover with unit tests. Instead, we'll have subtle bugs where finally
clauses don't run because the GeneratorExit was swallowed.

Also, SystemExit and KeyboardInterrupt were made into BaseExceptions for
the same reasons as I'm giving. (As I understand it, anyway.)
except Exception:
Such catchalls are known to be prone to catch too much
and are therefore not encouraged ;-).
As in 'use at your own risk'.
Guido encourages specific catches just for the reasons you give here.
More below:
There was a *long* discussion of the current 2.5 exception hierarchy on
pydev. Search either python.org's or gmane's archive if you want to pursue
this. But I expect the people involved would say much the same as above.
I've actually read the background on the exception hierarchy (and agree
with it all), especially other suggestions that GeneratorExit derive
from BaseException. As I understand it, Guido's objections are threefold:

1) The previous "generators as coroutines" examples were too
theoretical: I've wanted GeneratorExit to derive from BaseException for
months now, but didn't write this proposal until I actually wrote code
that failed in the presence of task cancellation.

2) You should avoid catching everything with except Exception: I think
that's too idealistic. Just do a search for try: except: through
publicly available Python. :) Sometimes, you really _do_ want to catch
everything. When you're making a network request that involves
xmlrpclib, urllib2, httplib, etc. you don't actually care what the error
was. (Well, except that the exceptions are submitted for automated
analysis.) Similarly, when loading a cache file with pickle, I don't
care what went wrong, because it's not critical and should not be turned
into a crash for the user. (We automatically report exceptions that
bubble into the main loop as crashes.)

3) If GeneratorExit escapes from the generator somehow and gets raised
in the main loop, then it will bubble out of the application like
SystemExit and KeyboardInterrupt would: I think this argument is
somewhat specious, because I can't imagine how that would happen. You'd
have to store exceptions in your generator and explicitly bubble them
out somehow. Our crash handling has to specially handle
KeyboardInterrupt and SystemExit anyway, since there are currently
non-Exception exceptions, such as strings and custom classes that forgot
to derive from Exception, that should count as crashes.

I personally can't think of any cases where I would _want_ to handle
GeneratorExit. I just want finally: and with: clauses to do the right
thing when a task is cancelled. Anyway, I haven't yet encountered any
serious bugs due to this yet... I'm just worried that if a task is
holding some resource and blocking on something, then the resource won't
get released. If this really does come up, then I do have a little bit
of python + ctypes that replaces GeneratorExit with ImvuGeneratorExit
(deriving from BaseException), but that's not very appealing.

Thanks again,
--
Chad Austin
http://imvu.com/technology

From: Asun Friere <afriere at yahoo.co.uk>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:41:59 -0700
Subject: Re: Newbee Question

Oh well since a few solutions have already been posted I thought I
might add another, just so you at the very least you have to do some
work making up your mind which one to choose. Using an incremental
approach just to be different ...

from decimal import Decimal

normal = Decimal('0.04')
over = Decimal('1.40)

def calcStopPay (stops) :
pay = Decimal('0.00')
while stops :
incr = normal if stops < 23 else over
pay += incr
stops -= 1
return pay

#testing:
for x in range(50) :
print "Stop pay for %s stops: $%s" % (x, calcStopPay(x))


From: Ron Garret <rNOSPAMon at flownet.com>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:42:45 -0700
Subject: Re: Is there a way to change the default string encoding?

In article ,
Peter Otten wrote:
If all else fails there's
sys.setdefaultencoding("latin1")
"Andre\xe9 Ramel".decode()
u'Andre\xe9 Ramel'

but that's an evil hack, you should rather talk to the maintainer of the
offending code to update it to accept unicode.
Yes, but I need to hack around it until I can get it fixed.

Thanks!

rg

From: Fabio Z Tessitore <fabioztessitore at libero.it>
To: python-list at python.org
Date: 21 Aug 2007 07:44:46 GMT
Subject: Re: Is there a way to change the default string encoding?

Il Mon, 20 Aug 2007 18:44:39 -0700, Ron Garret ha scritto:
Is there a way to change the default string encoding ...
Dive Into Python. Section 9 on http://diveintopython.org/xml_processing/
unicode.html

That will help.

Bye
Fabio

From: Asun Friere <afriere at yahoo.co.uk>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:51:45 -0700
Subject: Re: Newbee Question
On Aug 21, 5:41 pm, Asun Friere wrote:
over = Decimal('1.40)
oops, that should of course be:
over = Decimal('1.40')


From: Peter Otten <__peter__ at web.de>
To: python-list at python.org
Date: Tue, 21 Aug 2007 09:49:56 +0200
Subject: Re: Is there a way to change the default string encoding?

Ron Garret wrote:
In article ,
Peter Otten wrote:
If all else fails there's
sys.setdefaultencoding("latin1")
"Andre\xe9 Ramel".decode()
u'Andre\xe9 Ramel'

but that's an evil hack, you should rather talk to the maintainer of the
offending code to update it to accept unicode.
Yes, but I need to hack around it until I can get it fixed.
Oops, the snippet above omits the actual hack. It should be
import sys
reload(sys)
sys.setdefaultencoding("latin1")
"Andre\xe9 Ramel".decode()
u'Andre\xe9 Ramel'

Peter

From: Asun Friere <afriere at yahoo.co.uk>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:54:53 -0700
Subject: Re: Newbee Question
On Aug 21, 5:51 pm, Asun Friere wrote:
On Aug 21, 5:41 pm, Asun Friere wrote:> over = Decimal('1.40)

oops, that should of course be:
over = Decimal('1.40')
oh boy ... and it should also be
normal = Decimal('0.40')

I really need to test before posting ...


From: Dennis Lee Bieber <wlfraed at ix.netcom.com>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:57:39 -0700
Subject: Re: yet another indentation proposal

On Mon, 20 Aug 2007 04:51:06 GMT, James Stroud
declaimed the following in comp.lang.python:

What's wrong with just saying the current indent level? I'd much rather
hear "indent 4" than "tab tab tab tab".
Well... the latter doesn't require a Python aware vocalizer...

Though yes... something that would report on repeated "whitespace"
would be nicer... "four-tabs" vs "32-spaces"

--
Wulfraed Dennis Lee Bieber KD6MOG
wlfraed at ix.netcom.com wulfraed at bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: web-asst at bestiaria.com)
HTTP://www.bestiaria.com/

From: Dennis Lee Bieber <wlfraed at ix.netcom.com>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:57:39 -0700
Subject: Re: datetime in microseconds

On Mon, 20 Aug 2007 07:58:42 -0700, mroeloffs at gmail.com declaimed the
following in comp.lang.python:

microsecs -= 31536000000000 # -1 Year
There is no "year 0", one goes from 1 BC to AD 1
microsecs -= 1123200000000 # -13 Days (magic?)
Sounds like the conversion from Julian to Gregorian calendars...


I wonder what would result if one converted your microseconds into
fraction days, and fed that to a JD to calendar conversion.
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfraed at ix.netcom.com wulfraed at bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: web-asst at bestiaria.com)
HTTP://www.bestiaria.com/

From: Dennis Lee Bieber <wlfraed at ix.netcom.com>
To: python-list at python.org
Date: Tue, 21 Aug 2007 00:57:39 -0700
Subject: Re: Newbee Question

On Mon, 20 Aug 2007 07:51:10 -0700, kyosohma at gmail.com declaimed the
following in comp.lang.python:
On Aug 20, 9:23 am, "HD1956" wrote:
This is probably a simple code. I am a truck driver who gets paid by
stops and cases. I am trying to figure out how to code my stop pay. I
get 40 cents per stop up to 22 stops, and $1.40 per stops after that.
def calc(num):
if num < 23:
return 0.4 * num
else:
overtime = num - 22
x = 0.4 * 22
x += overtime * 1.4
return x

# Use your own brain next time

Mike
pay = min(num, 22) * 0.4 + max(num-22, 0) * 1.4
--
Wulfraed Dennis Lee Bieber KD6MOG
wlfraed at ix.netcom.com wulfraed at bestiaria.com
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: web-asst at bestiaria.com)
HTTP://www.bestiaria.com/

--
http://mail.python.org/mailman/listinfo/python-list


---------------------------------
Boardwalk for $500? In 2007? Ha!
Play Monopoly Here and Now (it's updated for today's economy) at Yahoo! Games.

---------------------------------
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-list/attachments/20070821/a05c9962/attachment-0001.htm

Search Discussions

  • Gabriel Genellina at Aug 27, 2007 at 4:12 am
    En Tue, 21 Aug 2007 06:18:26 -0300, susanti marsol <santi_anti at yahoo.com>
    escribi?:
    how to remove all number in our's document?
    Can you be more specific?

    --
    Gabriel Genellina


    From http Mon Aug 27 06:11:03 2007
    From: http (Paul Rubin)
    Date: 26 Aug 2007 21:11:03 -0700
    Subject: beginner, idiomatic python
    References: <13cqlqbbpn0dmea@corp.supernews.com>
    <1187898049.734696.9500@l22g2000prc.googlegroups.com>
    <13csi2tn49esmc3@corp.supernews.com>
    <mailman.230.1187928865.32294.python-list@python.org>
    <13csqk47j0c56b0@corp.supernews.com>
    <CqSdnRl2x8928FPbnZ2dnUVZ_jSdnZ2d@speakeasy.net>
    <13ct7v3qn2v5206@corp.supernews.com>
    <mailman.238.1187948359.32294.python-list@python.org>
    <13d49lk6ue2as6d@corp.supernews.com>
    <13d4hutad1dq699@corp.supernews.com>
    Message-ID: <7xk5rhvcq0.fsf@ruckus.brouhaha.com>

    "bambam" <david at asdf.asdf> writes:
    Is it safe to write
    A = [x for x in A if x in U]
    or is that undefined? I understand that the slice operation
    can be used to make a temporary copy, so I could write
    A=[x for x in A[:] if x in U]
    but I've just copied that without any understanding.
    You get a temporary copy either way; note you're going to linearly
    search U on every pass. Maybe you want:

    SU = set(u)
    A = [a for x in A if x in SU]

    or possibly

    A = list(set(A) & set(U))

    which will remove duplicate elements from A and not necessarily keep
    them in the same order, but is likely to be fastest of the bunch.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedAug 21, '07 at 9:18a
activeAug 27, '07 at 4:12a
posts2
users2
websitepython.org

People

Translate

site design / logo © 2022 Grokbase