Re: Composite fields

[Aron Podrigal]

Hi Thomas, I replied earlier before you posted, looks like my message got 
sent actually a lot later.

having a function like  *models.constrain(x, y, unique=True) *makes sense 
for inline declarations.

About null handling, If all columns on the database are null=True and all 
columns have a null value, then the composite field value would be  `None'. 
Otherwise it would be a dict mapping to the subfields, and a query needs to 
specify the subfields it queries against.


Aron.

On Saturday, March 7, 2015 at 11:16:12 PM UTC-5, Thomas Stephenson wrote:
>
> Aymeric,
>
> Thanks for your input. I feel some of your concerns have been addressed in 
> the DEPs I made, which have included quite a bit of input from this thread 
> along with the original design. That said, some of the points you've raised 
> are new and haven't been raised by other people, so I'll give you a full 
> reply.
>
> 1) That's still something I have to do, but more time consuming than other 
> parts of creating the proposal and I've put it off until I have a while to 
> do it. The original implementation was done without too much consideration 
> of prior attempts, because I was more interested in getting something 
> working than I was in learning from the past. 
>
> 2) I agree. The new syntax I've proposed is to add one or more class-level 
> methods to the django.db.models API. The new syntax for "inline" fields is:
>
> class MyModel(models.Model):
> x = models.IntegerField()
> y = models.IntegerField()
> point = models.constrain(x, y, unique=True)
>
good 

>
> The reason for not using the CompositeField constructor is that a lot of 
> the options which make sense for standalone field constructors (and all the 
> other field classes) make absolutely no sense when you're mainly leveraging 
> composite fields to provide a table level constraint to two existing 
> fields. Also there are some things that are commonly done in practice (like 
> providing `verbose_name` as a positional arg) that make adding multiple 
> leading positional arguments difficult.
>
> Note: It's a shame that we can't use py3's keyword only arguments here.
>
> 3) No, not all the field base API makes sense for composite fields -- in 
> fact most of it doesn't. This is a huge problem with fields in general, not 
> just composite fields -- there's just too much functionality on the basic 
> Field class that assumes a one-to-one mapping between a Field and a 
> database column and too many parameters accepted by field base that only 
> make sense for subsets of the available field types.
>
> e.g. 
> - What does "blank" or "max_length" mean for an IntegerField?
> - What does 'rel' mean for a NullBooleanField?
> - What does get_col mean for a ManyToManyField?
> etc.
>
> To fix this would mean introducing significant backwards incompatible 
> changes and, while I would support such a change, I'm not sure it's a 
> discussion that affects the ability to implement composite fields.
>
> 4) The addition of the `isnull` field is mainly to support the ability to 
> query for whether a composite field is NULL. If we leave it implementation 
> defined as to how to interpret whether a specific configuration of 
> subfields maps to a python `None` value for the composite field, then it 
> becomes really difficult to define lookup transformations to query for null 
> values in the table. 
>
> But although it sounded like a good idea when I came up with it, it raises 
> more questions than it solves. I'm more than ready to go back to the 
> drawing board on that one. 
>
5) Inheritance in the model API is complicated enough as it is without 
> adding inheritance of field types. Yes, it could be supported by "beating 
> the metaclass into submission", but it's not something that I think adds 
> any particular value. I did change the "no subclassing at all" restriction 
> to "only one class in an inheritance heirarchy can define subfields" when 
> writing the DEP though, because Ansarri wants the ability for users to 
> extend ForeignKey with their own python behaviour. 
>
> Thomas
>
>
>
> On 7 March 2015 at 22:31, Aymeric Augustin  > wrote:
>
>> Hello Thomas,
>>
>> It’s hard for me to digest a two-page-long email on a complex topic during
>> the week. I bookmarked your first email when it came in. It’s Saturday, 
>> 11am,
>> and I dedicated my first chunk of quality brain time to reading the entire
>> thread. I’ll let you ponder what the effect of your second email was.
>>
>> In fact, if you propose something stupid, you’ll get a quick answer, 
>> because
>> it’s easy to explain. Not getting answers right now means that your 
>> proposal
>> is good enough to require consideration. Yes, that’s counter-intuitive.
>>
>> With that out of the way, here are my thoughts on your proposal. Some 
>> overlap
>> with what other people have said in the thread.
>>
>> 1) I would find it reassuring if you described the landscape of past 
>> attempts,
>> what 

Re: Composite fields

[Aron Podrigal]

Hi Thomas,

First, thanks for your work. I've had a plan to start working on this 
feature last week,
but I got too many things to work on with higher priority, Thankfully you 
opted for this, again Thanks.

just sharing my thoughts,

1)  I like the MoneyField model style definition.

2) I don't like the inline declaration, I would opt for Anssi's proposal.

3) as Aymeric mentioned, NOT NULL only makes sense for a real column on the 
database, so that should be only be handled on the SubFields.
Assigning python `None' to the CompositeField should be handled by the 
value_from_dict method.

