Re: first() and last(), earliest() and latest()

[AK]

On 02/27/2013 05:34 PM, Wim Feijen wrote:

Hi all,

We struggled to get a proper definition for a first() and last() 
method vs. earliest() and latest() . I'd like to make one proposal. 
After that, I really like your opinion on which syntax you prefer.


First, let me give you a lenghty introduction. We discussed several 
use cases on this mailing list 
. 
Then, I realized that:


.filter(last_name__startswith='b').order_by('last_name').first()
is an acceptable compromise for me to use in stead of:
.first(last_name__startswith='b').order_by('last_name')

Last weekend Aymeric explained to me that earliest can actually 
accomplish the same:

.filter(last_name__startswith='b').earliest('last_name')

Then, I find "earliest" an inappropriate name, because it does not 
describe functioning well.


Therefore, my proposal is, if we are going to implement the earliest 
and latest method, we should definitely rename them to: first and latest.


After that, there is only one question left:

Which style do you prefer?

.filter(last_name__startswith='b').order_by('last_name').first()# 
clear and long
.first(last_name__startswith='b').order_by('last_name')# first 
method has filter syntax.
.filter(last_name__startswith='b').first('last_name')   # first method 
has order_by syntax.


So, what do you think?

Best regards,

Wim




How about first as a function? I think it's very often useful not just 
for querysets but

for all kind of iterables:

def first(iterable, default=None):
try:
return next(iter(iterable))
except StopIteration:
return default

 -ak

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: first() and last(), earliest() and latest()

[Shai Berger]

Oopsie:

On Thursday 28 February 2013, Shai Berger wrote:
> 
> Note that with this suggestion:
> 
>   qset.filter(a=b).first(c)
> 
> is not equivalent to
> 
>   qset.order_by(c).filter(a=b)
> 
That should have read

qset.order_by(c).first(a=b)

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: first() and last(), earliest() and latest()

[Shai Berger]

On Thursday 28 February 2013, Aymeric Augustin wrote:
> 
> I would support renaming them to first / last through a deprecation path.
> The new aliases would be available immediately, the old ones would be
> removed in two versions.
> 
+1

> And while we're there, I suggest to rely on the existing "ordering" meta
> attribute and to remove "get_latest_by". I suspect that in many cases
> these two attributes have the same value, and you can specify an explicit
> ordering otherwise.

Consistent with the above, +1

and as far as Wim's original question is concerned:

> Which style do you prefer?
> 
> .filter(last_name__startswith='b').order_by('last_name').first()# clear
> and long
> .first(last_name__startswith='b').order_by('last_name')# first method
> has filter syntax.
> .filter(last_name__startswith='b').first('last_name')   # first method has
> order_by syntax.

ordering is given by position, filtering by keyword arguments -- why not 
support both?

def first (self, *ordering, **filtering):
...

My only concern is one that Anssi raised -- the check for multiple objects is 
discarded, and there is no convenient way to get 0-or-1 objects (which is the 
semantics of the try-get-except-DoesNotExist-return-None pattern this is 
designed to replace). I don't think it has been given enough attention in the 
discussion so far.

One option -- with my suggested syntax -- is that if no ordering is given, 
then it means only one is expected (and, say, None could be used to say "use 
default ordering"). I suspect, though, that this might be a confusing (and 
conflated) interface.

Or maybe it can be saved by saying you must use one or the other but not both; 
then it's "overloaded", but nothing really surprising happens. This way, None 
could be used to say "No ordering -- there should be only one", which is even 
more intuitive. 

We get (semantically):

qset.first('last_name') ==> 
qset.order_by('last_name')[0] if qset.exists() else None

qset.first(None) ==>
qset.get() if qset,exists() else None

qset.first(last_name__startswith='b') ==>
qset.filter(last_name__startswith='b').first(None)

qset.first("last_name", last_name__startswith='b') ==>
raise TypeError("first() takes either all positional args or all keywords")

qset.first() ==>
qset.first(qset.model.ordering)

Note that with this suggestion:

qset.filter(a=b).first(c)

is not equivalent to

