On Sun, 09 Dec 2012 14:22:21 +1100, Chris Angelico wrote:
> On Sun, Dec 9, 2012 at 2:07 PM, Ramchandra Apte
> wrote:
>> Not really. I remember a bug saying that only 256 hashes were required
>> of known texts and then the randomization becomes useless.
>
> That requires that someone be able to g
On Sun, Dec 9, 2012 at 2:07 PM, Ramchandra Apte wrote:
> Not really. I remember a bug saying that only 256 hashes were required of
> known texts and then the randomization becomes useless.
That requires that someone be able to get you to hash some text and
give back the hash. In any case, even i
On Thursday, 6 December 2012 17:44:17 UTC+5:30, Chris Angelico wrote:
> On Thu, Dec 6, 2012 at 10:47 PM, Steven D'Aprano
>
> wrote:
>
> > Not so. Which one is faster will depend on how often you expect to fail.
>
> > If the keys are nearly always present, then:
>
> >
>
> > try:
>
> > do
On 2012-12-08 07:17, Chris Angelico wrote:
On Sat, Dec 8, 2012 at 6:01 PM, Terry Reedy wrote:
Unfortunately, catching exceptions may be and often is as slow as the
redundant check and even multiple redundant checks.
It depends on how often you're going to catch and how often just flow
through
On Sat, Dec 8, 2012 at 6:01 PM, Terry Reedy wrote:
> Unfortunately, catching exceptions may be and often is as slow as the
> redundant check and even multiple redundant checks.
It depends on how often you're going to catch and how often just flow
through. In Python, as in most other modern langua
On 12/7/2012 5:16 PM, Steven D'Aprano wrote:
On Thu, 06 Dec 2012 23:14:17 +1100, Chris Angelico wrote:
Setting up the try/except is a constant time cost,
It's not just constant time, it's constant time and *cheap*. Doing
nothing inside a try block takes about twice as long as doing nothing:
On Thu, 06 Dec 2012 23:14:17 +1100, Chris Angelico wrote:
> Setting up the try/except is a constant time cost,
It's not just constant time, it's constant time and *cheap*. Doing
nothing inside a try block takes about twice as long as doing nothing:
[steve@ando ~]$ python2.7 -m timeit "try: pas
On 2012-12-07, Steven D'Aprano wrote:
> On Thu, 06 Dec 2012 13:51:29 +, Neil Cerutti wrote:
>
>> On 2012-12-06, Steven D'Aprano
>> wrote:
>>> total = 0
>>> for s in list_of_strings:
>>> try:
>>> total += int(s)
>>> except ValueError:
>>> pass # Not a number, ignore it
>> Calling it 'found' is misleading, because it's True only if it updated.
>> If it found a match but didn't update, 'found' will still be False.
>> Using a loop within a loop like this could be the cause of your
>> problem. It's certainly not the most efficient way of doing it.
>
> I will keep you
On Thu, 06 Dec 2012 13:51:29 +, Neil Cerutti wrote:
> On 2012-12-06, Steven D'Aprano
> wrote:
>> total = 0
>> for s in list_of_strings:
>> try:
>> total += int(s)
>> except ValueError:
>> pass # Not a number, ignore it.
>
> If it's internal data, perhaps. Of course,
On 06/12/2012 04:32, Steven D'Aprano wrote:
On Thu, 06 Dec 2012 03:22:53 +, Rotwang wrote:
[...]
Is there a problem with either of the above? If so, what should I do
instead?
They're fine.
Never, ever say that people should never, ever do something.
*cough*
Thanks.
--
I have made a
On 06/12/2012 08:49, Bruno Dupuis wrote:
On Thu, Dec 06, 2012 at 04:32:34AM +, Steven D'Aprano wrote:
On Thu, 06 Dec 2012 03:22:53 +, Rotwang wrote:
On 06/12/2012 00:19, Bruno Dupuis wrote:
[...]
Another advice: never ever
except XXXError:
pass
at least log, or count, or warn
> gmane.comp.python.general:
>
>> But basically, the code seems to run a pair of nested for-loops:
>>
>> for SKU in database:
>> for SKU in csv file:
>> if the two SKUs match:
>> compare their prices and update the database
>>
> OUCH...
>
> I'm presuming the
Here is the product in the CSV:
MONIIE2407HDS-B1;MON;II;E2407HDS-B1;E2407HDS-B1;IIYAMA LCD 24" Wide
1920x1080TN Speakers 2ms Black DVI HDMI;133;20;RECTD0.41;0,41;
> [snip]
> It's not saying that it's not found, it's saying that it wasn't updated
> because:
You are right
On 2012-12-06 17:31, Anatoli Hristov wrote:
Here is the product in the CSV:
MONIIE2407HDS-B1;MON;II;E2407HDS-B1;E2407HDS-B1;IIYAMA LCD 24" Wide
1920x1080TN Speakers 2ms Black DVI HDMI;133;20;RECTD0.41;0,41;
This one is still not found and it is in the CSV file - I just don't
get it why
>> Here is the product in the CSV:
>> MONIIE2407HDS-B1;MON;II;E2407HDS-B1;E2407HDS-B1;IIYAMA LCD 24" Wide
>> 1920x1080TN Speakers 2ms Black DVI HDMI;133;20;RECTD0.41;0,41;
This one is still not found and it is in the CSV file - I just don't
get it why !
>> if len(db_s
On 2012-12-06 14:22, Anatoli Hristov wrote:
Guys I'm still confusing my script is working better, but not enough.
I did a logfile to see which products are not found anymore in the CSV
and I found some that are present but python says they are not ??
Here is the product in the CSV:
MONIIE2407HDS
>> No one have an idea ?
>>
>> Thanks
>>
>
> Basically because your code is crap. Others have already suggested
> refactoring your code to make it easier to follow.
Thank you Mark for your notes. I changed the name of the variables as
was suggested before.
I know my code should be crappy, but at
On 06/12/2012 16:16, Anatoli Hristov wrote:
No one have an idea ?
Thanks
Basically because your code is crap. Others have already suggested
refactoring your code to make it easier to follow. Try (diabolical pun
very deliberate) following that advice. Failing that find out how much
it'
On Thu, Dec 6, 2012 at 3:22 PM, Anatoli Hristov wrote:
> Guys I'm still confusing my script is working better, but not enough.
> I did a logfile to see which products are not found anymore in the CSV
> and I found some that are present but python says they are not ??
>
> Here is the product in the
On 12/06/2012 10:58 AM, Chris Angelico wrote:
On Fri, Dec 7, 2012 at 12:33 AM, Thomas Rachel
wrote:
Am 06.12.2012 09:49 schrieb Bruno Dupuis:
The point is Exceptions are made for error handling, not for normal
workflow. I hate when i read that for example:
try:
do_stuff(mydic
On 12/06/2012 08:58 AM, Chris Angelico wrote:
> On Fri, Dec 7, 2012 at 12:33 AM, Thomas Rachel
>
> wrote:
>> Am 06.12.2012 09:49 schrieb Bruno Dupuis:
>>
>>> The point is Exceptions are made for error handling, not for normal
>>> workflow. I hate when i read that for example:
>>>
>>> try:
>>>
On Fri, Dec 7, 2012 at 1:21 AM, Hans Mulder wrote:
> Errhm, no. Look again. The do_stuff(value) call is in the "else:"
> clause, so it will only be done of there was no Exception of any
> kind, and in that case the assignment to value must have succeeded.
DOH! My bad. Sorry! I somehow didn't se
On 6/12/12 14:58:01, Chris Angelico wrote:
> On Fri, Dec 7, 2012 at 12:33 AM, Thomas Rachel
>
> wrote:
>> > Am 06.12.2012 09:49 schrieb Bruno Dupuis:
>> >
>>> >> The point is Exceptions are made for error handling, not for normal
>>> >> workflow. I hate when i read that for example:
>>> >>
>>> >>
Guys I'm still confusing my script is working better, but not enough.
I did a logfile to see which products are not found anymore in the CSV
and I found some that are present but python says they are not ??
Here is the product in the CSV:
MONIIE2407HDS-B1;MON;II;E2407HDS-B1;E2407HDS-B1;IIYAMA LCD
On Fri, Dec 7, 2012 at 12:33 AM, Thomas Rachel
wrote:
> Am 06.12.2012 09:49 schrieb Bruno Dupuis:
>
>> The point is Exceptions are made for error handling, not for normal
>> workflow. I hate when i read that for example:
>>
>> try:
>> do_stuff(mydict[k])
>> except KeyError:
>>
On 2012-12-06, Steven D'Aprano
wrote:
> total = 0
> for s in list_of_strings:
> try:
> total += int(s)
> except ValueError:
> pass # Not a number, ignore it.
If it's internal data, perhaps. Of course, that would mean I had
the option of *not* creating that stupid list_of_
On Fri, Dec 7, 2012 at 12:32 AM, Hans Mulder wrote:
> On 6/12/12 12:55:16, peter wrote:
>> Is perfectly right to use try catch for a flow control.
>> Just think in something more complex like this.
>>
>>try:
>> self._conn = MySQLdb.connect(host=host,
>> user=user,
>
Am 06.12.2012 09:49 schrieb Bruno Dupuis:
The point is Exceptions are made for error handling, not for normal
workflow. I hate when i read that for example:
try:
do_stuff(mydict[k])
except KeyError:
pass
I as well, but for other reasons (see below). But basically t
On 6/12/12 12:55:16, peter wrote:
> Is perfectly right to use try catch for a flow control.
> Just think in something more complex like this.
>
>try:
> self._conn = MySQLdb.connect(host=host,
> user=user,
> passwd=passwd,
> db=db)
>
On Thu, Dec 6, 2012 at 10:47 PM, Steven D'Aprano
wrote:
> Not so. Which one is faster will depend on how often you expect to fail.
> If the keys are nearly always present, then:
>
> try:
> do_stuff(mydict[k])
> except KeyError:
> pass
>
> will be faster. Setting up a try block is very fast
On 12/06/2012 08:47 AM, Steven D'Aprano wrote:
On Thu, 06 Dec 2012 09:49:26 +0100, Bruno Dupuis wrote:
The point is Exceptions are made for error handling, not for normal
workflow.
That's certainly not the case in Python. Using exceptions for flow
control is a standard part of the language.
I
On Thu, 06 Dec 2012 09:49:26 +0100, Bruno Dupuis wrote:
> The point is Exceptions are made for error handling, not for normal
> workflow.
That's certainly not the case in Python. Using exceptions for flow
control is a standard part of the language.
IndexError and StopIteration are used to dete
On Thu, Dec 6, 2012 at 1:31 AM, Steven D'Aprano
wrote:
> On Wed, 05 Dec 2012 23:50:49 +0100, Anatoli Hristov wrote:
>
>
>> def Change_price():
>
> Misleading function name. What price does it change?
>
>
>> total = 0
>> tnf = 0
>
> "tnf"? Does that mean something?
>
>
>> for row in DB:
On Thu, Dec 6, 2012 at 7:49 PM, Bruno Dupuis
wrote:
>
> The point is Exceptions are made for error handling, not for normal
> workflow. I hate when i read that for example:
>
> try:
> do_stuff(mydict[k])
> except KeyError:
> pass
>
> (loads of them in many libraries and fra
On Thu, Dec 06, 2012 at 04:32:34AM +, Steven D'Aprano wrote:
> On Thu, 06 Dec 2012 03:22:53 +, Rotwang wrote:
>
> > On 06/12/2012 00:19, Bruno Dupuis wrote:
> >> [...]
> >>
> >> Another advice: never ever
> >>
> >> except XXXError:
> >> pass
> >>
> >> at least log, or count, or warn,
On Thu, 06 Dec 2012 03:22:53 +, Rotwang wrote:
> On 06/12/2012 00:19, Bruno Dupuis wrote:
>> [...]
>>
>> Another advice: never ever
>>
>> except XXXError:
>> pass
>>
>> at least log, or count, or warn, or anything, but don't pass.
>
> Really? I've used that kind of thing several times in
On 06/12/2012 00:19, Bruno Dupuis wrote:
[...]
Another advice: never ever
except XXXError:
pass
at least log, or count, or warn, or anything, but don't pass.
Really? I've used that kind of thing several times in my code. For
example, there's a point where I have a list of strings and I
On Thu, 06 Dec 2012 01:19:58 +0100, Bruno Dupuis wrote:
> I tried, I swear I did try, I didn't understand the whole algorithm of
> the function. However, in a first sight, I find it way to deeply nested.
Yes!
But basically, the code seems to run a pair of nested for-loops:
for SKU in database:
On Wed, 05 Dec 2012 23:50:49 +0100, Anatoli Hristov wrote:
> def Change_price():
Misleading function name. What price does it change?
> total = 0
> tnf = 0
"tnf"? Does that mean something?
> for row in DB: # DB is mySQL DB, logically I get out
> # 1 SKU and
On Wed, Dec 05, 2012 at 11:50:49PM +0100, Anatoli Hristov wrote:
> I'm confused again with a compare update function. The problem is that
> my function does not work at all and I don't get it where it comes
> from.
>
> in my DB I have total of 754 products. when I run the function is says:
> Total
41 matches
Mail list logo
