«

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'll cost to fix and get your cheque book out, perhaps that'll focus
your mind. I'll not apologise for being blunt as your follow up is less
than two hours after your previous post.

--
Cheers.

Mark Lawrence.

>> 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 least I try as I'm a beginner
in a programming at all - this is a good exercise for me.

>Try (diabolical pun very
> deliberate) following that advice. Failing that find out how much it'll
> cost to fix and get your cheque book out, perhaps that'll focus your mind.
> I'll not apologise for being blunt as your follow up is less than two hours
> after your previous post.

It seems the arrogance is in your blood Nice shot


Anatoli

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-B1;MON;II;E2407HDS-B1;E2407HDS-B1;IIYAMA LCD 24" Wide
> 1920x1080TN Speakers 2ms Black DVI HDMI;133;20;RECTD0.41;0,41;;;;;;;;;
>
> Here is what python reports:
> e2208hds-b2, 721 not found
> e2273hds-b1, 722 not found
> e2274hds-b2, 723 not found
> e2407hds-b1, 724 not found
>
> And here is my final code: ( I hope it look better now )
>
> def Change_price(): # Changes the price in the DB if the price in the CSV is changed
> TotalUpdated = 0 # Counter for total updated
> TotalSKUFound = 0 # Total SKU from the DB coresponds to the one in the CSV
> TotalSKUinDB = 0 # Total SKU in the DB
> for row in PRODUCTSDB:
> TotalSKUinDB +=1
> db_sku = row["sku"].lower()
> db_price = float(row["price"])
> found = False
> try:
> for x in pricelist:
> try:
> csv_price = x[6]
> csv_price = csv_price.replace(",",".")
> csv_price = float(csv_price)
> csv_new_price = csv_price*1.10
> csv_sku = x[4].lower()
> csv_stock = int(x[7]) # I used this as normally I used stock in the condition
> match = re.search(db_sku, csv_sku)

This line is equivalent to:

match = db_sku in csv_sku

This means that it's looking for db_sku anywhere in csv_sku. For
example, all of these are true: "72" in "720"; "20" in "720"; "720" in
"720"; etc.

> if len(db_sku) != 0 and match:
> TotalSKUFound +=1

TotalSKUFound is incremented if it finds a match.

Can "db_sku in csv_sku" be true multiple times for a given value of
db_sku? (See above.) Is it possible that TotalSKUFound is incremented
multiple times for some values of csv_sku?

> if csv_new_price < db_price and csv_stock > 0:
> print db_sku, csv_price, db_price, csv_new_price
> Update_SQL(csv_new_price, db_sku)
> TotalUpdated += 1
> found = True

It sets found to True if it updated.
>
> except IndexError: # I have a lot of index error in the CSV (empty fields) and the loop gives "index error" I don't care about them
> pass
> except ValueError:
> pass
> except TypeError:
> pass

Even after finding a match (and possibly updating), it continues
iterating though pricelist.

> except IndexError:

There's no need to catch IndexError here because the only places it
could be raised are also within the inner try..except.

> pass
> if not found: WriteLog(db_sku, db_sku,)

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.

> TotalNotFound = TotalSKUinDB - TotalSKUFound
> print "Total SKU in the DB %s" % TotalSKUinDB
> print "Total SKU coresponds to the DB and CSV %s" % TotalSKUFound
> print "Total updated: %s" % TotalUpdated
> print"Total not found with in the distributor: %s" % TotalNotFound
>
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.

>> 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_sku) != 0 and match:
>> TotalSKUFound +=1
> TotalSKUFound is incremented if it finds a match.
>
> Can "db_sku in csv_sku" be true multiple times for a given value of
> db_sku? (See above.) Is it possible that TotalSKUFound is incremented
> multiple times for some values of csv_sku?

Most of the SKU's are not doubled in the CSV, but what I will do is to
create new function to compare each SKU so after it founds the SKU in
the file it will return right away to the DB loop.

>> if csv_new_price < db_price and csv_stock > 0:
>> print db_sku, csv_price, db_price,
>> csv_new_price
>> Update_SQL(csv_new_price, db_sku)
>> TotalUpdated += 1
>> found = True

> It sets found to True if it updated.
>> except IndexError: # I have a lot of index error in the
>> CSV (empty fields) and the loop gives "index error" I don't care about them
>> pass
>> except ValueError:
>> pass
>> except TypeError:
>> pass
>
>
> Even after finding a match (and possibly updating), it continues
> iterating though pricelist.