qset.order_by(c).filter(a=b)

Because the latter checks for multiple objects and the former doesn't; this. 
IMO, justifies raising a type-error when trying to use both.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Persistent connections, take 2

[Aymeric Augustin]

Hello,

I've integrated the feedback received on my initial proposal in a new pull 
request:
https://github.com/django/django/pull/733 and I think it's ready for review.

I'm just wondering if 10 minutes is a good default value for CONN_MAX_AGE.
I chose it randomly. Would "unlimited" be better?

Unfortunately, this code is difficult to test automatically, for two reasons:
- The testing framework needs a permanent database connection; it inhibits
  the closing of the connection triggered on request_started / request_finished.
- Database errors cannot be produced at will.

I've done some manual testing with gunicorn. Django recovers as expected
after a database restart, ie. one request fails and the next one succeeds.

Thanks for your feedback,

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: first() and last(), earliest() and latest()

[Aymeric Augustin]

On 27 févr. 2013, at 23:34, Wim Feijen  wrote:

> Therefore, my proposal is, if we are going to implement the earliest and 
> latest method, we should definitely rename them to: first and latest.

I believe that latest() was introduced with dates in mind, and then earliest() 
for consistency with latest().
Note that models also have a "get_latest_by" meta attribute defining the order 
if none is specified.

You're absolutely right: this feature is useful for any field with a meaningful 
order, and latest / earliest aren't an intuitive API.

I would support renaming them to first / last through a deprecation path. The 
new aliases would be available immediately, the old ones would be removed in 
two versions.

And while we're there, I suggest to rely on the existing "ordering" meta 
attribute and to remove "get_latest_by". I suspect that in many cases these two 
attributes have the same value, and you can specify an explicit ordering 
otherwise.

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [SPAM] Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

[Shai Berger]

Hi Florian,

On Wednesday 27 February 2013, Florian Apolloner wrote:
> Hi Shai,
> 
> On Tuesday, February 26, 2013 2:18:14 AM UTC+1, Shai Berger wrote:
> > > No, since the Oracle tests are somewhat slow we decided to just test
> > > one Python for now. I will try to see if Python 2 makes a difference,
> > > didn't yet think of it.
> > 
> > Cool.
> 
> They do work on python2!

Double cool!

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

first() and last(), earliest() and latest()

[Wim Feijen]

Hi all,

We struggled to get a proper definition for a first() and last() method vs. 
earliest() and latest() . I'd like to make one proposal. After that, I 
really like your opinion on which syntax you prefer.

First, let me give you a lenghty introduction. We discussed several use 
cases on this mailing 
list.
 
Then, I realized that:

.filter(last_name__startswith='b').order_by('last_name').first()
is an acceptable compromise for me to use in stead of:
.first(last_name__startswith='b').order_by('last_name')

Last weekend Aymeric explained to me that earliest can actually accomplish 
the same:
.filter(last_name__startswith='b').earliest('last_name')

Then, I find "earliest" an inappropriate name, because it does not describe 
functioning well.

Therefore, my proposal is, if we are going to implement the earliest and 
latest method, we should definitely rename them to: first and latest.

After that, there is only one question left:

Which style do you prefer?

.filter(last_name__startswith='b').order_by('last_name').first()# clear 
and long
.first(last_name__startswith='b').order_by('last_name')# first method 
has filter syntax.
.filter(last_name__startswith='b').first('last_name')   # first method has 
order_by syntax.

So, what do you think?

Best regards,

Wim

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving from PIL to Pillow

[Alex Ogier]

On Wed, Feb 27, 2013 at 4:42 PM, Aymeric Augustin
 wrote:
