Top responses guys! This has all helped increadibly. Bearophile,
My applogies if I have offended you, but: 1. "I can't know much about you from the start" - Is kind of my point. Perhaps it would be better to avoid jumping to conclusions and pre- judging someones abilities simply because they are lacking knowledge in a particular area. Would it have been better if I had opened my thread with a copy of my CV? I've got a Degree in Digital Systems Engineering (yes I am also an Engineer)... I went on to do a Phd in AI and Robotics where I also developed embedded systems. I bummed out on that after 3 years and went on to work for a games company where I worked on 6 game titles across 5 different platforms. I was a Lead Software Engineer for the last 5 years. Before now moving on again. 2. I am also very much a follower of the K.I.S.S. approach, 9 times out of 10 the simplest solution is often the best. As an Engineer though I would also suggest that the best way to learn is to try solving a problem being sure to constantly assess your approach and then your final solution. By dismissing a possible avenue you are dismissing a whole new path of knowledge. Is it not better to try and fail than never try at all? Surely this is how we gain the valuable experience we need. By simply suggesting a "simple default" solution, I may never have consider the alternatives nor understand why they are or are not suitable. 3. I get your point about Students, sometimes there is such a thing as too much knowledge or information overload. Whilst doing a PhD I had to take labs and teach students... The approach I tried to take was one off, "You may not need packages, why do you think you need packages?" or "This is how packages would be used and why they would be used... do you still think you need packages" or better still, for a capable student, "This is how packages work, try solving your problem and then tell me if you think it was a good solution." Going with R. David Murray, perhaps I also jumped too my own conclusion too quickly and for that I appologise. Cheers, Shaun On 24 Mar, 12:37, bearophileh...@lycos.com wrote: > CinnamonDonkey: > > > It is neither constructive nor educational. > > > It's a bit like saying "If you don't know what a function is, then > > maybe you don't need it. ... have you tried having a single block of > > code?" > > > The point of people coming to these forums is to LEARN and share > > knowledge. Perhaps it's not the best solution for me right now but > > without trying it I won't know when or how to apply it as a solution. > > > By the way, my project has about 50 files (modules) in it with a lot > > of shared code that could be used across other projects... seems as > > good a reason as any to try packages out ;-) > > I don't agree. My answer can be wrong for your situation, but I can't > know much about you from the start, and for most people my answer was > the right one. > > When a student asks me how to improve his/her usage of metaclasses I > usually answer that metaclasses aren't required to solve that small > problem. > > Generally in engineering the simplest solution is the one you have to > try first (and often second and third), and only later, if practical > experience shows the simple solution doesn't work, you try a more > complex solution. > > So I have suggested you a simple solution by "default". If later you > see that you have many modules and you really need packages, then it's > easy to ignore my first answer. > > Bye, > bearophile -- http://mail.python.org/mailman/listinfo/python-list
