Saving files to s3 with python 3.3

[Andreas Kuhne]

Hi all,

We are trying to rewrite our webplattform because it has been developed
since 2009 and is more or less a patchwork of fixes.

In doing so, we want to be able to use the latest versions of all plugins
and frameworks, so we are looking at:
Django 1.6 (or 1.7 if it is released before September this year)
Python 3.4

The problem we have been seeing is that some required plugins are not
python 3 compatible, however, we have been able to patch them so far.

Now however I am facing a bigger problem. We are running our website on the
AWS plattform, so for storage we have S3. Previously we have been using
django-storages and boto so save files to S3.

I have changed to django-storages-py3 and the py3kport branch of boto. I
can download files from s3 and I can load files into BytesIO objects.
However I am not able to save a thumbnail image version of an image.

When I use pillow to save the image like this:
file = storage.open(output_fname, "wb")
image.save(file, "png")
file.close()

I get an exception in the image.save(file, "png") part.
  File
"/home/anku/.virtualenvs/env/lib/python3.3/site-packages/PIL/Image.py",
line 1564, in save
save_handler(self, fp, filename)
  File
"/home/anku/.virtualenvs/env/lib/python3.3/site-packages/PIL/PngImagePlugin.py",
line 546, in _save
fp.write(_MAGIC)
  File
"/home/anku/.virtualenvs/env/lib/python3.3/site-packages/storages/backends/s3boto.py",
line 434, in write
return super(S3BotoStorageFile, self).write(*args, **kwargs)
TypeError: string argument expected, got 'bytes'


I understand WHY I get the error, but I can't figure out how to resolve it.
Anyone have any ideas?

Regards,

Andréas

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CALXYUbn5RZT0wiHULYx7TVBUXB9K1S5T18WwY_-%3Dz75OwH2rmQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

assertXMLEqual behaviour

[Jon Dunleavy]

Hi,

I am using django 1.6 but I can't find any information on the bugtracker as 
to whether this has changed but is this intentional behaviour of 
assertXMLEqual:

# this passes
self.assertXMLEqual(
"Value",
"""Value""",
)

# this fails
self.assertXMLEqual(
"Value",
"""
Value
""",
)

Thanks,


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b00120b0-56bd-4deb-8f49-08614b0afdcf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

django-mutant

[Eddilbert Macharia]

Hello Guys,

I'm trying to create dynamic models using django-mutant and im having alot 
problem understandingg what is really happening, i have tried the provided 
guide http://integricho.github.io/2013/07/22/mutant-introduction/ but i'm 
still confused, is there any one out there who understands on how to use 
this app.

The part of creating the actual table i understand but creating the 
columns/fields is really giving headache. please assist


Regards

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c4f781d0-9a5e-4acb-9fae-d344d9a26fb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Email encoding (DKIM, long lines, etc..)

[notsqrt]

Hi !

