Updated my guide to python packaging.

exhuma · 7 days

Wow... thanks! :]

exhuma · 7 days

You're welcome! And thanks :)

exhuma · 7 days

Whooooops.... :)

Added the link :)

exhuma · 12 days

you're welcome! :)

exhuma · 12 days

... and what if it's utf16? :P

exhuma · 12 days

I don't see the need to use exec in your case. You are opening a file called version.py, so I assume you store nothing but your version number in it? I was thinking about doing the same thing. But then you can simply import it. No need for exec.

exhuma · 12 days

glad to be of service ^_^

exhuma · 13 days

hmmm... you're absolutely right. I never ran into this. I actually nicked the idea from the IBM page (http://www.ibm.com/developerworks/opensource/library/os-pythonpackaging/)

I ~~'ll make~~ made a note about this in the article. Thanks!

exhuma · 13 days

... and not package at all until then?

"Wars" like these will always exist. If this one ends, a new one will appear eventually.

It is true that the current state of affairs is confusing at best. But since distribute is backwards compatible with setuptools, I believe it is safe enough to go ahead anyways. There are so many packages using either distribute or setuptools that whatever will surface in the future cannot allow itself to break all this (or force user to back-port). There will be a smooth transition. One way or another...

exhuma · 13 days

I understand your feelings about entry points. I had the same for a while. But entry points seem to be the recommended way of doing this, when using distribute.

Importing sys and so on from inner code does not seem odd to me at all. Depending on the situation, I already tend to write my imports as close as possible (scope-wise) to the code using it. As python caches imports, there is no noteworthy performance impact. But it makes the code more readable, and it much easier to move methods around from one file to another.

Coming back to entry points: I particularly like the fact that it creates .exe files on windows. Granted, it's not the same as a package compiled with py2exe but it's still a nice touch.

Also, if I remember correctly, the contents of the generated scripts are nicer when using entry-points (they use pkg_resources). Using scripts as explained in the standard library does not use pkg_resources as that's not part of the stdlib.

exhuma · 13 days

I now replaced the pkg_resources link with a small paragraph about this into the document.... making the article a bit more "comprehensive" ;)

exhuma · 13 days

I agree. It was a lengthy article which I wrote in one take. I thought about it, but only had the energy (my fingers started being dyslexic...) to add a small note about it and link to the appropriate section in the distribute docs... ;)

Maybe I'll edit it in later...

Corrosivecoke · 20 days

The great thing about it is that, because there are that many more players, the distribution of skill is much larger. So, Blizzard's MMR system, pretty much anyone can play online without too much trouble.

I remember SC1 back in the days. I only rarely played online, as you had to pay internet by the hour, and is was expensive! So I quickly got left behind in skill and it became unplayable.

I know also play not that much, but still can enjoy random ladder games. :)

Corrosivecoke · 20 days

Indeed: http://imgur.com/gacPw (an encoding problem replaced the euro sign with a question mark)

Corrosivecoke · 20 days

time to get back into it man... ;)

Corrosivecoke · 20 days

let me confirm that. I was in the middle of it, and I had nerd-chills everywhere.... especially in the Nesta/Alive matches....

Corrosivecoke · 20 days

Nope. We had to wait as well inside due to technical problems. It could have been anything.

Corrosivecoke · 20 days

I was there... this is probably not even half of the line! I just got back home and uploaded the pictures. I took one after each turn in the road.

My last picture is taken from the other end of OP's picture. This should give you an even clearer picture of the epicness....

Onething to note: HUUUGE props to the "Grand Rex" team. Once the doors opened, the people were inside in no time. The organisation of it all was examplary! Really, really, really good!

~~Before clicking the link, be aware, that one picture is missing. I am in the process of re-uploading. It takes a while. My upload speed is not enormous!~~

~~Link: http://imgur.com/a/3DNjg~~

UPDATE: All 4 pictures: http://imgur.com/a/M5QHm

mattotodd · 26 days

A related post has shown up today: http://alarmingdevelopment.org/?p=680 (http://www.reddit.com/r/programming/comments/szsie/an_ide_is_not_enough)

skittixch · 26 days

I messed up in my post: MDB2 should have been PDO instead!

skittixch · 26 days

I disagree. Popular frameworks will actually teach you to do things "the right way". Never use bottom-level database access functions in production code! Use it as a learning experience.

But be aware, that you will be learning things you will unlikely use in the future. Don't get me wrong. It is good to be aware of the inner workings. But you will only need it if ...

... the library you use does not (completely/correctly) expose all internal DB functionalities.
... you need to optimise things. Also remember: "Premature optimisation is the root of all evil" (Knuth)

It is much more important to know your database's SQL dialect properly!

skittixch · 27 days

update: I completely mixed up MDB2 with PDO! So replace MDB2 in this post with PDO! ;)

I find myself using the zend framework for many things. It also does DB abstraction. Their tutorial works you through that too.

I would never recomment using the low-level database access methods. It is very error prone, and you have SQL-injection vulnerable code in no-time if not careful. If on the other hand you are carful, then the code become very messy. Plenty of mysql_real_escape_string calls for example (Who came up with that idiotic name anyway?).

As others have suggested, look into abstraction librarie. As - like mentioned - the Zend Framework. Or, what I used before ZF: MDB2.

ZF has the advantage that it gives you a lot more than only DB abstraction!

Oh... and don't worry. When I started, I did not want to know abstraction libraries because I wanted to understand it down to the guts. But, truth be told, very few applications nowadays need the down-to-the-metal db-library calls (as always there are exceptions).

exhuma

TROPHY CASE

you'll need to login or register to do that

create a new account

login