t+1 - Latest Comments

Re: Python’s hash lookup is insanely good

CSMajor — Wed, 01 Jul 2009 21:54:40 -0000

And hash tables and programming in general lol

Re: Don’t negotiate on your estimates

cockcage — Sun, 28 Jun 2009 10:16:54 -0000

Eye opening post. We must all break free from the barriers of pessimism and try to think broader and understand other people instead of looking down on them.

Re: How to write a resume for an internship

mw44118 — Sat, 27 Jun 2009 13:40:47 -0000

Thanks Niels! I'll do that and see what happens.

Re: How to write a resume for an internship

Niels — Fri, 26 Jun 2009 14:00:36 -0000

Very solid post. Submit it to digg/reddit etc ...

Re: Which code layout do you like more?

Brandon Corfman — Thu, 25 Jun 2009 10:03:25 -0000

Shouldn't the function name be "price" instead? Why introduce a variable just for naming when the function name serves that purpose?

Re: Which code layout do you like more?

freestylemedela — Thu, 25 Jun 2009 09:54:34 -0000

Second one would be great for me! I liked both of these btw!

Re: Define your validation schema inline

chiro12 — Thu, 25 Jun 2009 08:07:55 -0000

Declarative style is more appropriate and much easy to understand. Thank you for giving us some insights about schema.

Re: Ditz versus bugs everywhere

ging05 — Thu, 25 Jun 2009 07:33:03 -0000

quiet good.. I think the Python docs have more explanatory text in just the table of contents.. :)

Re: A few examples of how to use :g in vim

chocolover — Sun, 21 Jun 2009 16:37:01 -0000

Thanks for posting this one. It really helped me a lot.

Re: My new ticket tracking system is now vaporware!

zoooom — Sun, 21 Jun 2009 11:34:15 -0000

SVG charts are great for this! Can't wait to see the finished product!

Re: Is this pylint error message valid or bogus?

Dave Kirby — Sat, 20 Jun 2009 09:37:38 -0000

I agree with the commenters on clp - as a user of the function looking at the signature, I would expect that initial_time needed to be a string.

If you wanted to use something more explicit than None, then you could use a placeholder object, e.g.

TODAY = object()
def midnight_next_day(initial_time=TODAY):
if initial_time is TODAY:
...

however pylint still complains that instance of object does not have a date method.

Re: Which code layout do you like more?

Michael — Fri, 19 Jun 2009 22:17:14 -0000

With multiple return points I find myself spelling out implicit else statement:

def(a,b):
__if b:
____return h(g(a))
__else:
____return g(a)

Re: Is this pylint error message valid or bogus?

Ben Finney — Fri, 19 Jun 2009 19:19:24 -0000

> The vast majority of pythoners use None, but I prefer descriptive strings for default values

If you do that, you're communicating badly.

Python's default arguments mean something very specific, and readers will expect it: “this argument can be omitted, and if so, *this value will be used instead*”. By putting a value there that you never intend on using, you subvert that communication.

Please, if you don't have a good static value to use, just stick with the conventional sentinel value: None.

If you need None for some other purpose (e.g. you need to tell the difference between the default and a user-supplied None), use a clearly-for-no-other-purpose object, such as a module-local name bound to a unique object() instance.

Re: Which code layout do you like more?

seenxu — Fri, 19 Jun 2009 18:08:03 -0000

I'd prefer the first one, easy to read, easy to understand.

Re: Is this pylint error message valid or bogus?

D'gou — Fri, 19 Jun 2009 16:45:04 -0000

Nicely refactored.
"Gordian knot? What gordian knot? Just a bunch of pieces of rope on the floor here." :)

Re: Is this pylint error message valid or bogus?

Gary Bernhardt — Fri, 19 Jun 2009 15:45:16 -0000

I'd turn it into two functions: midnight_tomorrow() and midnight_after(initial_date). Default arguments tell you that you're probably violating the SRP. (Or maybe they're *always* violations; I haven't thought enough about it yet.) Here's a version with two functions:

def midnight_tomorrow():
....return midnight_after(datetime.now())

def midnight_after(initial_time):
....return initial_time.date() + timedelta(days=1)

There are no conditionals needed, it's two eloc instead of three, and there's less thinking required by the guy who calls these functions. The caller doesn't need the docstring suggested above by Alex or the descriptive default value you used; the functions' names are fully self-descriptive.

Re: Is this pylint error message valid or bogus?

nes — Fri, 19 Jun 2009 15:25:18 -0000

code does not come out that nice on the comment. Let's try this instead:

http://pastebin.com/m19049702

Re: Is this pylint error message valid or bogus?

nes — Fri, 19 Jun 2009 15:20:42 -0000

pylint thinks initial_time might be a string sometimes.

>>> def midnight_next_day(initial_time="use today's date"):

if initial_time == "use today's date":
initial_time = datetime.now()

return initial_time.date() + timedelta(days=1)

>>> midnight_next_day()

Traceback (most recent call last):
File "<pyshell#24>", line 1, in <module>
midnight_next_day()
File "<pyshell#23>", line 6, in midnight_next_day
return initial_time.date() + timedelta(days=1)
AttributeError: 'str' object has no attribute 'date'
>>>

Re: Is this pylint error message valid or bogus?

Alex — Fri, 19 Jun 2009 14:16:50 -0000

Sorry, but that's so nasty. Just use None and provide the description as a comment or in the docstring, please. None exists for a reason.

Re: Is this pylint error message valid or bogus?

Anonymous — Fri, 19 Jun 2009 14:16:13 -0000

there is no need for an if statement:

initial_time = intial_time or datatime.now()

the original version is bad because it suggests that your functions is taking string parameters, where in fact it takes datetime objects. Misleading.

Re: Which code layout do you like more?

rgz — Fri, 19 Jun 2009 13:08:07 -0000

I on the other hand love multiple return statements in loops and --while using php-- switches. I actually find that situation a lot using switches.

In some switches I don't use break at all since all my cases end with return. Some times however I have to do additional work before getting out of the function, then it's temp variable time again.

Re: Which code layout do you like more?

Titus Brown — Fri, 19 Jun 2009 12:54:47 -0000

For me, it depends on the rest of the code in the function. Multiple obvious return statements aren't "bad":

def f(...):
if param is bad:
return None

... do stuff ...
return answer

but I don't like having returns sprinkled throughout the code, and especially not in loops, where it can complicate the logic of the execution flow.

Re: Which code layout do you like more?

elzapp — Fri, 19 Jun 2009 07:04:54 -0000

the indentation disappeared. Using _ as space:
def(a,b):
__if b:
____return h(g(a))
__return g(a)

Re: Which code layout do you like more?

elzapp — Fri, 19 Jun 2009 07:03:52 -0000

How about
def(a,b):
if b:
return h(g(a))
return g(a)

Re: Which code layout do you like more?

Charles — Fri, 19 Jun 2009 07:01:23 -0000

I first learnt to program in the early 1990s using books, and thus methodologies, that were already old and discarded by their previous owners. All I really remember was the love of flowcharts and subtle re-enforcement of the idea that multiple return statements made code so hard to read that anyone else who saw it would meet an untimely end.

I think modern teaching styles have moved towards a more understanding based approach that credits the student with a little intelligence. Consider the following fragments of introductory programming:

* All functions must return a value
* No code after a return is executed
* a function can only return one value

Nice nuggets of information that can be memorised by rote. So very early on one gets into the habit of putting the return at the end of a function because it has to be there and thinking nothing more of it. It took a long time for me to unlearn that habit.