Live data from Hacker News

Django 1.6 released

djangoproject.com

101–107 of 107 posts

Re: Django 1.6 released

#101
post #42

Earlier quoted context omitted.

I'm quite interested in your experiences with Django, as I'm somewhat in the same boat. I'm a .NET developer, and while I love C#, am a fan of strongly-typed languages, and am quite fond of the .NET framework I have a soft spot for Python and especially Django. Similarly, I had a few days and decided to go out of my comfort zone. A few days later I had written a blog script and had modified it to work with Google App…

You're in the exact same spot I was. C# developer, completely enthralled with strongly-typed languages and OO development. I definitely use Python professionally (and some Django, but that's not the critical stuff.) It's not the only thing I do, but it's another arrow in my quiver. It's really useful for generating applications that need to do a lot of stuff, but benefit from brevity in code. Django is actually more…

One of my big reasons for wanting to pick up Python was to get me out of developing on Windows. As much as people love to tout Mono, it's simply not desirable for any .NET shop.

My biggest worry was if I was offered a job at a great company, how I would be able to adapt not to the language, but going from an entirely different platform, one that I hadn't used in anger since uni. Learning a language shouldn't be a problem, but as I've found out, most of my issues aren't in using the language itself, but adjusting to the Unix workflow.

Also, my big worry is being the "Windows guy" at an office. I doubt I'm the first C# developer to be laughed at because I develop on Windows, even if it's by (in my opinion) fairly crappy developers. Deep down, I reckon a lot of devs look down on people that have the audacity to call themselves developers when they don't build on Linux.

So, I guess my next two questions are:

1. Did you notice a decrease in "professional level" when you moved from C# to Python. I'm a mid-weight developer, probably not too far off from being a senior developer. With very limited Python experience I doubt I'd be able to just jump over to being a mid-level developer, and to be honest I wouldn't want to drop in salary by too much just so I can use a different language.

2. How easy was it to land a job writing Python if you've not come with "previous professional experience"? I've written a bit of Python, simply to script some things on a Windows server. I've got my own scripts, but nothing in an actual job. I reckon I could pick it up (Python/Django), along with a good dev workflow in Linux, within a few months, but I can see employers being skeptical to hire a C# dev if another Python dev wants the job.

Re: Django 1.6 released

#102
post #9

Earlier quoted context omitted.

Thirded! This is a better implementation for a framework. CBGV as-is would be better as an add-on app. This is a great example why framework projects could benefit from being a bit more democratic. Most people seem to be pulling their hair out, telling you something is too complicated to effectively use. The response: It's worth it once you learn. The complexity cost is worth it. Trust us. Read the docs (of course),…

I use the class-based generic views in a couple of projects. My personal opinion is that the official documentation still needs work, because people end up in the API reference tree looking for the examples and explanations. And that is not a happy place to end up when you're just starting out with them, since in there you're seeing the whole inheritance/mixin layout structure, which is what leads to the belief that…

Worth noting that it's an explicit aim of vanilla views to exactly replicate the functionality of Django's GCBVs.

For the docs: "If you believe you've found some behaviour in Django's generic class-based views that can't also be trivially achieved in django-vanilla-views, then please open a ticket, and we'll treat it as a bug."

You shouldn't be losing any flexibility by using it instead of using Django's existing GCBV implementation.

Re: Django 1.6 released

#105
post #57

Earlier quoted context omitted.

> Boolean can't have default. I don't see the problem.

Warning: default was False previously so this example is backwards Think about this code: class Missile(models.Model): # we can only attack short countries target = models.CharField(max_length=7) should_launch = models.BooleanField() def launch(self): """ pass launches the missile """ pass You recently added a new missile: # add new missile in case we have to attack Merica # it won't be launched until we set should_l…

Two problems here:

One not only is the example backwards, but given the previous behavior, the correct thing would have occurred. This is a complete nitpick but whatever.

More importantly, this shows a lack of understanding about the framework being used, not an issue with the framework. The example has a programmer basically assuming the default is False when it was True, or more correctly that the default was not True. That is an issue with the programmer (and testing) not with the framework, unless it was undocumented. Django is documented quite well. The programmer here assumed something worked one way that was clearly documented to work the other.

Booleans defaulting to False is not unusual, but not universal either. Django has chosen to go the path of explicitness, which is a fine choice to make, as opposed to defaulting to False which is often considered to be a safe choice. I don't see a problem with not assigning a default, but I also don't see a problem with the default being False.

Defaulting to NULL could cause other problems, at least for the programmer above who didn't read documentation and worked on assumption.

Re: Django 1.6 released

#106

Earlier quoted context omitted.

You're in the exact same spot I was. C# developer, completely enthralled with strongly-typed languages and OO development. I definitely use Python professionally (and some Django, but that's not the critical stuff.) It's not the only thing I do, but it's another arrow in my quiver. It's really useful for generating applications that need to do a lot of stuff, but benefit from brevity in code. Django is actually more…

One of my big reasons for wanting to pick up Python was to get me out of developing on Windows. As much as people love to tout Mono, it's simply not desirable for any .NET shop. My biggest worry was if I was offered a job at a great company, how I would be able to adapt not to the language, but going from an entirely different platform, one that I hadn't used in anger since uni. Learning a language shouldn't be a pro…

Actually, I find a lot of developers who don't care for Windows who very much like C#.

To your questions:

1) Professional level decrease? Not hardly. If anything, I found strong professionalism in Python. "Pythonistas" are huge in principles such as DRY, which isn't about something terribly complex but rather keeping things simple and clean. It's about being organizationally effective and not coding one's self into a corner. The fact that the language seems so easy to work with shouldn't give the impression of it being simplistic.

2) I didn't land a job writing Python, it's just a tool to get things done. From a career standpoint, I don't want to be known as a {language/platform/thing} guy, I simply want to be known as an engineer. Tools, languages, platforms, services, etc. will come and go. As long as I recognize how to use those in combination to get things done efficiently, I'm doing my job.

Re: Django 1.6 released

#107

Earlier quoted context omitted.

Warning: default was False previously so this example is backwards Think about this code: class Missile(models.Model): # we can only attack short countries target = models.CharField(max_length=7) should_launch = models.BooleanField() def launch(self): """ pass launches the missile """ pass You recently added a new missile: # add new missile in case we have to attack Merica # it won't be launched until we set should_l…

Two problems here: One not only is the example backwards, but given the previous behavior, the correct thing would have occurred. This is a complete nitpick but whatever. More importantly, this shows a lack of understanding about the framework being used, not an issue with the framework. The example has a programmer basically assuming the default is False when it was True, or more correctly that the default was not T…

Things should make sense without reading documentation (I'm not saying that you don't need to read it) and boolean having a default doesn't make any sense. Argument about it having a default value in other frameworks isn't a real argument either.
Post reply on HN