Yes it will change after I create the new func.as I assume.

>> except IndexError:
>
>
if not found: WriteLog(db_sku, db_sku,)
>
>
> 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 posted THANK YOU

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 !
>
[snip]
It's not saying that it's not found, it's saying that it wasn't updated
because:

csv_new_price < db_price and csv_stock > 0

was False. Is the new price higher or the same?

>>>>
>>>> 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, the price at the distributor is higher than the one I
have I will update the price what ever the price is I will not
compare it anymore.

Thanks

On 06 Dec 2012 00:42:00 GMT, Steven D'Aprano
<steve+> declaimed the following in
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 CSV is restarted each time the database record
changes...

That would seem better reformulated as:

for (SKU, price) in CSV:
DB.execute("update SKUtable set price = %s where SKU = %s",
(price, SKU) )
--
Wulfraed Dennis Lee Bieber AF6VN
HTTP://wlfraed.home.netcom.com/

> 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 CSV is restarted each time the database record
> changes...
>
> That would seem better reformulated as:
>
> for (SKU, price) in CSV:
> DB.execute("update SKUtable set price = %s where SKU = %s",
> (price, SKU) )
> --
I don't know if I get it right, but
Nope, each loop I'm getting:
for x in CSV:
MONIIE2409HDS-B1;MON;II;E2409HDS-B1;E2409HDS-B1;IIYAMA LCD 24" Wide
1920x1080 TN Panel Speakers 2MS Black;130;9;RECTD0.41;0,41;;;;;;;;;

So x[4] is my SKU and x[5] is price and so on. Each loop looks like this.

On 06/12/2012 08:49, Bruno Dupuis wrote:
> On Thu, Dec 06, 2012 at 04:32:34AM +0000, Steven D'Aprano wrote:
>> On Thu, 06 Dec 2012 03:22:53 +0000, 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 my code. For
>>> example, there's a point where I have a list of strings and I want to
>>> create a list of those ints that are represented in string form in my
>>> list, so I do this:
>>>
>>> listofints = []
>>> for k in listofstrings:
>>> try:
>>> listofints.append(int(k))
>>> except ValueError:
>>> pass
>>>
>>> Another example: I have a dialog box with an entry field where the user
>>> can specify a colour by entering a string, and a preview box showing the
>>> colour. I want the preview to automatically update when the user has
>>> finished entering a valid colour string, so whenever the entry field is
>>> modified I call this:
>>>
>>> def preview(*args):
>>> try:
>>> previewbox.config(bg = str(entryfield.get()))
>>> except tk.TclError:
>>> pass
>>>
>>> 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*
>>
>
> Well, dependening on the context (who provides listofstrings?) I would
> log or count errors on the first one... or not.

The actual reason for the first example is that I have a text widget
with a bunch of tags (which are identified by strings), and I want to
add a new tag whose name doesn't coincide with any of the existing tag
names. I achieve this by setting my listofstrings equal to the list of
existing tag names, and setting the new tag name as

str(max(listofints) + 1) if listofints else '0'

I realise that there are a bunch of other ways I could have done this.
But I haven't a clue how I could rewrite the second example without
using a try statement (other than by writing a function that would
recognise when a string defines a valid Tkinter colour, including the
long and possibly version-dependent list of colours with Zoolanderesque
names like 'LightSteelBlue3').


> On the second one, I would split the expression, because (not sure of
> that point, i didn't import tk for years) previewbox.config and
> entryfield.get may raise a tk.TclError for different reasons.
>
> The point is Exceptions are made for error handling, not for normal
> workflow.

Although I'm something of a noob, I'm pretty sure the Python community
at large would disagree with this, as evidenced by the fact that 'EAFP'
is an entry in the official Python glossary:

EAFP
Easier to ask for forgiveness than permission. This common Python
coding style assumes the existence of valid keys or attributes and
catches exceptions if the assumption proves false. This clean and
fast style is characterized by the presence of many try and except
statements. The technique contrasts with the LBYL style common to
many other languages such as C.

(from http://docs.python.org/2/glossary.html)

--
I have made a thing that superficially resembles music:

http://soundcloud.com/eroneity/we-be...-own-crapiness

On 06/12/2012 04:32, Steven D'Aprano wrote:
> On Thu, 06 Dec 2012 03:22:53 +0000, 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 thing that superficially resembles music:

http://soundcloud.com/eroneity/we-be...-own-crapiness