4) querying syntax, sounds fare. However depending on how we decide on 
exposing the subfields through the Model Meta API, 
eg. if the subfields would be returned by default, then we should also 
allow directly querying of the subfield.

Aron


On Saturday, March 7, 2015 at 6:31:53 AM UTC-5, Aymeric Augustin wrote:
>
> Hello Thomas, 
>
> It’s hard for me to digest a two-page-long email on a complex topic during 
> the week. I bookmarked your first email when it came in. It’s Saturday, 
> 11am, 
> and I dedicated my first chunk of quality brain time to reading the entire 
> thread. I’ll let you ponder what the effect of your second email was. 
>
> In fact, if you propose something stupid, you’ll get a quick answer, 
> because 
> it’s easy to explain. Not getting answers right now means that your 
> proposal 
> is good enough to require consideration. Yes, that’s counter-intuitive. 
>
> With that out of the way, here are my thoughts on your proposal. Some 
> overlap 
> with what other people have said in the thread. 
>
> 1) I would find it reassuring if you described the landscape of past 
> attempts, 
> what good ideas you’re keeping, what bad ideas you’re throwing away — in 
> short, if you convinced us that you’re building on top of past attempts. 
> The 
> main goal of this exercise is to guarantee that you don’t overlook a use 
> case 
> or an argument that made consensus in the past. (Don’t spend too much time 
> on 
> code; it my experience it’s harder to reuse and code matters much less 
> than 
> design. 
>
> 2) The syntax for inline composite fields doesn't look very nice. Could 
> you 
> simplify it somehow? Anssi’s proposal is good. I assume that a composite 
> field 
> could add the subfields to the model class if they aren't defined 
> explicitly 
> and their names passed in arguments to the composite field. 
>
> 3) Have you checked that all the Field APIs make sense for CompositeField? 
> It's quite obvious that value_from/to_dict are needed. It's less obvious 
> that 
> everything else is still needed. 
>
> 4) I'm wary of the extra 'isnull' column. Couldn't we required that, if 
> the 
> composite field is NULL, at least one of the subfields is NULL? My idea is 
> that a nullable composite field would consider itself NULL if all nullable 
> subfields are NULL. Declaring a composite subfield nullable when all 
> subfields 
> are non-nullable would be an error. In your MoneyField example, the amount 
> subfield should be nullable when the composite field is nullable. 
>
> 5) I understand the first two restrictions. They required deeper 
> refactorings 
> to be lifted. The reason for the third one is less clear. Is it just a 
> matter 
> of beating the metaclass into cooperation? 
>
> Best, 
>
> -- 
> Aymeric. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e1024af3-2822-4136-979c-7980e8c99dc5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite fields

[Thomas Stephenson]

Aymeric,

Thanks for your input. I feel some of your concerns have been addressed in
the DEPs I made, which have included quite a bit of input from this thread
along with the original design. That said, some of the points you've raised
are new and haven't been raised by other people, so I'll give you a full
reply.

1) That's still something I have to do, but more time consuming than other
parts of creating the proposal and I've put it off until I have a while to
do it. The original implementation was done without too much consideration
of prior attempts, because I was more interested in getting something
working than I was in learning from the past.

2) I agree. The new syntax I've proposed is to add one or more class-level
methods to the django.db.models API. The new syntax for "inline" fields is:

class MyModel(models.Model):
x = models.IntegerField()
y = models.IntegerField()
point = models.constrain(x, y, unique=True)

The reason for not using the CompositeField constructor is that a lot of
the options which make sense for standalone field constructors (and all the
other field classes) make absolutely no sense when you're mainly leveraging
composite fields to provide a table level constraint to two existing
fields. Also there are some things that are commonly done in practice (like
providing `verbose_name` as a positional arg) that make adding multiple
leading positional arguments difficult.