I am implementing DKIM validation for my emails.
I noticed than some emails do not pass DKIM validation due to different 
body hashes.
I followed the email flow, and found that postfix automatically truncates 
lines to 998 characters if they are too long (in accordance to 
https://tools.ietf.org/html/rfc2822#section-2.1.1).

Such emails can be generated by Sentry, by my own apps, etc..

Now about Django:
When using EmailMessage, the charset is utf-8, and 
the Content-Transfer-Encoding is either 7bit or 8bit (automatically changes 
between them when the body contains non-ASCII characters).
cf the ticket where the developers decided to switch from base64 to this 
behaviour : https://code.djangoproject.com/ticket/3472

Quick validation with:

>>> from django.core.mail import EmailMessage
> >>> print EmailMessage('subject', 'body', 'from...@example.net', 
> ['to@example.net']).message().as_string()
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 7bit
> Subject: subject
> From: from...@example.net
> To: to@example.net
> Date: Wed, 30 Apr 2014 11:01:44 -
> Message-ID: <20140430110144.1564.85693@localhost>
> body



So at the moment, because Django says not to use base64 for utf-8 emails in 
its code, Django does no longer make sure that the lines are not too long, 
despite the RFC.

I see 3 ways to make sure that the lines are not too long :

   - automatically split lines in a way that can be recognized by email 
   readers (no idea how to do that properly..) (in Django/in the apps)
   - go back to base64 (but it seems to increase spam scores)
   - switch to quoted-printable (functioning code below, no idea of the 
   potentially negative impact)

from django.core.mail.message import utf8_charsetfrom email import Charset
utf8_charset.body_encoding = Charset.QP

What do you think ?
Is Django code / app code the correct place to fix this ?
Should Django respect the RFC ?
Any other ideas ?

Thanks !

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c7e621c8-828e-4ba0-af8c-e12b21142acf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Email encoding (DKIM, long lines, etc..)

[notsqrt]

Quick addition : the ticket where it was approved to switch 
from quoted-printable to 7bit/8bit; but with the possibly unintended effect 
that lines were no longer short..

https://code.djangoproject.com/ticket/11212

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/3bf3b507-374f-4a4b-ab51-494966359c1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: assertXMLEqual behaviour

[James Bennett]

As far as I can tell from reading the source, there's no deliberate
intention one way or another.

However, from a strict/pedantic point of view, the example you give is
demonstrating correct behavior; due to whitespace, the second document
contains nodes not present in the first one.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAL13Cg8GJGK17kzHjzb85N9m1mkRhS17er8tDUO1hkeTeonj7g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Best practice - evolving from one to several sites using Django

[Ari Davidow]

Hi,

I am new to this group and new to Django. I have several websites that I 
want to drag into the current century. Initially I planned to do this with 
Drupal and know that it is relatively simple to add configuration 
information, modules, themes, for new sites using one Drupal installation.

What would be best practice for doing this in Django, knowing that I need 
to start off with the simplest site and then add additional domains as I 
have time and get more facile? My goal is to keep theming, most tables, 
etc., separate, but to have one django codebase to patch and to keep 
current.

Some areas of overlap: possible blog entries, a calendar of events, 
different views into a database of people involved in overlapping 
communities.

I see the terms "multisite" and "multi-tenant" used, but am not sure what 
each of these means in the context of django.

Many thanks,
Ari

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/370c1a46-030d-44cb-a65d-62b1beb86b15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Best practice - evolving from one to several sites using Django

[Avraham Serour]

if I'm not mistaken having a multi tentant django deploy means they will
share the same DB
I suggest having separate deployments for each site, as for sharing code
you should create an app which is the shared code and put in version
control and all your deployments would update from the same repository
the code could be the same but most of the time there should be many
different files, settings.py, templates, static files etc so putting all
the common code in a separate app would make sense at least to me

good luck


On Wed, Apr 30, 2014 at 4:07 PM, Ari Davidow  wrote:

> Hi,
>
> I am new to this group and new to Django. I have several websites that I
> want to drag into the current century. Initially I planned to do this with
> Drupal and know that it is relatively simple to add configuration
> information, modules, themes, for new sites using one Drupal installation.
>
> What would be best practice for doing this in Django, knowing that I need
> to start off with the simplest site and then add additional domains as I
> have time and get more facile? My goal is to keep theming, most tables,
> etc., separate, but to have one django codebase to patch and to keep
> current.
>
> Some areas of overlap: possible blog entries, a calendar of events,
> different views into a database of people involved in overlapping
> communities.
>
> I see the terms "multisite" and "multi-tenant" used, but am not sure what
> each of these means in the context of django.
>
> Many thanks,
> Ari
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/370c1a46-030d-44cb-a65d-62b1beb86b15%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tKPa49cBr%3DnhcMbhze7Mh23pRNgtm2JhuVU2K-MYZbjcA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: Best practice - evolving from one to several sites using Django

[Ilya Kazakevich]

Hello Ari,

First of all Drupal is PHP CMS, while Django is Python web-framework (and 
should be compared to PHP Zend or PHP Symfony then).

Django supports multiple sites: 
https://docs.djangoproject.com/en/1.7/ref/contrib/sites/

But Django uses one database and each table would have some kind of "site_id" 
field. It works pretty well.
And you can use different themes and different urls for each site.

Many apps already exist for Django, check here: http://djangopackages.com
You can take blogs app or calendar app and only customize it (writing your own 
HTML templates)

Install Django and try to move one site to it. Then, move next one. 

Ilya Kazakevich,
JetBrains PyCharm (Best Python/Django IDE)
http://www.jetbrains.com/pycharm/
"Develop with pleasure!"


>-Original Message-
>From: django-users@googlegroups.com
>[mailto:django-users@googlegroups.com] On Behalf Of Ari Davidow
>Sent: Wednesday, April 30, 2014 5:08 PM
>To: django-users@googlegroups.com
>Subject: Best practice - evolving from one to several sites using Django
>
>Hi,
>
>I am new to this group and new to Django. I have several websites that I want 
>to
>drag into the current century. Initially I planned to do this with Drupal and 
>know
>that it is relatively simple to add configuration information, modules, 
>themes, for
>new sites using one Drupal installation.
>
>What would be best practice for doing this in Django, knowing that I need to
>start off with the simplest site and then add additional domains as I have time
>and get more facile? My goal is to keep theming, most tables, etc., separate, 
>but
>to have one django codebase to patch and to keep current.
>
>Some areas of overlap: possible blog entries, a calendar of events, different 
>views
>into a database of people involved in overlapping communities.
>
>I see the terms "multisite" and "multi-tenant" used, but am not sure what each
>of these means in the context of django.
>
>Many thanks,
>Ari
>
>--
>You received this message because you are subscribed to the Google Groups
>"Django users" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to
>django-users+unsubscr...@googlegroups.com.
>To post to this group, send email to django-users@googlegroups.com.
>Visit this group at http://groups.google.com/group/django-users.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/django-users/370c1a46-030d-44cb-a65d-62
>b1beb86b15%40googlegroups.com
>2b1beb86b15%40googlegroups.com?utm_medium=email&utm_source=footer>
>.
>For more options, visit https://groups.google.com/d/optout.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/01b701cf6481%249d1f32a0%24d75d97e0%24%40JetBrains.com.
For more options, visit https://groups.google.com/d/optout.

The Django 1.7 tees!

[Sithembewena Lloyd Dube]

To Whom It May Concern,

I am devastated that I could not place an order for one of the new Django
1.7 tees. Now that I am ready to go, the campaign has ended on the merchant
website.

May I please place an order for one? I'd dearly like a memento of this
milestone release. Pretty please? Size=small :)