>
> On 27 févr. 2013, at 21:40, Marijonas Petrauskas  wrote:
>
> > Why isn't Pillow the recommended Django image library yet? PIL has
> > been unmaintained for almost 3 years and has a number of annoying bugs
> > (e.g. fails to open some valid JPEG files, maybe has some security
> > issues as well). Pillow, on the other hand, is a backwards-compatible
> > community-maintained fork, which has most of those issues fixed and
> > will even support Python 3 soon.
> >
> > I think this change would involve (1) running the test suite with
> > Pillow, (2) updating the documentation and (3) updating the ImageField
> > warning shown when PIL is not installed. Looks like an easy change.
> > What do you think?
>
>
> Yes, we'll have to choose a Python 3-compatible replacement for PIL.
>
> I've converted your email into a ticket: 
> https://code.djangoproject.com/ticket/19934
>
> I assume that Pillow and PIL are API-compatible. Django could fallback to PIL
> if Pillow isn't installed, to preserve backwards compatibility.
>
> --
> Aymeric


This seems like pretty much a no-brainer. PIL is a notoriously
backwards python package and more or less abandonware, and Pillow is a
well-supported fork.

As regards API-compatibility, Pillow is so much compatible that it
even installs to the same locations. Unless you manually check for it,
you shouldn't even notice that you are getting Pillow libraries
instead of PIL libraries. Which means that supporting pillow *should*
be as easy as Marijonas suggests, unless there actually are real
regressions. Just install it instead of or in addition to PIL when
testing, and update any documentation that refers to PIL and
ImageFields to recommend Pillow instead.

Best,
Alex Ogier

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecation of AUTH_PROFILE_MODULE

[Russell Keith-Magee]

On Thu, Feb 28, 2013 at 4:24 AM, Alper Çuğun  wrote:

>
> I looked into this today with 1.5 hitting and working on a project and
> this seemed relevant.
>
> On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote:
>
>> 1. A specification of the minimal useful interface for a User (perhaps
>>
>> in the form of an abstract base model?)
>>
> A User should not require a username. Usernames are a hideous remnant that
> are impossible to justify on consumer facing websites. Authentication on
> e-mail should be built-in if not the default.
>
>
A user *doesn't* require a username. It requires a unique identifying
field. However, by default, for historical reasons, the Django's built-in
User model has a username field. The whole point of the new feature is that
specifying an alternative is now a simple activity.

> 4. A migration path that meets our backwards-compatibility standards.
>>
> I saw the configurable User model that just landed in 1.5 but for a
> non-library developer this is not very useful. It looks like a very large
> amount of code for a rather small function.
>

It's not clear what you're suggesting here. Django has a built in User
model. That hasn't changed. You can now specify your own User model, and
reuse large parts of Django's built in parts if that is helpful in your
circumstances. What exactly is your concern here?


> Furthermore: “If you intend to set 
> AUTH_USER_MODEL,
> you should set it before running manage.py syncdb for the first time.” is
> somewhat prohibitive to existing projects. “you may need to look into
> using a migration tool like South  to ease
> the transition.” is not really a solution unless it is obvious what
> changes should be made.
>

Well, this is a situation where we can't provide documentation, because
everyone's specific circumstances will be different. The best advice for
custom user models is "set it before you run syncdb", which is what we've
said. If you've already run syncdb, you'll need to migrate your models… but
exactly what that entails will entirely depend on what your own project has
done.


> Also I don't understand: “This example illustrates how most of the
> components work together, but is not intended to be copied directly into
> projects for production use.” Code that is ready for production is the
> point of the documentation for me. If this isn't, I think it's a
> documentation bug.
>

The point of that comment is that you shouldn't treat the documentation as
a cargo-cult, just copying and pasting. What is there will *work*. However,
in a real application, you need to pay attention to error messages,
validation conditions and so on.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Moving from PIL to Pillow

[Aymeric Augustin]

On 27 févr. 2013, at 21:40, Marijonas Petrauskas  wrote:

> Why isn't Pillow the recommended Django image library yet? PIL has
> been unmaintained for almost 3 years and has a number of annoying bugs
> (e.g. fails to open some valid JPEG files, maybe has some security
> issues as well). Pillow, on the other hand, is a backwards-compatible
> community-maintained fork, which has most of those issues fixed and
> will even support Python 3 soon.
> 
> I think this change would involve (1) running the test suite with
> Pillow, (2) updating the documentation and (3) updating the ImageField
> warning shown when PIL is not installed. Looks like an easy change.
> What do you think?