Note: It's a shame that we can't use py3's keyword only arguments here.

3) No, not all the field base API makes sense for composite fields -- in
fact most of it doesn't. This is a huge problem with fields in general, not
just composite fields -- there's just too much functionality on the basic
Field class that assumes a one-to-one mapping between a Field and a
database column and too many parameters accepted by field base that only
make sense for subsets of the available field types.

e.g.
- What does "blank" or "max_length" mean for an IntegerField?
- What does 'rel' mean for a NullBooleanField?
- What does get_col mean for a ManyToManyField?
etc.

To fix this would mean introducing significant backwards incompatible
changes and, while I would support such a change, I'm not sure it's a
discussion that affects the ability to implement composite fields.

4) The addition of the `isnull` field is mainly to support the ability to
query for whether a composite field is NULL. If we leave it implementation
defined as to how to interpret whether a specific configuration of
subfields maps to a python `None` value for the composite field, then it
becomes really difficult to define lookup transformations to query for null
values in the table.

But although it sounded like a good idea when I came up with it, it raises
more questions than it solves. I'm more than ready to go back to the
drawing board on that one.

5) Inheritance in the model API is complicated enough as it is without
adding inheritance of field types. Yes, it could be supported by "beating
the metaclass into submission", but it's not something that I think adds
any particular value. I did change the "no subclassing at all" restriction
to "only one class in an inheritance heirarchy can define subfields" when
writing the DEP though, because Ansarri wants the ability for users to
extend ForeignKey with their own python behaviour.

Thomas



On 7 March 2015 at 22:31, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> Hello Thomas,
>
> It’s hard for me to digest a two-page-long email on a complex topic during
> the week. I bookmarked your first email when it came in. It’s Saturday,
> 11am,
> and I dedicated my first chunk of quality brain time to reading the entire
> thread. I’ll let you ponder what the effect of your second email was.
>
> In fact, if you propose something stupid, you’ll get a quick answer,
> because
> it’s easy to explain. Not getting answers right now means that your
> proposal
> is good enough to require consideration. Yes, that’s counter-intuitive.
>
> With that out of the way, here are my thoughts on your proposal. Some
> overlap
> with what other people have said in the thread.
>
> 1) I would find it reassuring if you described the landscape of past
> attempts,
> what good ideas you’re keeping, what bad ideas you’re throwing away — in
> short, if you convinced us that you’re building on top of past attempts.
> The
> main goal of this exercise is to guarantee that you don’t overlook a use
> case
> or an argument that made consensus in the past. (Don’t spend too much time
> on
> code; it my experience it’s harder to reuse and code matters much less than
> design.
>
> 2) The syntax for inline composite fields doesn't look very nice. Could you
> simplify it somehow? Anssi’s proposal is good. I assume that a composite
> field
> could add the subfields to the model class if they aren't defined
> explicitly
> and their names passed in arguments to the composite field.
>
> 3) Have you checked that all the Field APIs make 

how to run django in window 8

[Alok Rodhiya]

i spend the overnight in installing django but i am unable to get it
plz someone post the .exe of django so i can install it nd get my work 
started

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/eadcf6aa-80bc-4d75-9f90-a227f11d9262%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Database based on country]

[Fabio Caritas Barrionuevo da Luz]

Hello xino12.

This group is for the discussion of the development of Django itself. If 
you want to ask questions about using Django, please post on django-users 
.


--
Fábio C. Barrionuevo da Luz

Em sábado, 7 de março de 2015 16:52:35 UTC-3, xino12 escreveu:
>
> Hi,
>
> is there any possibility that we could select the database to which route 
> a request of a user depending on the geolocalization of the client? Or the 
> user country?
>
> I've check some documentation of the dbrouters, but I am concerned that if 
> a user travels to another country he is going to be routed to the wrong 
> database.
>
> Does anybody have this issue?
>
> -- 
> Gràcies,
>
> Rubén
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ae8a3f2f-eb9f-4e14-87d6-cc4bd985886d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Database based on country]

[xina towner]

Hi,

is there any possibility that we could select the database to which route a
request of a user depending on the geolocalization of the client? Or the
user country?

