Django 1.6 released
djangoproject.com
djangoproject.com
Years ago, when I was a Microsoft-only shill (yeah, I'll say it), I knew how to build almost anything as long as something from Microsoft was under the covers. I was proud of my abilities, and in spite of the anti-MS crowd, I stood up for my platform and was a good developer.
In 2006, I had a short two-week break from my startup job, and my wife & kids were traveling to their grandparents' house at the same time. I had 336 consecutive hours to spend as I wanted, something I hadn't been able to do in many years. I decided I wanted to work on a little side project, something I could complete within those two weeks.
I made a decision to break out of my comfort zone. I knew a little about Linux, nothing about Apache, zero about Python, and had never worked with Mysql. I came up with an idea for a simple little CRUD application, just a utility site. It was something I knew I could build in maybe two or three days using Microsoft tools.
So, I searched around and found Django. I downloaded v0.9x (it was sometime in the summer, can't recall what it was specifically. I know it was pre-v1.)
And I started from the beginning, purely a newb. It was a position I wasn't accustomed to, so I immediately felt a lack of boundaries and sense of control. But the Django documentation was really good, and I soon gained an understanding of everything I needed to learn -- Python, running Apache, configuring Django, wiring up Mysql. I stayed focused and in one week, I had written my ridiculously simple CRUD app.
But the value I got out of it was how well the project pulled me in to becoming productive on a platform that I'd never used. Not only that, there was the help in the discussion groups from the community. It was a lot of fun, and I could recognize myself becoming a better developer.
The biggest realization came when I compared my Django project to an equivalent built on Microsoft tools. It wasn't a comparison of one-week vs. two-days, but rather one-week coming from square 1. All this led me to rethink my thoughts around my Microsoft background. I didn't become a convert per se, but it made me realize there are so many other ways of solving problems and other systems on which to build applications. And, after feeling productive, it made it easier for me to explore other (non-Microsoft) technologies. The feeling of being productive in multiple environments was so empowering.
I'm not sentimental about software, but the Django project is kind of that kid who can do no wrong in my eyes, due to my formative experience with it.
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 Engine.
Do you use Python/Django in a professional setting now? If so, how did you find the full-time conversion?
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 responsible for me learning Python and how to use it responsibly in a production environment. I knew how to write services in C# and Java that wouldn't be an administrative nightmare or cause pagers to go off at odd hours, so I needed to learn that with Python (turns out, it's not hard.)
As always, your mileage may vary. Nonetheless, lean toward finding a use for it in your operation, if only for experience. It's super practical, and to minimize transitional familiarity, go with IronPython. Works with all the VS IDEs.
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.
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.
Nit-pick: suspect you are actually a fan of statically-typed languages. Python is a strongly-typed language, but not statically-typed.
(general easy way to tell them apart: in a statically-typed language, both the name and the value bound to it have a type, and those types must match; in a dynamically-typed language only the value has a type; in a weakly-typed language, operations on incompatible types are permitted, and they may be coerced for compatibility; in a strongly-typed language, operations on incompatible types are an error -- usually at compile-time or equivalent for statically-typed, usually run-time for dynamically-typed)
And probably closer to "statically-but-not-too-statically-typed-because-really-more-than-my-language-of-choice-is-too-much" languages. Self-avowed fans of "statically-typed languages" (usually java or C#) rarely consider giving up nulls and casts.
Java:
System.out.println("abc" + 5); -> "abc5"
Python:
print "abc" + 5 -> TypeError: cannot concatenate 'str' and 'int' objects
Ruby:
puts "abc" + 5 -> TypeError: can't convert Fixnum into String
Why do you find implicitly converting an int (/Fixnum) to a float (/Float) more palatable, when they have completely different internal representations, domains of definition, precisions, operational semantics and potential pitfalls?
And what about Python's `"foo" * 3`? Hell, what about this:
> class Fixnum
> def to_str
> self.to_s
> end
> end
=> nil
> "5" + 3
=> "53"
But wait, there's more without even bothering with overrides:
> a = [1, 2, 3]
=> [1, 2, 3]
> a[1.4]
=> 2
Django admin site is still my favourite feature.
https://www.djangoproject.com/weblog/2013/nov/06/django-16-r...
The release notes are here:
https://docs.djangoproject.com/en/1.6/releases/1.6/
Also: if you downloaded the package in the period between the parent link going up, and now, you might want to grab it again. The first roll of the 1.6 package (which wasn't announced, so we could do final checks first) failed to update our trove classifier, so the package was regenerated, which changed its signature and checksums.
Was the release uploaded to pypi or a download page? If so, that's released IMHO. eg, debian, various news outlets, and others auto scan download pages for new releases.
And if we catch a minor packaging error at this point, it's easy enough to fix on the spot without having to do an entire new release.
Except in this case somebody got really eager, saw the release process starting, and posted a link to our downloads page (and I'm not entirely certain if it would have been possible to get the incorrect package from it), rather than waiting for and linking to the release announcement once we'd vetted and made everything public.
Will wait for the official release announcement next time. Sorry again.
Mistakes can be made if you have to do version number tweaks in various places before releasing.
Personally, I'm happy that Python 3 is now officially supported, though in practice I haven't had an issues with using Django 1.5 with Python 3.
From personal experience, most of the critical ones are compatible.
Of course I'm partial to my new pave project: https://bitbucket.org/mixmastamyk/pave It is based on fabric, and uses a yaml file to automate it.
Still in progress, but there you go.
There's always the option of just using Upstart or systemd as well.
Really nice piece about Malcolm from his former boss: https://plus.google.com/+errazudinishak/posts/6j6iAMhNfnb
Congrats to the Django team on releasing 1.6, I'm looking forward to upgrading soon!
For me it's a perpetual issue to get them up and running, commit/push with git, etc etc. Is there an easier solution? Basically, I'd like them to get started and be able to tweak the templates and css as effortless as possible.
It's kind of very hard to have people working directly in templates/css and others updating html/css and them diff the changes, integrate them, etc..
Doing the first 2 lessons will not only get your a vagrant powered VM up and running, it will also give you a good feel for normal use. And you'll also be learning Django.
Happy to share if you ping me.
For Django, all you need is a portable Python installation, and a start script for starting the development server, isn't it?
- Use Vagrant and some bootstrap scripts (or Docker) to make giving them a dev environment easy
- Get them to use a git GUI like SourceTree (free & good: http://www.sourcetreeapp.com/)
- Build a workflow around pull requests / review branches a la github/bitbucket/gerrit so you can have them submit changes but an engineer reviews/verifies before it's merged.
In general, empowering them to do this is an investment in the future and well worth it.
I think I had a one line batch file to start the server, but that's it. Subversion integrates directly into the filesystem with tortoisesvn and even Git has good tools these days.
I can't imagine a designer needing to touch the command line at all.
Sourcetree is a little slow for them (they use Macs), but they seem to get the idea.
What I'd do is use South now and essentially rebase when you upgrade to 1.7 – ensure that your servers are current with South, remove it and start over with 1.7's built-in migrations.
Once your project is deployed then think about sticking with specific version. Development should be on the bleeding edge!
Form fields will get extended support like input[type="email"]
Django comments are now deprecated.
Congratulations to everyone using Django!
https://docs.djangoproject.com/en/dev/releases/1.6/#improved...
> BooleanField no longer defaults to False
It caused quite a few headaches. Boolean can't have default.
I don't see the problem.
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
Then you have a view:
/missile/launch_missiles
for missile in Missile.objects.filter(should_launch=True):
missile.launch()
missile.should_launch is True
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.
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), use this 3rd party site (ok...), read the code. (so I can write a non-trivial view!?). If you are still giving that answer years later, you have to be open to the fact that that your users might be on to something.
Often when you hear someone say they're using CBGV on a large project, you can almost sense the pause for applause.
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 it's too complicated to use.
Which... no, class-based generics are pretty darned easy. Here are the views for my blog app, for example:
https://github.com/ubernostrum/blog/blob/master/blog/views.p...
It'd be nice to cut down the use of super(), but that's about the only issue I have with it. All of the simpler-CBV implementations I've seen make a few too many assumptions for my personal taste, or otherwise cut down on flexibility in favor of simplifying the inheritance diagram, which I don't agree with as a goal in itself.
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.
The announcement and release notes both have the information you want:
https://www.djangoproject.com/weblog/2013/nov/06/django-16-r...
I was thinking basically of transaction management, especially the autocommit behavior.
I browsed through the docs and saw that the default python database API requires autocommit to be turned off... but then again django overrides this behavior.
any comments on this ? (or am I completely lost ?)...
> Django’s transaction management was overhauled. Database-level autocommit is now turned on by default. This makes transaction handling more explicit and should improve performance. The existing APIs were deprecated, and new APIs were introduced, as described in the transaction management docs.
> Please review carefully the list of known backwards-incompatibilities to determine if you need to make changes in your code.
> Persistent database connections¶
> Django now supports reusing the same database connection for several requests. This avoids the overhead of re-establishing a connection at the beginning of each request. For backwards compatibility, this feature is disabled by default. See Persistent connections for details.
Or they did connection pooling outside the development framework.
The admin was too much to give up to swap the ORM to SQLAlchemy for me.