how to remove number
susanti marsol
santi_anti at yahoo.com
Tue Aug 21 05:18:26 EDT 2007
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 <__peter__ at web.de> 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 <__peter__ at web.de> 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.html>
More information about the Python-list
mailing list