Why does Django make Python look ugly?
I took up the Python programming language because of its design philosophies, its great community and most importantly for me its beautiful syntax. However, recently I've been a left a little disheartend. In my attempts to customise Django I've come across code that I think syntactically could be cleaner. I'm by no means a seasoned Python programmer, in-fact I've only been using it properly for the past few months. I'd appreciate your insights and your views. 

Here are some examples of code I have come across:

Why is there a need for the slash?

    from django.contrib.admin.util import get_model_from_relation, \
        reverse_field_path, get_limit_choices_to_from_path

Could this be written more elegantly?

        rel_name = other_model._meta.pk.name
        self.lookup_kwarg = '%s__%s__exact' % (self.field_path, rel_name)
        self.lookup_kwarg_isnull = '%s__isnull' % (self.field_path)
        self.lookup_val = request.GET.get(self.lookup_kwarg, None)
        self.lookup_val_isnull = request.GET.get(
                                      self.lookup_kwarg_isnull, None)
        self.lookup_choices = f.get_choices(include_blank=False)

One thing I don't understand is why the code after the method for each and statement is on seperate lines?

    def has_output(self):
        if isinstance(self.field, models.related.RelatedObject) \
           and self.field.field.null or hasattr(self.field, 'rel') \
           and self.field.null:
            extra = 1
        else:
            extra = 0
        return len(self.lookup_choices) + extra > 1

This just looks messy!

    def choices(self, cl):
        from django.contrib.admin.views.main import EMPTY_CHANGELIST_VALUE
        yield {'selected': self.lookup_val is None
                           and not self.lookup_val_isnull,
               'query_string': cl.get_query_string(
                               {},
                               [self.lookup_kwarg, self.lookup_kwarg_isnull]),
               'display': _('All')}
        for pk_val, val in self.lookup_choices:
            yield {'selected': self.lookup_val == smart_unicode(pk_val),
                   'query_string': cl.get_query_string(
                                   {self.lookup_kwarg: pk_val},
                                   [self.lookup_kwarg_isnull]),
                   'display': val}
        if isinstance(self.field, models.related.RelatedObject) \
           and self.field.field.null or hasattr(self.field, 'rel') \
           and self.field.null:
            yield {'selected': bool(self.lookup_val_isnull),
                   'query_string': cl.get_query_string(
                                   {self.lookup_kwarg_isnull: 'True'},
                                   [self.lookup_kwarg]),
                   'display': EMPTY_CHANGELIST_VALUE}

Please don't get me wrong, I'm not doing a disservice to the many contributors of Django, on the contrary I really admire them and I'm grateful. I appreciate that maybe it's my lack of experience with Python itself or that bits of code that make the syntax look unclean are in-fact core features of the Python programming language.
Why does Django make Python look ugly?
===

I took up the Python programming language because of its design philosophies, its great community and most importantly for me its beautiful syntax. However, recently I've been a left a little disheartend. In my attempts to customise Django I've come across code that I think syntactically could be cleaner. I'm by no means a seasoned Python programmer, in-fact I've only been using it properly for the past few months. I'd appreciate your insights and your views. 

Here are some examples of code I have come across:

Why is there a need for the slash?

    from django.contrib.admin.util import get_model_from_relation, \
        reverse_field_path, get_limit_choices_to_from_path

Could this be written more elegantly?

        rel_name = other_model._meta.pk.name
        self.lookup_kwarg = '%s__%s__exact' % (self.field_path, rel_name)
        self.lookup_kwarg_isnull = '%s__isnull' % (self.field_path)
        self.lookup_val = request.GET.get(self.lookup_kwarg, None)
        self.lookup_val_isnull = request.GET.get(
                                      self.lookup_kwarg_isnull, None)
        self.lookup_choices = f.get_choices(include_blank=False)

One thing I don't understand is why the code after the method for each and statement is on seperate lines?

    def has_output(self):
        if isinstance(self.field, models.related.RelatedObject) \
           and self.field.field.null or hasattr(self.field, 'rel') \
           and self.field.null:
            extra = 1
        else:
            extra = 0
        return len(self.lookup_choices) + extra > 1

This just looks messy!

    def choices(self, cl):
        from django.contrib.admin.views.main import EMPTY_CHANGELIST_VALUE
        yield {'selected': self.lookup_val is None
                           and not self.lookup_val_isnull,
               'query_string': cl.get_query_string(
                               {},
                               [self.lookup_kwarg, self.lookup_kwarg_isnull]),
               'display': _('All')}
        for pk_val, val in self.lookup_choices:
            yield {'selected': self.lookup_val == smart_unicode(pk_val),
                   'query_string': cl.get_query_string(
                                   {self.lookup_kwarg: pk_val},
                                   [self.lookup_kwarg_isnull]),
                   'display': val}
        if isinstance(self.field, models.related.RelatedObject) \
           and self.field.field.null or hasattr(self.field, 'rel') \
           and self.field.null:
            yield {'selected': bool(self.lookup_val_isnull),
                   'query_string': cl.get_query_string(
                                   {self.lookup_kwarg_isnull: 'True'},
                                   [self.lookup_kwarg]),
                   'display': EMPTY_CHANGELIST_VALUE}

Please don't get me wrong, I'm not doing a disservice to the many contributors of Django, on the contrary I really admire them and I'm grateful. I appreciate that maybe it's my lack of experience with Python itself or that bits of code that make the syntax look unclean are in-fact core features of the Python programming language.