I've check some documentation of the dbrouters, but I am concerned that if
a user travels to another country he is going to be routed to the wrong
database.

Does anybody have this issue?

-- 
Gràcies,

Rubén

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

Fellow Report - March 6, 2015

[Tim Graham]

As you know if you saw Russ's recent post on the Django blog 
,
 
the fellowship program has resumed as of this week. A big thank you to 
everyone who helped with the fundraising efforts and contributed to the 
campaign!


Highlights of this week included catching up on the backlog of unreviewed 
tickets and tending to 1.8 release blockers.

Report for week ending March 6, 2015:

Triaged

---

https://code.djangoproject.com/ticket/24437 - contrib.auth @ 1.8b1 breaks 
existing projects / applications using Mongoengine (invalid)

https://code.djangoproject.com/ticket/24196 - Filtering __in a sliced 
queryset with a 0 limit raises an unexpected error (accepted)

https://code.djangoproject.com/ticket/24349 - Limit URL domain name labels 
to 63 characters (accepted)

https://code.djangoproject.com/ticket/24417 - Add 
ModelAdmin.get_list_select_related() (accepted)

https://code.djangoproject.com/ticket/24296 - clear select fields for 
`.exists()` of distinct, non-sliced querysets (accepted)

https://code.djangoproject.com/ticket/24440 - debug view could use 
additional padding for individual stack rows. (accepted)

https://code.djangoproject.com/ticket/24162 - "Method Flowchart" for all 
CB(G)V documentation pages (accepted)

https://code.djangoproject.com/ticket/24443 - Changing upload_to on a 
filefield creates a migration despite not changing the database at all 
(invalid)

https://code.djangoproject.com/ticket/24441 - 
core.files.images.get_image_dimensions broken on invalid images (accepted)

https://code.djangoproject.com/ticket/24435 - Removing blank=True, 
null=True from ManyToMany field causes data deletion in migration (accepted)

https://code.djangoproject.com/ticket/24434 - Django Custom Field inherits 
ForeignKey deconstruct() fails (accepted)

https://code.djangoproject.com/ticket/24426 - Admin actions panel is always 
hidden if show_full_result_count = False (accepted)

https://code.djangoproject.com/ticket/24248 - 
django.db.utils.OperationalError: no such table: creating models from 
running manage.py inspectdb (worksforme)

https://code.djangoproject.com/ticket/24342 - Add EnumField (someday/maybe)

https://code.djangoproject.com/ticket/24150 - Settings changed at runtime 
not reflected in management commands (worksforme)

https://code.djangoproject.com/ticket/24364 - Document that 
ManifestStaticFilesStorage shouldn't be used during testing (accepted)

https://code.djangoproject.com/ticket/24419 - Provide an easy way to test 
email connection (accepted)

https://code.djangoproject.com/ticket/24281 - Improve docs for auto_now & 
auto_now_add and timezone handling (accepted)

https://code.djangoproject.com/ticket/24156 - inherited manytomany.all() 
empty when 2 or more inherited model from abstract one (accepted)

https://code.djangoproject.com/ticket/24134 - Document short command line 
options for management commands (accepted)

https://code.djangoproject.com/ticket/24171 - (1054, "Unknown column 
'__col1' in 'field list'") when using values, annotate, and aggregate 
(accepted)

https://code.djangoproject.com/ticket/24421 - Querying a reverse 
ForeignObject relation using exclude() fails (accepted)

https://code.djangoproject.com/ticket/2 - Update django admin visual 
style to make it look modern (needsinfo)

https://code.djangoproject.com/ticket/24276 - 
django.contrib.auth.decorators.user_passes_test doesn't pass *args and 
*kwargs to resolve_url (won’t fix)

https://code.djangoproject.com/ticket/24422 - Messages framework not 
correctly encoding messages (needsinfo)

https://code.djangoproject.com/ticket/24385 - Sum() doesn't seem to respect 
.distinct() in the queryset filter before .aggregate() when filtering by 
m2m. (accepted)

https://code.djangoproject.com/ticket/24430 - wildcard matching and 
reversing of URLs (won’t fix)

https://code.djangoproject.com/ticket/24347 -  parameter 'widget' of 
BoundField.as_widget is ignored (needsinfo)

https://code.djangoproject.com/ticket/24292 - {% blocktrans with count 
n=something %} isn't accepted (won’t fix)