Yes, we'll have to choose a Python 3-compatible replacement for PIL.

I've converted your email into a ticket: 
https://code.djangoproject.com/ticket/19934

I assume that Pillow and PIL are API-compatible. Django could fallback to PIL
if Pillow isn't installed, to preserve backwards compatibility.

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Decision needed on formfield_callback

[Shai Berger]

On Wednesday 27 February 2013, poswald wrote:
> I'm wondering if we can open a quick discussion on the `formfield_callback`
> method of django ModelForms..
> 
> The basic issue boils down to the fact that we have an undocumented (and
> thus unsupported) method on ModelForm that would benefit greatly from a
> small change in behavior and an official blessing in the form of some
> documentation:
> 
> https://code.djangoproject.com/ticket/12915
> 
> This would be very helpful to developers who want to ensure that all of the
> model forms extending their form get a certain overridden field, or for a
> project like django-floppyforms. In the ticket Russ mentions not being 100%
> happy with the patches. Is there a better way to define the standard field
> type to use for a given type?

I took a glance, and it seems like the formfield_callback belongs in the opts 
object (and the Meta inner class), not the form class itself.

My 2 cents,

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: DjangoCon Europe tickets on sale today!

[Reinout van Rees]

On 27-02-13 21:21, Andre Terra wrote:

I wonder if these will ever be made available online for a fee, even if
months after the conference. For a hobbyist developer like me, coughing
up a few thousand dollars for the tickets, registration and hotel is
just impossible, but I would be glad to pay to have access to the
knowledge being shared there.


For most Python (and thus Django) conferences, the talks are assumed to 
be available online after a couple of weeks or months. The best site to 
look at is pyvideo: http://pyvideo.org/


http://pyvideo.org/search?models=videos.video=djangocon

Hm. I notice that the djangocon.eu videos aren't there. 2011's are here: 
http://blip.tv/djangocon-europe-2011

2012's can be downloaded.
You probably can google around for the rest.



Reinout

--
Reinout van Reeshttp://reinout.vanrees.org/
rein...@vanrees.org http://www.nelen-schuurmans.nl/
"If you're not sure what to do, make something. -- Paul Graham"

--
You received this message because you are subscribed to the Google Groups "Django 
developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Moving from PIL to Pillow

[Marijonas Petrauskas]

Hi all,

Why isn't Pillow the recommended Django image library yet? PIL has
been unmaintained for almost 3 years and has a number of annoying bugs
(e.g. fails to open some valid JPEG files, maybe has some security
issues as well). Pillow, on the other hand, is a backwards-compatible
community-maintained fork, which has most of those issues fixed and
will even support Python 3 soon.

I think this change would involve (1) running the test suite with
Pillow, (2) updating the documentation and (3) updating the ImageField
warning shown when PIL is not installed. Looks like an easy change.
What do you think?

Thanks,
-- Marijonas

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: deprecation of AUTH_PROFILE_MODULE

[Alper Çuğun]

I looked into this today with 1.5 hitting and working on a project and this 
seemed relevant.

On Monday, 2 May 2011 19:22:53 UTC+2, Carl Meyer wrote:

> 1. A specification of the minimal useful interface for a User (perhaps
>
> in the form of an abstract base model?) 
>
A User should not require a username. Usernames are a hideous remnant that 
are impossible to justify on consumer facing websites. Authentication on 
e-mail should be built-in if not the default.
 

> 4. A migration path that meets our backwards-compatibility standards.
>
I saw the configurable User model that just landed in 1.5 but for a 
non-library developer this is not very useful. It looks like a very large 
amount of code for a rather small function.

Furthermore: “If you intend to set 
AUTH_USER_MODEL,
 
you should set it before running manage.py syncdb for the first time.” is 
somewhat prohibitive to existing projects. “you may need to look into using 
a migration tool like South  to ease the 
transition.” is not really a solution unless it is obvious what changes 
should be made.

Also I don't understand: “This example illustrates how most of the 
components work together, but is not intended to be copied directly into 
projects for production use.” Code that is ready for production is the 
point of the documentation for me. If this isn't, I think it's a 
documentation bug.