-- 
Regards,
Sithu Lloyd Dube

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAH-SnCB%2BVP%2BVpM3g4Uj4qP5sWfMv4%3DFvcuiNFvbYAErJknTnmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: django-mutant

[Simon Charette]

Hi Eddilbert,

I'm the author of django-mutant. May I ask you what exactly you're trying 
to achieve with this application?

Creating new field should be as simple as importing a field definition 
subclass from a contrib.* application.

e.g.

from mutant.contrib.text import CharFieldDefinition

CharFieldDefinition.objects.create(model_def=, 
name='mycharfield', max_length=100)

Simon

Le mercredi 30 avril 2014 04:12:27 UTC-4, Eddilbert Macharia a écrit :
>
> Hello Guys,
>
> I'm trying to create dynamic models using django-mutant and im having alot 
> problem understandingg what is really happening, i have tried the provided 
> guide http://integricho.github.io/2013/07/22/mutant-introduction/ but i'm 
> still confused, is there any one out there who understands on how to use 
> this app.
>
> The part of creating the actual table i understand but creating the 
> columns/fields is really giving headache. please assist
>
>
> Regards
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/47785a2a-f780-4430-a585-07a42a6c2846%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

apache module - which is better?!

[Hamed Rostami]

which is better? 
1-mod_python
2-mod_wsgi
give me reason & document about this.


-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/07ce8519-c7fe-464d-9a75-675ee07d9c6d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ManyToManyField causes invalid form when limit_choices_to argument set

[rgreene]

Good day,

This is a somewhat contrived example, but I'm having the same problem in a 
real project.