https://code.djangoproject.com/ticket/24256 - No easy way to access the 
filtered queryset from admin.SimpleListFilter (needsinfo)

https://code.djangoproject.com/ticket/24447 - Migrations do not execute 
create_fk_sql() when adding a foreign key to a field (accepted)

https://code.djangoproject.com/ticket/24448 - Add a management command to 
generate new SECRET_KEY (won’t fix)

https://code.djangoproject.com/ticket/24445 - DurationField with default='1 
00:00' triggers validation on otherwise empty inline formsets (invalid)

https://code.djangoproject.com/ticket/24276 - 
django.contrib.auth.decorators.user_passes_test doesn't pass *args and 
*kwargs to resolve_url (won’t fix)

https://code.djangoproject.com/ticket/24348 - Allow to pass on initial data 
to change form for existing objects (again). (needsinfo)

Re: status of 1.8 release blockers

[Tim Graham]

With about 10 days to go until the scheduled date for the release candidate 
(Monday, March 16), there's just one blocker that Anssi's working on (looks 
like tests aren't passing yet) [#24171]. About 7 issues have been fixed in 
1.8 since the beta release.

On Wednesday, February 25, 2015 at 3:43:15 AM UTC-5, raulcd wrote:
>
> \o/
>
> On Wed, Feb 25, 2015 at 1:08 AM, Tim Graham  > wrote:
>
>> Zero blockers as of this writing. If we survive the next 12 hours with no 
>> new ones, I'll release the beta around then (famous last words).
>>
>>
>> On Monday, February 23, 2015 at 7:29:09 PM UTC-5, Tim Graham wrote:
>>>
>>> Previous two issues have been fixed, and now we have two new issues:
>>>
>>> #24391  UUIDField with 
>>> default=uuid4 triggers validation on otherwise empty inline formsets 
>>> 
>>>
>>> #24395  Cannot reference 
>>> FK relation from inline ModelForm.save() 
>>> 
>>>
>>> There is a chance to resolve them both tomorrow and then release the 
>>> beta.
>>>
>>> On Saturday, February 21, 2015 at 3:53:51 PM UTC-5, Tim Graham wrote:

 Patches for the two remaining blockers are awaiting review.

 #24381  Cache pickling 
 exception in 1.8a1 with cross-table filter params 
 
 #24377  UUIDField as 
 primary key breaks inline admins 
 

 On Friday, February 20, 2015 at 4:48:01 PM UTC-5, Tim Graham wrote:
>
> The three issues from last time are resolved, but there is a new issue 
> I've been working on today. I have a tentative fix, but there is a 
> failing 
> test. Assuming nothing else comes up, I might consider releasing the beta 
> tomorrow even if I can't solve that by then as it's not really a new 
> issue, 
> just magnified by the fact that UUIDField is in core and that it's 
> implementation as a primary_key requires default=uuid.uuid4 unlike some 
> existing third-party implementations.
>
> #24377  UUIDField as 
> primary key breaks inline admins 
> 
>
> On Thursday, February 19, 2015 at 2:45:07 AM UTC-5, Loïc Bistuer wrote:
>>
>> From my point of view #24351 is ready for a final sanity check and 
>> merging. 
>>
>> -- 
>> Loïc 
>>
>> > On Feb 19, 2015, at 10:10, Tim Graham  wrote: 
>> > 
>> > 3 issues remain. I haven't confirmed with the owners, but it seems 
>> to me there may be a good chance to wrap them up tomorrow. 
>> > 
>> > 
>> > #24351  RunPython/RunSQL operations in contrib migrations 
>> and multi-db routers. 
>> > Owner: Loic 
>> > Status: In review. 
>> > 
>> > 
>> > #24328 The new Options._get_fields() method needs to be cleaned up 
>> > Owner: Anssi 
>> > Status: In review. 
>> > 
>> > #24343 UUID foreign key accessor returns inconsistent type 
>> > 
>> > Owner: Marc 
>> > Status: Marc to polish patch. 
>> > 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups "Django developers (Contributions to Django itself)" group. 
>> > To unsubscribe from this group and stop receiving emails from it, 
>> send an email to django-develop...@googlegroups.com. 
>> > To post to this group, send email to django-d...@googlegroups.com. 
>> > Visit this group at http://groups.google.com/
>> group/django-developers. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/
>> 170625d3-1bb5-4b9d-ab74-501fd5dea86b%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 developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to django-develop...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/7d933ca2-ed55-408b-bdce-551060e24d54%40googlegroups.com
>>  
>> 
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to 

Re: CSRF cipher in xor + base64 or Vignere cipher

[Erik Romijn]

Hello,

In the context of a one time pad on the CSRF token, I don’t see a security 
advantage to either cipher here. If I read correctly, the argument for Vignere 
is that it can already produce output suitable for inclusion in form values, 
not requiring base64 encoding of the one time pad.

I’ve looked up the current implementations that have been contributed:
Here’s the XOR+base64 implementation:
https://github.com/django/django/compare/66285eb2a7a6fb3e6ec0eec0bbc15a5e94215872#diff-a3be722ce2831a8d11438021d44cedf1R62
 

And the Vignere implementation:
https://github.com/django/django/pull/1477/files#diff-a3be722ce2831a8d11438021d44cedf1R40
 


Though the Vignere implementation means that base64 is not required and is 
significantly shorter, it seems considerably more complex and error prone. I 
can’t instantly see whether this implementation is correct. The XOR+base64 
implementation, on the other hand, is straight forward and obvious. Therefore, 
if the current implementations are a proper measure for the complexity of 
implementing either option, XOR+base64 is my strong preference. Slightly more 
work, but substantially simpler, reducing the risk of overlooked implementation 
errors.

Erik

> On 07 Mar 2015, at 13:31, Asif Saifuddin  wrote:
> 
> Hi,
> 
> Just start working on this ticket https://code.djangoproject.com/ticket/20869
> 
> wondering what should be the preferred way ?
> 
> using XOR or Vignere Cipher?
> 
> 
> Reagrds
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to django-developers@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/django-developers 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/3d23b87e-c153-4035-a838-331d5bc9cd1d%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 developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/10CE5813-C1DA-4231-8721-36A2AEEB8748%40solidlinks.nl.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

CSRF cipher in xor + base64 or Vignere cipher

[Asif Saifuddin]

Hi,

Just start working on this 
ticket https://code.djangoproject.com/ticket/20869

wondering what should be the preferred way ?

using XOR or Vignere Cipher?


Reagrds

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3d23b87e-c153-4035-a838-331d5bc9cd1d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Composite fields

[Aymeric Augustin]

Hello Thomas,

It’s hard for me to digest a two-page-long email on a complex topic during
the week. I bookmarked your first email when it came in. It’s Saturday, 11am,
and I dedicated my first chunk of quality brain time to reading the entire
thread. I’ll let you ponder what the effect of your second email was.

In fact, if you propose something stupid, you’ll get a quick answer, because
it’s easy to explain. Not getting answers right now means that your proposal
is good enough to require consideration. Yes, that’s counter-intuitive.

With that out of the way, here are my thoughts on your proposal. Some overlap
with what other people have said in the thread.

1) I would find it reassuring if you described the landscape of past attempts,
what good ideas you’re keeping, what bad ideas you’re throwing away — in
short, if you convinced us that you’re building on top of past attempts. The
main goal of this exercise is to guarantee that you don’t overlook a use case
or an argument that made consensus in the past. (Don’t spend too much time on
code; it my experience it’s harder to reuse and code matters much less than
design.

2) The syntax for inline composite fields doesn't look very nice. Could you
simplify it somehow? Anssi’s proposal is good. I assume that a composite field
could add the subfields to the model class if they aren't defined explicitly
and their names passed in arguments to the composite field.

3) Have you checked that all the Field APIs make sense for CompositeField?
It's quite obvious that value_from/to_dict are needed. It's less obvious that
everything else is still needed.

4) I'm wary of the extra 'isnull' column. Couldn't we required that, if the
composite field is NULL, at least one of the subfields is NULL? My idea is
that a nullable composite field would consider itself NULL if all nullable
subfields are NULL. Declaring a composite subfield nullable when all subfields
are non-nullable would be an error. In your MoneyField example, the amount
subfield should be nullable when the composite field is nullable.

5) I understand the first two restrictions. They required deeper refactorings
to be lifted. The reason for the third one is less clear. Is it just a matter
of beating the metaclass into cooperation?

Best,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2130B21B-41FA-4928-BC9C-5F5BAADAD7E0%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.