Hi Piotr,
Thank you so much for your efforts over the summer.
I'd also like to apologise for my lack of communication; I certainly
haven't been a model mentor over the course of the program.
Although we may not have achieved all the goals we set out to achieve
at the start of the program, I don'
Thanks Piotr,
It's been interesting and helpful watching your progress on this project.
I wouldn't worry too much about not quite meeting all the goals you'd hoped
for - it's a deceptively difficult task.
In particular it's really difficult trying to maintain full backwards
comparability with
Hi,
Google Sumer of Code is almost ended. I was working on customizable
serialization. This project was a lot harder than I expected, and sadly
in my opinion I failed to do it right. I want to apologize for that and
especially for my poor communication with this group and my mentor. I
want to
Hi,
In the past 3 weeks, my project has changed a lot. First of all I
changed output of first phase of serialization. Previously it was python
native datatypes. At some point I added dictionary with metadata to it.
Metadata was used in second phase of serialization. Now after first
phase I re
W dniu 11.07.2012 14:04, Russell Keith-Magee pisze:
There is still problem with API and how to do some things but in my opinion
it's going in right direction.
Generally, I agree. I still have some concerns however; mostly around
the things that you're putting onto the Meta class.
related_serial
On Wed, Jul 11, 2012 at 8:18 AM, Piotr Grabowski wrote:
> Hi,
>
> It is time to midterm evaluation of my participation in gsoc so I want to
> summarize in this check-in what I have done in last month.
> https://gist.github.com/3085250 - here is something that can be
> "documentation". I wrote some
Hi,
It is time to midterm evaluation of my participation in gsoc so I want
to summarize in this check-in what I have done in last month.
https://gist.github.com/3085250 - here is something that can be
"documentation". I wrote some examples of ModelSerializer usage and how
it should work.
https
W dniu 26.06.2012 11:52, Tom Christie pisze:
> It is the way I am doing deserialization - pass instance to subfields
Seems fine. It's worth keeping in mind that there's two ways around
of doing this.
1. Create an empty instance first, then populate it with the field
values in turn.
2. Popul
> default deserialized_value don't returns anything. It sets the field
value.
Cool, that's exactly what I meant.
> but declaring function only to say "do nothing" isn't good solution for
me.
Declaring a method to simply 'pass' seems fine to me if you want to
override it to do nothing.
> It
W dniu 20.06.2012 13:50, Tom Christie pisze:
>deserialized_value function with empty content
Are you asking about how to be able to differentiate between a field
that deserializes to `None`, and a field that doesn't deserialize a
value at all?
No :) I had this problem before and I managed to
> if I put list in input I want list in output, not generator
I wouldn't worry about that. The input and output should be *comparable*,
but it doesn't mean they should be *identical*.
A couple of cases for example:
*) You should be able to pass both lists and generator expressions to a
given s
Hi!
This week I wrote simple serialization and deserialization for json
format so it's possible now to encode objects from and to json:
import django.core.serializers as s
class Foo(object):
def __init__(self):
self.bar = [Bar(), Bar(), Bar()]
self.x = "X"
class Bar(obje
Hi!
This week I managed to write deserialization functions and tests.
*Issues with deserialization*
Working on deserialization give me a lot thoughts about previous
concepts. I rewrite Field class so now Field can't be nested. Field can
only have subfields if subfields are attributes:
class C
Hi,
Sorry for being late with weekly update. Due to some issues with Meta
and my wrong understanding of metaclasses that Russell pointed I spend
time on enhance my knowledge about this. I rewrote also some part of
code that I have written week before.
This week I will do what I was suppose to
W dniu 29.05.2012 02:28, Russell Keith-Magee pisze:
Hi Piotr;
Apologies for the delay in responding to your updated API.
On Tue, May 22, 2012 at 6:59 AM, Piotr Grabowski wrote:
I do some changes to my previous API: (https://gist.github.com/2597306<-
change are included)
* which fields of o
Hi Piotr;
Apologies for the delay in responding to your updated API.
On Tue, May 22, 2012 at 6:59 AM, Piotr Grabowski wrote:
> I do some changes to my previous API: (https://gist.github.com/2597306 <-
> change are included)
>
> * which fields of object are default serialized. It's depend on
> i
On May 27, 7:37 pm, Piotr Grabowski wrote:
> Hi,
>
> This week I started coding my project. It' available on branch
> soc2012-serialization onhttps://github.com/grapo/django.
>
> I'm not very familiar with git so I'm not suer that I do it right:
> * I forked django repo from github
> * clone it to
Hi,
This week I started coding my project. It' available on branch
soc2012-serialization on https://github.com/grapo/django.
I'm not very familiar with git so I'm not suer that I do it right:
* I forked django repo from github
* clone it to my computer
* create new branch soc2012
* work in thi
I do some changes to my previous API: (https://gist.github.com/2597306
<- change are included)
* which fields of object are default serialized. It's depend on
include_default_field but opposite to Tom Christie solution it's default
value is True so all fields (eventually specified in Meta.mod
Hi,
During this week I was focused on my exams. Now I have more time for
serialization project. Sadly API isn't finished yet. 21 May in gsoc
calendar is time for start coding. Tomorrow I will send updates to API
proposal and I will present idea of algorithm (maybe list of steps will
be better
Hi,
This week I think about internal API for Serializer. I want that
developers can eventually use it for better customization of their
solutions.
Next week I must learn for my exams so I suppose I will not do much with
serialization project. I will try to resolve some issues about my API
t
W dniu 07.05.2012 20:13, Tom Christie pisze:
Hey Piotr,
Here's a few comments...
You have 'fields' and 'exclude' option, but it feels like it's missing
an 'include' option - How would you represent serializing all the
fields on a model instance (without replicating them), and
additionally in
W dniu 06.05.2012 10:45, Russell Keith-Magee pisze:
- I'm not sure I follow how class_name would be used in practice. The
act of deserialization is to take a block of data, and process it to
populate an object.
In the simplest case, you could provide an empty instance (or factory)
that is the
Hey Piotr,
Here's a few comments...
You have 'fields' and 'exclude' option, but it feels like it's missing an
'include' option - How would you represent serializing all the fields on a
model instance (without replicating them), and additionally including one
other field? I see that you could
On Sat, May 5, 2012 at 4:08 AM, Piotr Grabowski wrote:
> Hi,
>
> During this week I have a lot of work so I didn't manage to present my
> revised proposal in Monday like i said. Sorry. I have it now:
> https://gist.github.com/2597306
Hi Piotr,
At a high level, I think you're headed in the right
Hi,
During this week I have a lot of work so I didn't manage to present my
revised proposal in Monday like i said. Sorry. I have it now:
https://gist.github.com/2597306
Next week I hope there will be some discussion about my proposal. I will
also think how it should be done under the hood. Th
W dniu 27.04.2012 12:39, Tom Christie pisze:
Hey Piotr,
> I quickly skimmed the proposal and I noticed speed/performance wasn't
mentioned. I believe performance is important in serialization and
especially in deserialization.
Right. Also worth considering is making sure the API can deal with
Hey Piotr,
Thanks for the quick response.
> However sharing ideas and discuss how the API should look and work it
will be very desirable.
That'd be great, yup. I've got a couple of comments and questions about
bits of the API, but I'll wait until you've had a chance to post your
proposal t
On Apr 27, 12:11 pm, Piotr Grabowski wrote:
> I didn't think about performance a lot. There will be regressions.
> Now serialization is very simple: Iterate over fields, transform it into
> string (or somethink serializable), serialize it with json|yaml|xml.
> In my approach it is: transform (Mode
W dniu 27.04.2012 10:36, Anssi Kääriäinen pisze:
On Apr 27, 11:14 am, Piotr Grabowski wrote:
Hi!
I'm Piotr Grabowski, student from University of Wroclaw, Poland
In this Google Summer of Code I will deal with problem of customizable
serialization in Django.
You can find my proposal here https
On Apr 27, 11:14 am, Piotr Grabowski wrote:
> Hi!
>
> I'm Piotr Grabowski, student from University of Wroclaw, Poland
> In this Google Summer of Code I will deal with problem of customizable
> serialization in Django.
>
> You can find my proposal here https://gist.github.com/2319638
I quickly sk
Cool, thanks, all good points.
Slight haitus working on this right now whilst I try to get my head around
the right way to try to bring it more into line with the Forms API, but
hoping to pick it up again once I've marshaled my thoughts.
Obviously I'll keep the list updated if I do make more he
Hi! I put your code to good use in my project and have two minor
suggestions:
Make the signature of
def get_related_serializer(self, key)
like this:
def get_related_serializer(self, key, obj):
because the related serializer could also depend on obj (does for me).
Secondly: the naming of s
Yup.
The current implementation (see the github repo) allows properties and
methods that only take a 'self' argument to be serialized by adding the name
to 'fields' or 'include'.
If you need anything more involved then you'd write a custom method on the
Serializer class. (or a custom SerializerF
Looks really good, the current implementation for serialization is
pretty limited, so this will be a breath of fresh air :)
Using the proposed Serializations class, will it be possible to
serialize properties of a model that is not fields, for example
methods?
On Jun 15, 12:18 pm, Tom Christie
> A suggestion though, is to be able to declare serializers in a
> similar fashion as models or forms.
Actually that's a fair point, yup - the proposal could be made a little
closer to the existing Forms and Models APIs.
Something along these lines...
class ModelPKField(SerializerField):
def
Hi !
Looks like a great idea to me. I had already proposed something
similar when there were talks for implementing this for SOC.
Like I had said in this thread, I have already implemented something
that works a similar way as what you propose :
http://readthedocs.org/docs/any2any/en/latest/doc_pa
> The purpose of this project is to define (and then implement) a DSL
> for serialization.
If a DSL is what you are looking for, then I withdraw my proposal.
The idea of hosting yet another DSL inside Django project scares me a
little.
I'll just implement my idea as a separate project, I guess.
On Wed, Apr 6, 2011 at 11:31 AM, DaNmarner wrote:
>> So - show me what it would look like. Show me how I, as a third party,
>> would use your proposed syntax to define output that would match
>> Django's existing serialization scheme. Yes, this serialization format
>> will exist as a built in defa
> So - show me what it would look like. Show me how I, as a third party,
> would use your proposed syntax to define output that would match
> Django's existing serialization scheme. Yes, this serialization format
> will exist as a built in default; but I should be able to reproduce
> that format in
On Wed, Apr 6, 2011 at 7:44 AM, DaNmarner wrote:
>> 1) It's almost illegible. Between your mail client's munging of line
>> wrapping, and the completely unreadable code samples, it's very
>> difficult to tell if you have presented a good idea.
>
> Pardon the format. I actually auto-wrapped the tex
As a side note: I encountered the use case for customizing
serialization last summer when building my own blog project (I wanted
an app that could import/export my models from/to wordpress/blogger
XML. The API I proposed largely emerged from my thought back then. I'm
willing to commit efforts to ma
> 1) It's almost illegible. Between your mail client's munging of line
> wrapping, and the completely unreadable code samples, it's very
> difficult to tell if you have presented a good idea.
Pardon the format. I actually auto-wrapped the text with vim and copy
pasted at the first time. Realizing
On Sun, Apr 3, 2011 at 6:58 AM, DaNmarner wrote:
> I've got some more crystalized details about my proposal.
>
> Here are the target result if this proposal is implementated:
>
> 1. User could configure serialization for each model.
>
> 2. In fact, user could configure the serialization details do
On Thu, Mar 31, 2011 at 7:38 PM, Vivek Narayanan wrote:
> Hi Russ,
>
> Thanks for the suggestions once again, I've thought of changing the
> model for handling nested fields.
>
> Each model can have a no of serializers, and they can be plugged in to
> other serializers
> and in this way nested mod
After a few days' consideration, I've got some more crystalized
details about my proposal.
Here are the target result if this proposal is implementated:
1. User could configure serialization for each model.
2. In fact, user could configure the serialization details down to
each field of each mod
I've got some more crystalized details about my proposal.
Here are the target result if this proposal is implementated:
1. User could configure serialization for each model.
2. In fact, user could configure the serialization details down to
each field
of each model. That means:
3. The key n
Hi Russ,
Thanks for the suggestions once again, I've thought of changing the
model for handling nested fields.
Each model can have a no of serializers, and they can be plugged in to
other serializers
and in this way nested models can be handled instead of cycling
through a tree of arbitrary depth
> I also haven't seen any proposals or examples of how I'd use the API as
> an end user - are people going to be able to register serialisers to
> models (since they're apparently tied to specific models anyway)?
There will be different types of serializers like JSONSerializer,
YAMLSerializer, XML
>From a previous discussion on this list (
http://groups.google.com/group/django-developers/browse_thread/thread/2da69b9e24cf3438/17d87e3b27d4395d
) I gather that modifying the field options of a Model is not
desirable due to a loss in orthogonality. Here is a modified
permissions framework for ser
On Mar 8, 3:14 pm, Tom Evans wrote:
> Splitting down your project into small chunks will also demonstrate to
> people reading your proposal that you understand the subject matter,
> and they can have a high confidence of the project being delivered.
Thanks, I didn't know this and I don't have
On Mon, Mar 7, 2011 at 4:28 PM, Vivek Narayanan wrote:
> ...
> In the run up to May 23rd, I'll be familiarizing myself with the
> codebase and community practices of Django, examining all the
> integration points and looking at the best practices of serialization.
>
> Week 1: I'll be implementing
On Mar 6, 11:54 am, Russell Keith-Magee
wrote:
> On Sun, Mar 6, 2011 at 2:41 PM, Vivek Narayanan wrote:
> > @Sebastien: I got your point about using a dict as an intermediate
> > structure and the use of recursion, and I looked at your
> > implementation which is somewhat similar to what I have
On Mar 6, 11:54 am, Russell Keith-Magee
wrote:
> On Sun, Mar 6, 2011 at 2:41 PM, Vivek Narayanan wrote:
> > @Sebastien: I got your point about using a dict as an intermediate
> > structure and the use of recursion, and I looked at your
> > implementation which is somewhat similar to what I have
On Sun, Mar 6, 2011 at 2:41 PM, Vivek Narayanan wrote:
> @Sebastien: I got your point about using a dict as an intermediate
> structure and the use of recursion, and I looked at your
> implementation which is somewhat similar to what I have in mind.
>
> Well, here is a list of deliverables for the
@Sebastien: I got your point about using a dict as an intermediate
structure and the use of recursion, and I looked at your
implementation which is somewhat similar to what I have in mind.
Well, here is a list of deliverables for the project:
• Investigate existing structure of the serializer, ma
Ok ... I have to admit I was not very clear. Here is what I meant,
illustrated with some code examples :
http://readthedocs.org/docs/django-serializers-draft/en/latest/index.html
These are my "dream" django-serializers !
On Mar 1, 10:20 am, Vivek Narayanan wrote:
> @Sebastien, Thank you for you
@Sebastien, Thank you for your suggestions, that's exactly what I had
considered.
As I've mentioned earlier, I would like to start with providing basic
XML, JSON, YAML and text serializers, that would be built on the
existing base structure with a few modifications, as building blocks.
But before
Hi
I just stumbled across this discussion ... even though I have always
been very interested about contributing to Django, I never took the
step yet ! But this is actually a topic that interests me very much
(even though for the moment it is Vivek's).
For several projects I am working on (a lot o
On Thu, Feb 24, 2011 at 10:24 PM, Vivek Narayanan wrote:
> Hi,
>
> I am Vivek Narayanan, an undergrad student at IIT, Varanasi in India
> and am interested in participating in this year's SoC
Hi Vivek, and thanks for your interest in the GSoC!
> Problem
>
> Django provides a seriali
Thanks for the advice! Of course I will apply in these year and do the
home work. If some one has any other resource I it can be usefull ,
plese post it. So If I have some advances I will share it with all!
2010/2/23 Russell Keith-Magee :
> On Tue, Feb 23, 2010 at 1:26 PM, Jesus Mager wrote:
>> H
On Tue, Feb 23, 2010 at 1:26 PM, Jesus Mager wrote:
> Hi all!
>
> My name is Jesus Mager, and I'm student at the National Autonomous
> University of Mexico.I am interested in in taking part of Google
> Summer of Code for the diango project.
> The Customizable Serialization sound a good idea. Djan
On Tue, Feb 23, 2010 at 12:26 AM, Jesus Mager wrote:
> Hi all!
>
> My name is Jesus Mager, and I'm student at the National Autonomous
> University of Mexico.I am interested in in taking part of Google
> Summer of Code for the diango project.
> The Customizable Serialization sound a good idea. Dja
63 matches
Mail list logo