Assuming continents have many countries, and countries can belong to many 
continents, I have a continent_country "junction" table in the database and 
am using ManyToManyField as follows...

Models:
*class Country(models.Model):*
*country_id = models.AutoField(primary_key=True)*
*country_name = models.CharField(max_length=200)*

*class Meta:*
*managed = False*
*db_table = 'country'*

*def __unicode__(self):*
*return '%s' % (self.country_name)*

*class Continent(models.Model):*
*continent_id = models.AutoField(primary_key=True)*
*continent_name = models.CharField(max_length=200)*

*country = models.ManyToManyField(Country, 
db_table='continent_country', limit_choices_to=Q(country_id__exact=1))*

*class Meta:*
*managed = False*
*db_table = 'continent'*

Form:
*class ContinentForm(ModelForm):*
*class Meta:*
*model = Continent*
*widgets = {'country': CheckboxSelectMultiple}*

Using this form, everything saves as expected if I remove the 
limit_choices_to=Q(country_id__exact=1)argument. However, using the form 
with the ManyToManyField configured as shown causes the form to be returned 
with is_valid=False in the POST, indicating that field country is required.

I traced into the django code for a bit, but as a relative rookie got 
somewhat lost! Why does limiting the list prevent django from setting the 
country? How to work around this? Any ideas greatly appreciated...

Thanks in advance,
Randal

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/aa1249ca-dc1b-4abb-91e8-45a174a8506f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: ManyToManyField causes invalid form when limit_choices_to argument set

[rgreene]

Solved! It turned out the problem only occurred trying to uncheck the last 
checkbox. I needed to set blank=True on the ManyToManyField.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/045d2628-55da-4353-9f46-8893243161b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: apache module - which is better?!

[C. Kirby]

mod_wsgi

Django does not support mod_python

On Wednesday, April 30, 2014 2:22:01 PM UTC-5, Hamed Rostami wrote:
>
> which is better? 
> 1-mod_python
> 2-mod_wsgi
> give me reason & document about this.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c187ac20-15b5-4d18-a1ba-741979a2781e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

regression? validate_email accepts trailing dash

[Jason Brackins]

Hi everybody,

I've found this behavior that feels like a bug. I would like your opinion 
on whether it *is* a bug.

In django 1.6 an EmailField will accept an address of the form 
'f...@bar.com-'
In django 1.4 it would trigger a ValidationError.

Should this be considered a regression?

The way I interpret the email domain name specs f...@bar.com- is technically 
a valid email address, because bar.com- is technically a valid domain. But 
in practice there aren't any top level domains with a dash at the end, so 
this behavior is completely unexpected.

reference:
 * email spec: http://tools.ietf.org/html/rfc2822#section-3.4
 * domain name spec: http://tools.ietf.org/html/rfc1035#section-2.3.1


Tested in both versions like so:
   from django.core.validators import validate_email
   validate_email('f...@bar.com-')


Should I file a bug, do you think?

Thanks
-jason

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d7c5b6c5-6e32-454d-a5f0-e6556c7e2fa2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

error in "makemessages" command on latest django version (1.8dev)

[Fabio Caritas Barrionuevo da Luz]

hello, was testing in the latest version of Django[1] directly from Github 
and am having this problem


*optparse.OptionConflictError: option -e/--extension: conflicting option 
string(s): -e*

That would be a bug or am I doing something wrong

In this link you can see all the steps I did to get this error

https://asciinema.org/a/9213


[1] 
https://github.com/django/django/tree/8f6dff372b174e772920de6d82bd085f1a74eaf2

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/afcfaea9-145c-4abd-8cde-99022da9c2db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Email encoding (DKIM, long lines, etc..)

[Russell Keith-Magee]

On Wed, Apr 30, 2014 at 7:13 PM,  wrote:

