Looks like somebody jumped the gun when they saw the commits and uploads happening; the official release announcement went up only a few minutes ago, and is here:
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.
Seems like a new release should be done? Isn't that what RC and pre releases are for?
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.
Well, what we do is generate everything, then share it privately and quickly amongst the core team for final review before flipping switches and making things public. One actually important part of this is verifying things like "the package I download from what will become the public release URL has checksums that match what's in the checksum file", so it does have to actually go up on our server for that.
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.
That "somebody" would be me then. Sorry for any inconvenience this may have caused. I saw "Latest Release: 1.6" on the djangoproject.com home page, checked if it was on PyPI already (it was), did a "pip install Django" and got 1.6. These together to me seemed to be a pretty good sign that 1.6 was released.
Will wait for the official release announcement next time. Sorry again.
Next time around we'll probably do more to hide things up until the announcement (though of course we can't hide the commits on github, and the download URLs are predictable, so someone who sees the commits will be able to figure out where the release is going to live).
Perhaps the better thing to do for this would be that no changes are made between the last release candidate and the final release. Some projects do it, some don't.
Mistakes can be made if you have to do version number tweaks in various places before releasing.
Django is one of my favorite open-source projects. I owe the project a lot.
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.
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 Engine.
Do you use Python/Django in a professional setting now? If so, how did you find the full-time conversion?
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)
> Nit-pick: suspect you are actually a fan of statically-typed languages.
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.
And here we can see the issues and clusterfucks of the completely undefined and arbitrary "concept" of "weak" (conv. strong) typing: java's behavior here is well-defined, simple and statically typed, there's no more type loss than when doing `5 + 1.0` in Ruby or Python.
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"
so "strongly typed" it has a protocol for implicit string conversion.
But wait, there's more without even bothering with overrides:
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 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.
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.
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.
I had a somewhat similar experience. I was using PHP for many, many years and after hearing all the fuzz about Ruby/Rails I tried to learned it but it didn't really click with me. However, when I tried Python/Django I was immediately hooked. The main deciding factors were Django admin site and the (cleaner than Ruby) Python syntax.
Circus looks huge and doesn't appeal for one or two apps. I do however wish to experiment with circus at some point. Do you have any comparison to make, assuming you have used both? Or anyone out there? Thanks
I think the MySQL one might be quite a big one for many people. I know Postgress is better (South tells me every time the migration doesn´t work) but for converting older projects it definitely going to be useful.
For what I can see, Invoke is just a revamped version of Fabric’s task running components.
Fabric 2.0 will "leverage Invoke for task running, leaving Fabric itself much more library oriented".
I am aware of that, but I still consider it one of my favorite libraries, and thought it would be useful to mention that it's not yet py3k-ready. I can imagine quite a few people might depend on it. What are you using instead?
The standard MySQL driver wasn´t working the other day when I tried. That might be quite a big one for some people. I saw you could apply a patch, but I didn´t get round to trying yet.
Alpha release of Oracle MySQL Connector/Python http://dev.mysql.com/downloads/connector/python/ actually works with Django 1.5+ and Python3. But you will be on the bleeding edge if you put it in production.
The dedication to Malcolm Tredinnick was a very nice thing for the Django team to do. I didn't know of Malcolm or his passing before reading the release notes, but he seemed like a wonderful person who will be missed by many. Very sad that somebody like that is no longer with us. Reading his tweets I get the sense he was a really cool guy.
One of the reasons I like Django so much is because of the community. This might seem rather meta but the comments in this thread are generally positive. Most Django users I know are well aware of its limitations and don't try to sugarcoat it if Django is not the right tool for the job. But overall I've found the community (and that of Python) pretty receptive.
The persistent connections that now exist within Django should give a quite but great performance boost for the vast majority of Django applications, which are not already running a connection pooler (http://www.craigkerstiens.com/2013/03/07/Fixing-django-db-co...). This alone can be reason enough to upgrade in addition to all the other improvements.
I would recommend using 1.6 and South for now. 1.7 is at least nine months away, and who knows where the API will go in that time. You're probably better off developing a stable version of your project using 1.6/South, and then refactoring when 1.7 lands.
No: 1.7 is not stable and it's not like the current migration situation with South is a particularly large pain-point.
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.
1.7 It is not hard to keep up with changes. And it is easier to do them incrementally than have big jump which you never find time to do and end up lagging versions and huge technical debt.
Once your project is deployed then think about sticking with specific version. Development should be on the bleeding edge!
For those who works with designers or html people who don't use the command line, how do you collaborate with them with Django?
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..
- 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 don't use django, but one of the easiest ways to get designers and non technical folks working directly on projects is to run virtual machines with vagrant[0] and automate everything as much as possible.
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.
well, it's mainly geared towards PHP but you might find https://puphpet.com/ useful to get a reasonably sane vagrant/puppet installation which you can then customize for django or whatever. You could just remove the php specific stuff from the generated configurations if you don't want it
I also have this same problem. It's one of the things which has made me think about switching to web2py - you can edit templates and css, and do commits directly in the admin. There is something a bit crazy about it though.
Alternatively I don't think it would be that difficult to put a decent JavaScript-based editor on a page and allow editing of certain files, combined with a way of running the collectstatic management command.
Difficult enough for me to not have tried it though.
What command line stuff would they need to do? I've built a couple reasonably complex projects using Django, and I don't remember spending much time at all on the command line.
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.
Working with frontend designers/developers in a few different languages (PHP/Python), the easiest way for our office was to just use a central development server in the office then use NFS.
Sourcetree is a little slow for them (they use Macs), but they seem to get the idea.
We put together a vagrant script and a set of instructions specifically for front-end devs on Windows who might lack the bash-fu and Python skills needed to get a local setup.
I was always opening an object link in a new tab and then going back and hitting refresh in the main tab with the admin listing. Guess I won't have to do that anymore.
1.7 release will be very interesting. Instead of South there will be migrations support. At DjangoCon EU Andrew Godwin told about his vision of it. i.e. if you have 200 migrations you'll be able to merge them into 1.
Form fields will get extended support like input[type="email"]
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_launch to True
Missile.objects.create(target="Merica")
Then you have a view:
/missile/launch_missiles
with the code:
for missile in Missile.objects.filter(should_launch=True):
missile.launch()
You'll have the unexpected behavior of launching that missile you just added.
With the new behavior your missile wouldn't be launched until you told it to. Basically this update has everything to do with the missile above failing this conditional:
missile.should_launch is True
Since 'None is not True and None is not False', it is a sensible default for Booleans.
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.
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.
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), 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.
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 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:
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.
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.
The person who posted this apparently saw the version-bump commits and jumped the gun, posting a link to just our download page before we even had the release announcement out.
The announcement and release notes both have the information you want:
are there any particular performance improvements over the previous versions ?
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.
It's hard to imagine using an ORM for anything high volume that just got around to adding (still very limited) connection pooling. I'd tend to think anyone overly concerned with performance would use SQLAlchemy, if they use any ORM at all.
right tool for the job. Djangoś ORM is great for simple stuff. And it works with the admin interface (which is worth a lot). If You need something complex enough, use raw SQL.
The admin was too much to give up to swap the ORM to SQLAlchemy for me.
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.