I just created a ticket (http://code.djangoproject.com/ticket/7617) to
allow a subclass of ModelFormMetaclass to inherit from a mixin, too.
One of the changes in my patch is to always use super(...,
cls).__new__ to chain up.
A grep over the django code base finds other metaclasses that directly
c
TO DOWN THE COOL TRISHA!! IMAGES!!!
TO DOWNLOAD THE KUSALAN AND IMAGES ON RASIYA, MUMTHAJ,STEYA,.
TO THE COMEDY IN THE NEW FILM AND THE THEME OF THE STORIES AND TALIORS
OF
NEW FILM ON HINDI ALSO.
SO WANT MORE!!!
CLICK MY PROFILE!!
***
Naruto 407
Naruto 407, One Piece 506, Bleach 329 Hot manga Download
The hottest mangas and the latest chapters
Manga news, Most popular mangas, Latest mangas, Latest chapters
http://english1.isoshu.com/?recommid=1023
http://emanga1.isoshu.com/?recommid=1023
--~--~-~--~~--
On Wednesday 02 July 2008 16:48:53 Paul Kenjora wrote:
> I've been using Django for a while and recently started
> contributing to the trunk. Previously I ran my own branch but
> sooner or later that gets tiresome. So I created a ticket the
> other day:
>
> http://code.djangoproject.com/ticket/7
On Thu, 2008-07-03 at 02:06 -0700, Christian wrote:
[...]
> Should I send in patches for django.db.models.ModelBase,
> django.newforms.DeclarativeFieldsMetaclass, and
> django.newforms.MediaDefiningClass?
Sounds like a reasonable idea. Make patches against the right branches,
though, please. Dec
Ticket with patch is open at http://code.djangoproject.com/ticket/7619
2008/7/2 Justin Bronn <[EMAIL PROTECTED]>:
>
> > I could clean this up as a patch to the GIS branch, but there seems to
> > be some confusion as to whether such functionality should be in the
> > core product.
> >
> > What is
Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-07-03 at 02:06 -0700, Christian wrote:
> [...]
> > Should I send in patches for django.db.models.ModelBase,
> > django.newforms.DeclarativeFieldsMetaclass, and
> > django.newforms.MediaDefiningClass?
>
> Sounds like a reasonable idea.
On Thu, 2008-07-03 at 14:56 +0200, Christian Tanzer wrote:
[...]
> I'd propose to write that check as
>
> parents = [b for b in bases if isinstance(b, ModelBase)]
> if parents:
> return super(ModelBase, cls).__new__ (cls, name, bases, attrs)
> ...
>
> Simpler
Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-07-03 at 14:56 +0200, Christian Tanzer wrote:
> [...]
> > I'd propose to write that check as
> >
> > parents = [b for b in bases if isinstance(b, ModelBase)]
> > if parents:
> > return super(ModelBase, cls).
I would like to remind those out there setting milestones on tickets to
follow the following guidelines that Jacob put forth:
* Must-have feature bugs go in the "1.0 alpha" milestone. These
basically should be all nfa-blocker tickets. Bugs in the must-have
features are not to be part of thi
random person: "i need help"
magus: gives technical answer
random person: does understand python
magus: points to docs
random person: you are rude
On Jul 2, 11:38 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 2, 2008 at 7:17 AM, Arien <[EMAIL PROTECTED]> wrote:
>
> > Can we get back
> I would like to stress the point that features not on the list are not
> to be put in any 1.0 milestone. For those working on tickets for
> features or enhancements that are not on the list, please understand
> that these are lower priority than vetted features and *all* bugs. If
> you really
On Thu, Jul 3, 2008 at 9:26 AM, phillc <[EMAIL PROTECTED]> wrote:
>
> random person: "i need help"
> magus: gives technical answer
> random person: does understand python
> magus: points to docs
> random person: you are rude
1) Let's stop referring to specific people, mmkay? I made that
mistake,
On Thu, Jul 3, 2008 at 9:26 AM, Jannis Leidel <[EMAIL PROTECTED]> wrote:
>> Even if these sorts of features have a patch and are "Ready for checkin,"
>> that does not mean they get a 1.0 milestone. They still take core
>> developer time to review and commit, time that also needs to be
>> focused
The docs say '.chunks()' , which makes more sense to me, but the code
says '.chunk()' (2 * for implementation, 1 * used)
It's not too late to fix the code, otherwise the docs need changing.
Luke
--
"Ineptitude: If you can't learn to do something well, learn to enjoy
doing it poorly." (desp
We have a proprietary Client Screening and management software program
created in Django and Python.
We are an adult industry service company.
Our designer has moved on and we're looking for a young mind to not
only continue work but take it in a new direction.
It's currently running on sliceho
On Thu, Jul 3, 2008 at 11:08 AM, Luke Plant <[EMAIL PROTECTED]> wrote:
> The docs say '.chunks()' , which makes more sense to me, but the code
> says '.chunk()' (2 * for implementation, 1 * used)
>
> It's not too late to fix the code, otherwise the docs need changing.
I just talked about this wi
Hi Lee --
This is the wrong place for this kind of post; please take it to
django-users -- or, better yet, http://djangogigs.com/
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
On Thu, Jul 3, 2008 at 9:26 AM, Jannis Leidel <[EMAIL PROTECTED]> wrote:
> Just out of curiosity, could we fix that bottleneck by appointing more
> developers to be core developers?
As with many things, the process of becoming a committer is documented
in our contributing document
(http://www.dja
On Thu, Jul 3, 2008 at 12:22 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> I just talked about this with Mike on IRC; I think chunk() is
> non-obvious and we're gonna change it to chunks(). Hopefully nobody's
> written so much code in the last week to be pissed.
>
> Also, we're going to chang
> As with many things, the process of becoming a committer is documented
> in our contributing document
> (http://www.djangoproject.com/documentation/contributing/#commit-access
> ):
>
> [...]
>
> To request commit access, please contact an existing committer
> privately. Public requests for comm
On Thu, Jul 3, 2008 at 12:03 PM, Marty Alchin <[EMAIL PROTECTED]> wrote:
> Well, as long as the floor's open, I'd like to make sure file storage
> code is consistent. Currently, it uses filename instead of file_name
> or just name, and it also uses size instead of file_size. I assume I
> should go
you can like this where much hot models hot video hot
pictures
**
http://anushkahollywood.blogspot.com/
*
--~--~-~--~~~---~--~~
You received this message because you are subscrib
Hi all!,
I've posted a patch[1] with a small refactor to some Field's
get_db_prep_* methods. Basically, for non-basic field types, the
database-prepared values is not computed by the Fields anymore, but
delegated to DatabaseOperations functions. As the current default
logic was copied to the defa
Thanks for your answer all!
I really appreciate it!
In the meantime, I have thought of the following ugly but simple
solution. A comma (or whatever character) seperated list of primary
keys in a CharField can hold the values in the order needed. Now the
only thing I need is a widget that generat
I found the ticket for this strange behaviour of QueryDict, which
meant I wasn't alone having a problem with it -
http://code.djangoproject.com/ticket/7331,
and submited a patch.
It's actually MultiValueDict that is the cause, but let's clarify
things a little, first.
Consider this scenario:
>
> The only thing that might be worth doing in this are is adding a way to
> say "middleware should never be called on this response" and then
> somebody can write their own HttpResponse subclass and be in complete
> control of their destiny.
Would this disable ALL middleware from running? Or only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jul 4, 2008, at 00:45, Jure Vrscaj wrote:
> Could this be fixed in 1.0? It breaks compatibility, I know.
Although I'm not in any kind of position of making such a decision, I
can make an educated guess: no. The reason is that most developers
On Fri, Jul 4, 2008 at 4:57 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>
> Hi all!,
>
> I've posted a patch[1] with a small refactor to some Field's
> get_db_prep_* methods. Basically, for non-basic field types, the
> database-prepared values is not computed by the Fields anymore, but
Hi Leo,
I'
On Thu, Jul 3, 2008 at 8:27 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 4, 2008 at 4:57 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>>
>> Hi all!,
>>
>> I've posted a patch[1] with a small refactor to some Field's
>> get_db_prep_* methods. Basically, for non-basic field types
On Thu, 2008-07-03 at 16:57 -0400, Leo Soto M. wrote:
> Hi all!,
>
> I've posted a patch[1] with a small refactor to some Field's
> get_db_prep_* methods. Basically, for non-basic field types, the
> database-prepared values is not computed by the Fields anymore, but
> delegated to DatabaseOperat
On Thu, Jul 3, 2008 at 10:36 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
> I've also read through the patch already and it seems like the right
> track. I like the approach, since it helps in a few areas, including
> field extensions and extra database backends.
>
> I haven't given it a comp
On Fri, 2008-07-04 at 01:54 +0200, Ludvig Ericson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Jul 4, 2008, at 00:45, Jure Vrscaj wrote:
>
> > Could this be fixed in 1.0? It breaks compatibility, I know.
>
>
> Although I'm not in any kind of position of making such a decisi
33 matches
Mail list logo