> Hi !
>
> I am implementing DKIM validation for my emails.
> I noticed than some emails do not pass DKIM validation due to different
> body hashes.
> I followed the email flow, and found that postfix automatically truncates
> lines to 998 characters if they are too long (in accordance to
> https://tools.ietf.org/html/rfc2822#section-2.1.1).
>
> Such emails can be generated by Sentry, by my own apps, etc..
>
> Now about Django:
> When using EmailMessage, the charset is utf-8, and
> the Content-Transfer-Encoding is either 7bit or 8bit (automatically changes
> between them when the body contains non-ASCII characters).
> cf the ticket where the developers decided to switch from base64 to this
> behaviour : https://code.djangoproject.com/ticket/3472
>
> Quick validation with:
>
> >>> from django.core.mail import EmailMessage
>> >>> print EmailMessage('subject', 'body', 'from...@example.net', ['
>> to@example.net']).message().as_string()
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset="utf-8"
>> Content-Transfer-Encoding: 7bit
>> Subject: subject
>> From: from...@example.net
>> To: to@example.net
>> Date: Wed, 30 Apr 2014 11:01:44 -
>> Message-ID: <20140430110144.1564.85693@localhost>
>> body
>
>
>
> So at the moment, because Django says not to use base64 for utf-8 emails
> in its code, Django does no longer make sure that the lines are not too
> long, despite the RFC.
>
> I see 3 ways to make sure that the lines are not too long :
>
>- automatically split lines in a way that can be recognized by email
>readers (no idea how to do that properly..) (in Django/in the apps)
>- go back to base64 (but it seems to increase spam scores)
>- switch to quoted-printable (functioning code below, no idea of the
>potentially negative impact)
>
> from django.core.mail.message import utf8_charsetfrom email import Charset
> utf8_charset.body_encoding = Charset.QP
>
> What do you think ?
> Is Django code / app code the correct place to fix this ?
>

I'd say so. EmailMessage et al are the end user's public interface to
sending mail. If a user can use our API to generate a non-RFC compliant
mail, then that's a bug. Even if the root cause of the bug lies in a deeper
layer (e.g., Python's email library), we should do everything we can to
provide a workaround so that end users aren't affected.

Should Django respect the RFC ?
>

Absolutely. Django shouldn't expose a public API that makes it possible to
generate non-RFC emails payloads; furthermore, if there's any defacto
standards or common practices that make an email unacceptable on receipt
(e.g., the problem with base64 encoding getting flagged as spam), we should
be adhering to that, too.


> Any other ideas ?
>
>
It sounds like you've found a problem; this should be logged as a ticket so
it isn't forgotten. If you want to try your hand at a patch, the help would
be most welcome.

I'd need to do some more reading about the right solution; Quoted Printable
might be workable, but I'm also not aware if that will have any downstream
consequences. Some investigation will be required. The only option I can
rule out is moving back to base64, because that was done for a reason.
Unless you can validate that base64 encoding is no longer penalized by
popular spam services, this isn't an option.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq84941tt7_p1OB5Y3DBE0oHGaaM0F1RupL%3Du5_rQWEG8x7Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: The Django 1.7 tees!

[Russell Keith-Magee]

Hi Sithu,

Unfortunately, we can't add orders once the campaign is closed - this is
one of the features of TeeSpring as a fund raising method.

We *can* relaunch the campaign, but that campaign would be independent to
the original. It would have its own sales target, its own closing date, and
so on.

The lowest we can set the sales target is 20 shirts. I know there are about
6 other orders out there from people who missed the deadline; if there's
any other interest out there (speak up in a reply if you're interested), we
might consider reopening the campaign for a week.

Yours,
Russ Magee %-)


On Wed, Apr 30, 2014 at 11:58 PM, Sithembewena Lloyd Dube  wrote:

> To Whom It May Concern,
>
> I am devastated that I could not place an order for one of the new Django
> 1.7 tees. Now that I am ready to go, the campaign has ended on the merchant
> website.
>
> May I please place an order for one? I'd dearly like a memento of this
> milestone release. Pretty please? Size=small :)
>
> --
> Regards,
> Sithu Lloyd Dube
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAH-SnCB%2BVP%2BVpM3g4Uj4qP5sWfMv4%3DFvcuiNFvbYAErJknTnmw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq84-mq6pnpX3WaSGrfBccE-hT1e7MY3xWRp_O62pkUpZGxw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: apache module - which is better?!

[Russell Keith-Magee]

On Thu, May 1, 2014 at 4:18 AM, C. Kirby  wrote:

> mod_wsgi
>
> Django does not support mod_python
>
> It's also important to point out why this is - mod_python is dead. It's
been officially deprecated by Apache, and is not being maintained. It
hasn't been updated for several *years*.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq849zhipdg3TpOhzzJ8mwcnrtkO_pYkW27FdQavcfE3ieZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Error to customize a user

[Lucas Simon Rodrigues Magalhaes]

Hello, 

I have a problem when rendering my admin after creating a custom user. 

I followed the tutorial of Django [1] documentation and also Subclass 
AbstractBaseUser section of the book Twoo Scoops of Django. 

The error is described in this gist [2] and the code is in this repository 
[3]. 
The strange thing is that I set the USERNAME_FIELD = 'email' field in the 
model 


[1] # https://docs.djangoproject.com/en/1.5/topics/auth/customizing/ 
django.contrib.auth.models.CustomUser 
[2] https://gist.github.com/lucassimon/39f08556efa8a324d3fe 
[3] 
https://github.com/lucassimon/pywatch.com.br/tree/speaker_custom_user/speakers

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5e2ec502-d8bf-439d-befc-eb8032d58f51%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Error to customize a user

[alTus]

You don't have `has_perm` and `has_module_perms` methods defined in your 
user model while they are required:
https://docs.djangoproject.com/en/1.5/topics/auth/customizing/#custom-users-and-django-contrib-admin

Not sure if it would help coz traceback is not about them but you can at 
least try and watch if smth will change.

четверг, 1 мая 2014 г., 5:33:13 UTC+4 пользователь Lucas Simon Rodrigues 
Magalhaes написал:
>
> Hello, 
>
> I have a problem when rendering my admin after creating a custom user. 
>
> I followed the tutorial of Django [1] documentation and also Subclass 
> AbstractBaseUser section of the book Twoo Scoops of Django. 
>
> The error is described in this gist [2] and the code is in this repository 
> [3]. 
> The strange thing is that I set the USERNAME_FIELD = 'email' field in the 
> model 
>
>
> [1] # 
> https://docs.djangoproject.com/en/1.5/topics/auth/customizing/django.contrib.auth.models.CustomUser
>  
> [2] https://gist.github.com/lucassimon/39f08556efa8a324d3fe 
> [3] 
> https://github.com/lucassimon/pywatch.com.br/tree/speaker_custom_user/speakers
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f44d8750-a9fd-4ee3-b0e3-a886a32327cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Python/Django based Enterprise framowrk

[Kenan Bek]

Dear Django users,

I am working on ERP solution for my company and I used to use Django as a 
web application framework. To automatise process of creating CRUD forms I 
use Django Admin with Django Suit package. It works pretty well. BUT it 
does not gives features for full customisation because it is DYNAMIC form 
generation approach.

So, now, I am looking for frameworks based on Django which will give 
features for following issues:

- rich CRUD views generation (list/table, details, edit and create forms)
- ready to use file upload feature
- rich reporting feature
- and full customisation of code/view (I think it should generate python 
codes rather than generate dynamic views)

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5daa1b65-329a-4899-b54c-1236ece96fab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Version number comparison and beta

[Kevin Golding]

Hi all
I'm trying to update some existing code so that it will be compatible with 
1.7, in particular the use of settings.AUTH_USER_MODEL instead of 
get_user_model().
Given the differences I'm going to have to check the version numbers and 
then have two alternatives eg:

if StrictVersion(get_version()) >= StrictVersion('1.7'):
   new code
else:
   old code

However the current version number for 1.7 is 1.7b3, which is treated as being 
less than 1.7 according to StrictVersion.
In order to get it to work the way I want right now I'm going to have to 
compare with a version number such as 1.7a1, 
but this is going to look pretty ugly going forward.

What is the best practice for doing version number comparisons taking into 
account the existence of beta version numbers?

Thanks
Kevin

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c74612d3-87c7-4f4e-a709-416038fe1860%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.