Best,
Alper

>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: DjangoCon Europe tickets on sale today!

[Andre Terra]

I just wanted to say that the list of talks & speakers is the best I've
seen to date. I really wish I could go see it, but unfortunately Warsaw is
too far for me.

I wonder if these will ever be made available online for a fee, even if
months after the conference. For a hobbyist developer like me, coughing up
a few thousand dollars for the tickets, registration and hotel is just
impossible, but I would be glad to pay to have access to the knowledge
being shared there.

In any case, have fun and happy coding, everyone!


Cheers,
AT

On Wed, Feb 27, 2013 at 8:02 AM, Ola Sitarska  wrote:

> Hi everyone!
>
> I'm Ola, one of the main organizers of upcoming DjangoCon Europe
> conference. I just wanted to let you know that we're starting to sell
> regular tickets to the conference today at 4pm CET prompt! Tickets are
> available here: http://tickets.djangocon.eu/
>
> We have also recently announced venue ,
> schedule , 
> talks
>  and speakers . We would love to hear
> you thoughts and ideas for DjangoCon -- please, let us know what we can
> improve to make this event ever more awesome :)
>
> Really looking forward to meet you in Warsaw!
>
> --
> Ola Sitarska
> http://2013.djangocon.eu/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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?hl=en
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [SPAM] Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

[Florian Apolloner]

Hi Shai,

On Tuesday, February 26, 2013 2:18:14 AM UTC+1, Shai Berger wrote:
>
> > No, since the Oracle tests are somewhat slow we decided to just test one 
> > Python for now. I will try to see if Python 2 makes a difference, didn't 
> > yet think of it. 
> > 
>
> Cool. 
>

They do work on python2! 
http://ci.djangoproject.com/job/Django%20Oracle/database=oracle,python=python2.7/13/
  
A few failures, but most of them are probably real ;)

Either way, I am happy for today…

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

DjangoCon Europe tickets on sale today!

[Ola Sitarska]

Hi everyone! 

I'm Ola, one of the main organizers of upcoming DjangoCon Europe 
conference. I just wanted to let you know that we're starting to sell 
regular tickets to the conference today at 4pm CET prompt! Tickets are 
available here: http://tickets.djangocon.eu/

We have also recently announced venue , 
schedule , 
talks
 and speakers . We would love to hear 
you thoughts and ideas for DjangoCon -- please, let us know what we can 
improve to make this event ever more awesome :) 

Really looking forward to meet you in Warsaw!

--
Ola Sitarska
http://2013.djangocon.eu/

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How can we Commit request.FILES using pysvn in Django?

[zalew]

This is a group for discussing development of the framework. Please post 
your support questions to django-users.

On Tuesday, February 26, 2013 7:57:24 AM UTC+1, abdul wrote:
>
> I have to commit files from request.FILES to svn repository usiong pysvn 
> but when i try like this
>
> import pysvn
> client = pysvn.Client("Repo_url")
> file = request.FILES.get('file', None)
> *client.add(file)*
> *
> *
> *TypeError: PyCXX: Error creating object of type N2Py7SeqBaseINS_4CharEEE 
> from 
> *
> *
> *
> *Please help me out.*
> *
> *
> *Regards,*
> *Abdul Wahid*
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Decision needed on formfield_callback

[poswald]

I'm wondering if we can open a quick discussion on the `formfield_callback` 
method 
of django ModelForms..

The basic issue boils down to the fact that we have an undocumented (and 
thus unsupported) method on ModelForm that would benefit greatly from a 
small change in behavior and an official blessing in the form of some 
documentation:

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

This would be very helpful to developers who want to ensure that all of the 
model forms extending their form get a certain overridden field, or for a 
project like django-floppyforms. In the ticket Russ mentions not being 100% 
happy with the patches. Is there a better way to define the standard field 
type to use for a given type? I'm wondering if we can discuss what we would 
like to see changed in that code to make it acceptable for a merge...

Thanks!
-Paul

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.