An opportunity for Django community

[Mike Scott]

I've watched the video of the keynote speech, and the following struck me as
an "opportunity for django".

Ala the speech given.

http://www.google.com/buzz/ianbicking/BRWDjsMCGWQ/I-like-the-original-proposal-move-PyPI-stuff-into#127681396096


Thoughts?

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: High Level Discussion about the Future of Django

[Mike Scott]

I agree almost whole-heartedly with the perception that David
portrays. His feelings almost mirror mine. Albeit I haven't submitted
contributions to the django development process I've been involved
with a number of issues and come away with similar feelings viewing
the process.

I love what those who do contribute do, and I whole-heartedly stand
behind the ideals that the core team produce, but I do feel that the
"community" aspect of django is slipping.

On Apr 19, 11:10 am, David Cramer  wrote:
> I just want to throw my 2 cents into the ring here. I'm not against a
> fork, but at the same time I want to see the Django mainline progress.
> However, let me tell you my story, and how I've seen the Django
> development process over the years.
>
> I started with Django 4 years ago. It was cool, shiny, and let us get
> up and running. At the time, were were one of the largest Django
> installations. We had needs, and some of those needs were met.
> However, many were not. We were the only ones furiously trying to get
> the core team to accept our patches, ideas, etc.. Now while I'm not
> going to say every idea we had was right for Django, there were in
> fact many that were great, and eventually have made it into trunk.
> There are also still many (lets take the classic #17 here), that still
> haven't made it into trunk, even though people have been even more
> aggressively pushing them lately. I honestly can only remember a
> single patch that I've committed that has ever been fully integrated
> into trunk (select_related refactor).
>
> Now, the development process has changed with Django over the years,
> but I will sadly say that I feel it's been for the worst. I've
> completely given up on trac, submitting patches, or even
> participating. Now while some may not like my aggressive tacts (e.g.
> James) that doesn't mean what I've brought to the table hasn't been
> needed. For the last year or two all I've seen on the trac whenever I
> took up the time to write a patch, or even submit a ticket, was a
> closure of "wontfix" for some, honestly, stupid reason. It just isnt
> worth my time to submit the same ticket 3 times just so its "correct",
> or it fits everyones needs. Tickets are not patches, and they
> shouldn't be treated like "if this one isnt accepted, create a new
> one".
>
> I think there's a split within the Django core team right now and I
> strongly believe that unless you can tirelessly convince a core
> developer (no matter how large the following), a feature is not going
> to make it into mainline. This to me is a serious issue when you're
> talking about an open source, community contributed project. Sure, the
> core team does a large amount of the work, but not without help from
> the community. I'll take this back to my old analogy, not everyone is
> building a blog, and if they are, they can go use WordPress. Many,
> many things have gone ignored for far too long. I love Malcom's ORM
> refactor, but that was at a standstill for I don't know how long, and
> that entire time any patch which was related to improvements to the
> ORM was ignored simply stating "we're working on a refactor of the
> ORM". This philosophy seems to continue still today.
>
> Just recently there was a post about "High Level Talk About
> Django" (or whatever it was called). Now while the thread didn't make
> a whole lot of sense in general, it was just an attempt to gather some
> ideas, and brainstorm. Immediately it was shut down by the core
> developers.
>
> What frustrates me even more is all of this pony talk. If there's one
> thing I dislike it's Django's philosophy that "if it can be done 3rd
> party, do it", yet even the simplest things, like the template engine,
> have better 3rd party implementations (Jinja2). Django still doesn't
> have migrations. It still doesn't have dependancies. It's seriously
> lacking in many areas which other (albeit lesser) alternatives such as
> Rails have made available for far too long. Now while there's great
> 3rd party apps for things like this (South), and there's a few
> mediocre sites to find pieces of code (Django Snippets), this doesn't
> solve the problem which is really going on in Django: The community
> cant contribute beyond what the core team deems necessary.
>
> For me, I've entirely given up on trying to give back to Django. I've
> written enormous amounts of questionable code simply so I didn't have
> to patch Django, or even bother dealing w/ the process of Django's
> development. Monkey patching, ugly metaclass hacks, you name it.
> Anything that's made it easier to avoid this "process", has made it
> easier for us to develop. I continue to build these "ponies", but that
> doesn't make them any easier to integrate in Django.
>
> All in all, I think some things have been ignored for far too long.
> Simple things, again, like migrations, JSON and RESTful utilities, and
> even the tools to make development easier (the debug toolbar hasn't
> 

Re: RequestContext rarely used (branched from Feature reviews for 1.1)

[Mike Scott]

For all three of our projects in django, we've gone through and used our own
exended version of render_to_response, which uses RequestContext by default.
Its such a blessing.

On Tue, Nov 18, 2008 at 7:42 PM, James Bennett <[EMAIL PROTECTED]>wrote:

>
> On Tue, Nov 18, 2008 at 12:04 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> > I'm always wondeing how it's possible that Django creators don't use
> > django in ways that are written in django documentation. That leads to
> > misunderstanding in expectations, and should explain why some tickets
> > don't get expected resolutions.
>
> Adrian may not use it, but I certainly do, as do plenty of other folks
> I know. Which means, I guess, that it's time for you to maybe stop
> making sweeping generalizations and jumping to conclusions about
> tickets based on someone simply saying he does or doesn't use some
> particular feature a lot.
>
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django documentation index redesigned

[Mike Scott]

+1!

Just one suggestion - if the final "bateries included" could be split into
contrib apps, and core library that'd be nicer.

On Tue, Nov 18, 2008 at 8:44 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:

>
> After months of being frustrated (and hearing other people being
> frustrated) with our newish documentation index, I took some time
> tonight to reorganize the links, to make it easier and faster to find
> things. Take a look here:
>
> http://docs.djangoproject.com/en/dev/
>
> I opted for a much more compact approach, with related links
> side-by-side. The previous version tended to organize each link based
> on whether it was reference vs. an overview, but this new version
> organizes by topic, instead.
>
> The "Other batteries included" section is kind of a cop out. It's a
> bit past my bedtime, so that's all I could come up with in a hurry.
>
> Hope people find this easier and faster to use!
>
> Adrian
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: auto_now_add and auto_now

[Mike Scott]

Thierry,

Firstly django-developers is not the place for this discussion.

Secondly this question has been asked, and solved many times. If you search
through the django-users archives I'm sure you'll find plenty of solutions.
There are solutions out and about in the blogosphere too.

Cheers,


Mike.

On Mon, Oct 13, 2008 at 10:07 PM, Thierry Stiegler <
[EMAIL PROTECTED]> wrote:

>
> Hi,
>
> I have a lot of models using this type of fields :
> 
>creation = models.DateTimeField(auto_now_add=True)
>update = models.DateTimeField(auto_now=True)
> 
>
> But I read that since 2007, it was planned to drop those options from
> models.DateField.
>
> Here the post :
> http://groups.google.com/group/django-developers/browse_thread/thread/4cd631c225cb4e52
>
> So what I have to do ? New custom fields ?
>
> I saw some tickets but I didn't find a nice substitute...
>
> Any suggestions ?
>
> Yours,
>
> Thierry.
>
>
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django model version control

[Mike Scott]

Please move this conversation to django-users. Django-developers is for the
discussion pertaining to the maintenance and development of the django
framework itself.

On Thu, Oct 2, 2008 at 3:55 AM, Erik Allik <[EMAIL PROTECTED]> wrote:

>
> Nevermind the previous e-mail.
>
> On 01.10.2008, at 17:10, David Hall wrote:
>
> >
> > I've just released an open-source version control application for
> > Django.  It is available for download from Google code.
> >
> > http://code.google.com/p/django-reversion/
> >
> > Features include:
> >
> >  - Roll back to any point in a model's history - an unlimited undo
> > facility!
> >  - Recover deleted models - never lose data again!
> >  - Admin integration for maximum usability.
> >  - Group related changes into revisions that can be rolled back in a
> > single transaction.
> >  - Automatically save a new version whenever your model changes using
> > Django's flexible signalling framework.
> >  - Automate your revision management with easy-to-use middleware.
> >
> > It can be easily added to your existing Django project with an
> > absolute minimum of code changes.
> >
> > It's so far been previewed by a half dozen developers, with good
> > feedback.  I'd appreciate any comments / suggestions you may have to
> > offer.
> >
> > >
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Announcements regarding djangocon video's availability

[Mike Scott]

Hi Guys,

I wasn't sure where/who to get in touch with regarding this but I was hoping
that on both the djangocon and django blog websites announcements could be
made to the effect of announcing the availability of the djangocon videos
from google now on youtube. I think it would be great to let everyone know,
particularly as it slipt through my tracking cracks.

Cheers,


Mike.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: ANNOUNCE: Django 1.0 released

[Mike Scott]

Congratulations!!

Was wondering if you could get a hold of adrian and get him to update the
python packages stuff to the latest version?

Otherwise looking good! :)

On Thu, Sep 4, 2008 at 12:07 PM, James Bennett <[EMAIL PROTECTED]>wrote:

>
> The Django team is pleased to announce the release of Django 1.0 this
> evening:
>
> Download: http://www.djangoproject.com/download/
> Release notes: http://docs.djangoproject.com/en/dev/releases/1.0/
>
> Have fun with it, and we'll see you in a few days for DjangoCon.
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: DjangoCon meetup Friday Sept 5

[Mike Scott]

err, link doesn't seem to work with www for me, so try:

http://thisweekindjango.com/

On Thu, Aug 21, 2008 at 9:01 PM, Mike Scott <[EMAIL PROTECTED]> wrote:

>
>
> On Thu, Aug 21, 2008 at 7:54 PM, Jonathan Nelson <[EMAIL PROTECTED]>wrote:
>
>>
>> TWID guys?  I'd be happy to combine groups.  I just don't know who
>> that is.
>>
>
> "This week in django" crew - http://www.thisweekindjango.com/ only the
> premier podcast resource for django-aholics.
>
> Get in touch with one of them, contacts details are available on said
> website.
>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: DjangoCon meetup Friday Sept 5

[Mike Scott]

On Thu, Aug 21, 2008 at 7:54 PM, Jonathan Nelson <[EMAIL PROTECTED]>wrote:

>
> TWID guys?  I'd be happy to combine groups.  I just don't know who
> that is.
>

"This week in django" crew - http://www.thisweekindjango.com/ only the
premier podcast resource for django-aholics.

Get in touch with one of them, contacts details are available on said
website.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Renaming of mailing lists to avoid user confusion

[Mike Scott]

On Wed, Aug 20, 2008 at 12:37 AM, Simon Willison <[EMAIL PROTECTED]>wrote:

>
> On Aug 19, 1:39 am, "Tom Tobin" <[EMAIL PROTECTED]> wrote:
> > (And you know, I still think we'd be better off with
> > "django-YES-THIS-ONE" and "django-NO-THE-OTHER-ONE".  Or perhaps a tad
> > more seriously, something like "django-community" and "django-core" —
> > otherwise we'll be fighting this battle forever.)
>
> django-internals sounds good to me, though I've used up all of my
> capital already as far as renaming things is concerned ;)
>
>
I'm definately +1 on the idea. Also moving this to a seperate thread to
raise awareness.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: MySQL BINARY WHERE Clauses

[Mike Scott]

David,

We know you know the difference, but you should also know how much we
love detail. More detail is also needed here.



On Tue, Jul 22, 2008 at 6:29 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> I don't want to seem harsh Karen, but I understand the differences in the
> user lists. This is not an issue with how I'm using Django, it's an issue
> with what Django's doing. This may be better suited as a ticket, but I'd
> rather not end up with another trac ticket that emails me daily because it
> turns into a discussion on how it should work.
>
> In summary, this is, in fact, a problem in the Django codebase, and need's
> addressed, as it's causing issues for myself, and probably a number of other
> people, even if they haven't realized it yet.
>
> On Tue, Jul 22, 2008 at 1:25 AM, Karen Tracey <[EMAIL PROTECTED]> wrote:
>>
>> On Tue, Jul 22, 2008 at 2:13 AM, David Cramer <[EMAIL PROTECTED]> wrote:
>>>
>>> I was using utf8_general. I'm swapping to utf8_bin to attempt to fix
>>> it, but binary encodings cause problems as well with unique indexes or
>>> something similar (can't remember what my test case was from Curse).
>>>
>>> On Jul 22, 12:59 am, David Cramer <[EMAIL PROTECTED]> wrote:
>>> > SELECT * FROM `spider_discoveredlink` WHERE
>>> > `spider_discoveredlink`.`url` = BINARY 'http://www.starcraft.org/maps/
>>> > scums/multiplayerums/multiplayerrpg/Shinhwa+2008';
>>> >
>>> > is NOT the same as
>>> >
>>> > SELECT * FROM `spider_discoveredlink` WHERE
>>> > `spider_discoveredlink`.`url` = 'http://www.starcraft.org/maps/scums/
>>> > multiplayerums/multiplayerrpg/Shinhwa+2008';
>>> >
>>> > Just FYI, you are breaking all of my queries :)
>>
>> This topic would seem better suited to django-users, since you are not
>> discussing developing django, but using it.  You are also not really
>> providing enough information to help you.  I do not know which of those
>> queries you actually want, what Django lookup methods you have tried to
>> achieve the results you are looking for, etc.  If you follow up on
>> django-users with specifics of what Django code you are running, what
>> results you were hoping for and what you are seeing instead, someone might
>> be able to suggest something.
>>
>> Karen
>>
>>
>>
>
>
>
> --
> David Cramer
> Director of Technology
> iBegin
> http://www.ibegin.com/
> >
>



-- 
James Thurber  - "Women are wiser than men because they know less and
understand more."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Spam detection

[Mike Scott]

Jacob,

I think its the fact that we see "internal server error" and just miss
the message which is very nicely hidden after it.

Alot of django developers know what a 500 means, but generally don't
expect to see it for a spam block.

Maybe the page after the block submission needs to be changed. And
maybe you could output a copy of the submitted text too just incase
you didn't have a copy written elsewhere.

On Fri, Jun 27, 2008 at 8:59 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 26, 2008 at 4:34 PM, Marc Fargas <[EMAIL PROTECTED]> wrote:
>> El jue, 26-06-2008 a las 13:31 -0700, Jacob Kaplan-Moss escribió:
>>> Help me out here: how can I make it more obvious? You missed that;
>>> others often do to. Can you share with me some insights on how you
>>> missed it?
>>
>> The sentence should be more prominent, I know nobody that will read that
>> many lines, so maybe bolding "spam" and "register for an account" would
>> make those a bit more visible.
>
> Yeah, it does kind of get lost in the text there. The first few lines
> basically say "be sure you actually have an unreported bug."
> Presumably, the potential reporter thinks: "Yeah, Yeah, I've been
> through that before so why should I read every point in that list
> carefully?"
>
> True, first time reporters to any project probably should read that,
> but obviously they don't. Personally, I alway look for a "register"
> link in the menu - usually in close proximity to the "Login" link. I'd
> suggest (and have in the past) that a "Register" link be added to
> every Trac page right next to the "Login" and "Settings" links up in
> the top right corner.
>
> If that doesn't work - then perhaps a dancing animation across the
> newticket page. Ok, maybe not. :-D
>
>
> --
> 
> Waylan Limberg
> [EMAIL PROTECTED]
>
> >
>



-- 
Woody Allen  - "I am not afraid of death, I just don't want to be
there when it happens."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Ordered ManyToMany

[Mike Scott]

Could this not be further discussed?

I understand the need to be toolkit agnostic, but could we not take a
similar approach as the Ext js framework, where by you can use one of
many existing frameworks as your base. Then the django community can
build connectors as demanded.

I understand there are some complexities involved, but essentially its
just creating a uniform javascript API to use - not unlike the may we
have a uniform database api.



On Fri, Jun 27, 2008 at 1:50 AM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
>
> On Thu, Jun 26, 2008 at 3:41 PM, OliverMarchand
> <[EMAIL PROTECTED]> wrote:
>> === Form Field/Widget ===
>>
>> The normal ChoiceField has no ordering. I am no Javascript expert, but
>> I think it is very simple to write a widget where the selected choices
>> can also be ordered. Assuming that the chosen parameters appear in the
>> specified order in the GET or POST prtocol, the order can be retrieved
>> from the server.
>
> This requires JS and is pretty tied to *your* toolkit of choice. As
> most sites already rely on one of the toolkits, Django can't depend on
> any of them (at least outside of default admin templates) and
> providing lengthy DOM-based widgets is a waste of time (as the site
> will likely have to replace them with themed and toolkit-powered
> ones). This falls outside of Django's scope.
>
> If you need ordered lists, create models that include a sorting field.
>
>> === ManyToMany Fields ===
>>
>> The above would be very useful for values stored in the database as
>> well. It would be nice to have an OrderedManyToMany Field. That would
>> assume that the intermediate table for a a many-to-many relationship
>> would also have a column for storing the order. One could use the id
>> column of the intermediate table. Do you agree that it could be very
>> simple to write an OrderedManyToMany Field, but simply adding the up/
>> down feature to the widget?
>
> See above, use an explicit connecting model for many-to-many relations
> and add tour sorting fields there.
>
> --
> Patryk Zawadzki
> PLD Linux Distribution
>
> >
>



-- 
Jonathan Swift  - "May you live every day of your life."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

[Mike Scott]

Ahh my greatest apologies - not expected behaviour, nor compliant behavour.

Teach me for skim reading.

On Thu, Jun 5, 2008 at 11:31 AM, Jeff Anderson <[EMAIL PROTECTED]>
wrote:

> Mike Scott wrote:
>
>> Marty:
>>
>> If you read his post you'll see he is infact getting a 500 Server error,
>> and
>> not a spam filter error. 500 Server errors happen when something goes
>> wrong,
>> not when spam is filtered.
>>
>>
> The way that this ticket system is set up, you do indeed get a 500 Server
> error when you are marked as spam; pasted:
>
> Internal Server Error
> 500 Internal Server Error (Submission rejected as potential spam (Akismet
> says content is spam))
> TracGuide — The Trac User and Administration Guide
>
> This is re-creatable by simply being anonymous (clear your cookies, or use
> a different browser!) and attempting to post a ticket.
>
>
> Jeff Anderson
>
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Improving the truncatewords filter (and a +1 vote for filters with multiple arguments)

[Mike Scott]

Marty:

If you read his post you'll see he is infact getting a 500 Server error, and
not a spam filter error. 500 Server errors happen when something goes wrong,
not when spam is filtered.

On Thu, Jun 5, 2008 at 5:40 AM, Marty Alchin <[EMAIL PROTECTED]> wrote:

>
> On Wed, Jun 4, 2008 at 1:21 PM, Aral Balkan <[EMAIL PROTECTED]> wrote:
> > Unfortunately, I don't think your ticketing system likes me. I'm
> > getting: 500 Internal Server Error (Submission rejected as potential
> > spam).
>
> Right on the new ticket screen, under the big heading labeled "Read
> this first" you'll find the following line:
>
> "If you're getting rejected by the spam filter, we apologize! The best
> way to avoid that is to register for an account and make sure you're
> logged in."
>
> -Gul
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Multiple database support

[Mike Scott]

On Fri, May 23, 2008 at 2:59 AM, Simon Willison <[EMAIL PROTECTED]>
wrote:

> 1. Replication - being able to send all of my writes to one master
> machine but spread all of my reads over several slave machines.
> Thankfully Ivan Sagalaev's confusingly named mysql_cluster covers this
> problem neatly without modification to Django core - it's just an
> alternative DB backend which demonstrates that doing this isn't
> particularly hard: http://softwaremaniacs.org/soft/mysql_cluster/en/


Personally I think this is something that is better solved by the database
software itself. Having replication code-side is something that I don't feel
to good about. But maybe thats just me.


>
>
> 2. Sharding - being able to put User entries 1-1000 on DB1, whereas
> User entries 1001-2000 live on DB2 and so on.
>
>
>
This is something I would love, an example being archives. (As Eratothene
points out.

Maybe having to state a storage location on a per-row level. (IE this could
happen by overriding the manager, and simply switching DB at selection time.
or being able to provide the DB info at selection time.)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: QSRF Related

[Mike Scott]

David,
The point here is that you were using a development source for your code.
Understandably people have started using this source more and more due to
the enhancements and features provided, and its general stability. But it is
stated everywhere that the source is subject to change on a daily basis,
without warning and with backwards incompatable changes.

Now given the fact that these changes are expected and anticipated by most,
it is expected people keep an eye on the list. If you don't then you cannot
go round blaming the developers for something that they did. Your excuse
that you haven't got the time is valid, but yet not an excuse at all. If
you're using a development source for anything, then you must also keep in
touch with the information pertaining to that source, in this case
django-dev. If you cannot do that, then you shouldn't be using the
development sources.

Now I know this is an issue that not just you experienced David, and I
myself was quite suprised to see that (despite it being mentioned on both
mailing lists, for which I saw) it is yet to be mentioned on the blog
(which, again, seems to have become forgotten, and is collecting dust).
Perhaps a recommendation from yourself then David could be that the Django
developers could make more active use of the Blog for this kind of thing?
I'm all for that because it was an Announcement of a major change, and that,
if not listed in a specific announcements mailing list, should be placed
somewhere of prominence for general users, eg the blog.

There is an issue David, I agree. I just don't think your solution is quite
right. If you haven't time to pass over a few emails, then how do you find
the time to check a page every day? or even every half day? Also you should
check these things BEFORE you do a svn update, rather than after.

Regards,

Mike Scott

On Wed, Apr 30, 2008 at 2:25 PM, David Cramer <[EMAIL PROTECTED]> wrote:

>
> I've been extremely busy over the last few weeks, and have rarely had
> the chance to check the mailing list. I specifically disable email
> updates from these because of all the mail I get each day. So sorry
> for not having time (but I'm really not sorry).
>
> On Apr 29, 5:50 pm, Kenneth Gonsalves <[EMAIL PROTECTED]> wrote:
> > On 29-Apr-08, at 11:25 PM, David Cramer wrote:
> >
> > > WILL BREAK" (I didn't even know QSRF was released until someone
> > > pointed it out to me)
> >
> > must have been about a million messages congratulating malcolm on the
> > mailing list ...
> >
> > --
> >
> > regards
> > kghttp://lawgon.livejournal.comhttp://nrcfosshelpline.in/code/
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: mod_python issue

[Mike Scott]

This mailing list is for the development of django itself. Your issue is
with mod_python and is probably better answered at
http://mailman.modpython.org/mailman/listinfo/mod_python

It has nothing to do with django itself.




If you have any issues with django, then the first port of call (and often
the only port of call) is the django-users list.

Cheers.

On Mon, Apr 14, 2008 at 6:24 AM, jurian <[EMAIL PROTECTED]> wrote:

>
> I've been battling with this issue for half a day now.
>
> This is the error I'm getting when starting-up apache:
>
> [Sun Apr 13 20:13:29 2008] [error] make_obcallback: could not import
> mod_python.apache.\n
> Traceback (most recent call last):
>  File "/home/django/active/Python-2.5.2/lib/python2.5/site-packages/
> mod_python/apache.py", line 23, in 
>import time
> ImportError: No module named time
> [Sun Apr 13 20:13:29 2008] [error] make_obcallback: Python path being
> used "['/home/django/active/Python-2.5.2/lib/python25.zip', '/home/
> django/active/Python-2.5.2/lib/python2.5', '/home/django/active/
> Python-2.5.2/lib/python2.5/plat-linux2', '/home/django/active/
> Python-2.5.2/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload',
> '/home/django/active/Python-2.5.2/lib/python2.5/site-packages', '/usr/
> lib/python2.5/site-packages']".
>
>
> The server works, but mod_python doesn't.
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Unfair ticket management

[Mike Scott]

I'm not a fan of this discussion,

I understand what you're saying, and the simple importerror test should
suffice, otherwise its going to get to a point where we're going to have to
keep a list of python libraries that can't be used for app names. Its not
going to work like that. As far as I'm concerned, if you don't know enough
to know that you cannot name an app the same as a module on your python
path, then you're obviously not doing something right.

As an aside, I'm sure something could be implemented that goes through the
app list and see's if there are any conflicts. But not sure how reliable
this would be.

On Tue, Apr 1, 2008 at 4:08 PM, Thejaswi Puthraya <
[EMAIL PROTECTED]> wrote:

>
> On Mar 31, 9:08 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> > On Mar 31, 7:36 pm, Thejaswi Puthraya <[EMAIL PROTECTED]>
> > wrote:> First, I am very sorry to have caused so much of pain to you. I
> > > totally overlooked your ticket (just missed it) in an urge to
> > > contribute during the sprint. Will be careful from the next time. The
> > > patch for ticket #6789 too was pushed in after lot of reluctance from
> > > the devs because it still did not solve the problem of preventing the
> > > name clash during deployment.
> >
> > It's ok. It really wasn't so painfull :)
> >
> > > Another thing is that your current patch (as on 31/3/08) let's people
> > > name their project "test" which the INVALID_PROJECT_NAMES was
> > > preventing earlier.
> >
> > No, it won't. 'test' is a standard python package and it will be
> > detected by __import__ in try/except/else clause.
> > INVALID_PROJECT_NAMES is unnecessary - every single name in it is
> > handled by __import__ - I checked and tested this when created my
> > patch.
>
> Sorry to prolong this discussion. Though I can see the test module
> http://docs.python.org/modindex.html, it is not installed on my system
> and hence I was able to create a project by name 'test'. I am using
> python2.5.1 taken directly from the fedora rpm repository.
>
> Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
> [GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import test
> Traceback (most recent call last):
>  File "", line 1, in 
> ImportError: No module named test
> >>>
>
> --
> Cheers
> Thejaswi Puthraya
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: : default settings for unit tests

[Mike Scott]

Further to this I'd like to point out that SQL lite is a very limited
database in respect to the other offerings.

Encouraging such a practice, in my opinion, is a really bad idea.

Just my 2c.



Mike

On Feb 13, 2008 3:55 PM, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:

>
> On Feb 13, 2008 1:56 AM, David Cramer <[EMAIL PROTECTED]> wrote:
> >
> > Why don't they provide settings for MySQL, PostgreSQL, Oracle, MSSQL,
> > etc?
>
> If you think about what goes in a MySQL/PostgreSQL/Oracle settings
> file, the answer will be obvious.
>
> Yours,
> Russ Magee %-)
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Trying to add a ticket on documentation

[Mike Scott]

If Adrian or one of the others with access could update the new ticket page,
and add a link to register that would make these issues disappear. Right now
people just get confused and shy away more than they ask.

On Jan 10, 2008 1:54 PM, James Bennett <[EMAIL PROTECTED]> wrote:

>
> On Jan 9, 2008 6:40 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > Sorry, disregard... got the ticket in here
> http://code.djangoproject.com/ticket/6351
>
> Also, note that per the documentation on contributing to Django[1],
> the preferred process is to create an account in Trac (or, at least,
> to provide a username/email address). Doing so will disable the spam
> filter, which only operates on anonymously-submitted tickets.
>
>
> [1]
> http://www.djangoproject.com/documentation/contributing/#submitting-patches
>
>
> --
> "Bureaucrat Conrad, you are technically correct -- the best kind of
> correct."
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django weekly updates?

[Mike Scott]

http://groups.google.com/group/django-newsroom

I just created this group, If Rob, Michael could ping me when they're joined
and I'll give them higher permissions. Lets see what the newsroom can do!



On Dec 16, 2007 1:53 AM, Richard D. Worth <[EMAIL PROTECTED]> wrote:

> On Dec 14, 2007 11:48 AM, Rob Hudson <[EMAIL PROTECTED]> wrote:
>
> >
> > How do we go about setting up a new mailing list on google groups?
>
>
> Go to http://groups.google.com/ and click 'Create a group...' Then you
> just need:
>
> 1. Group name
> 2. Group email address (@googlegroups.com)
> 3. Group description
>
> Then you add the users. You can also decide whether the group is public
> (anyone can join) or invite-only.
>
>
> >
> > Anyone have a suggestion for a name?
>
>
> django-newsies?
>
> - Richard
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Better Support for static file serving via django

[Mike Scott]

Hey All,

I've been looking at how to better serve my static files for django sites,
and I'm particularly interested in things like Javascript handling.

For example if we were to look at RoR, they have their include tags which
can automatically compile javascript into one big file, compressing and
obfusicating it.

Is this an approach the bulk of the Django community are interested in
taking or is it something that we should leave to the things that do it
best, ie: Apache and the like.


Regards,


Mike Scott

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: DB API - the limiting syntax, is it magic?

[Mike Scott]

James, I'm think what I'm getting at more is not the fact that its
"magical", maybe that is the wrong choice of word. But my opinion is more of
the fact that it doesn't conform to the rest of the django database
commands.

I do think you put it aptly in asking do we want to be more SQL-style or
Python-style. Ultimately it boils down to people understanding the framework
better, and keeping it as is may infact do that. I think it is something
that needs to be considered quite carefully. Promoting slicing as the
recommended way, but still allowing a limit() function in there to conform
with the rest of the db api. Conformity, to a set standard (which in this
case doesn't seem to exist - which is another reason I am +1 on the DEP
idea), is better than doing it just cause you can.

What the issue was (and the reason I bought this up) was that it was
understood that the python functionality was executed after the method was,
and therefor there was an understanding that it wouldn't make any
difference:

Models.objects.filter(date__gt=date_start)[:1]

However, it did and it would have been clearer as:

Model.objects.filter(date__gt=date_start).limit(1)

Its something that has been solved by marking with a comment, however I'm
firmly a fence sitter at this point, so I'm ready to be swung either way.
But I don't think your comments so far have done so.


Mike.


On Dec 3, 2007 7:13 PM, James Bennett <[EMAIL PROTECTED]> wrote:

>
> On 12/2/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > Frankly, I have found the slicing syntax hard to understand and
> > error-prone myself. I think one of the reasons it seems magic is that
> > it's one of the *rare* cases in which we use a Python
> > "magic-syntax-ism" (like operator overloading, for instance) in the
> > framework, plus the fact that, what, *every* other piece of QuerySet
> > functionality uses a method. It seems bolted on.
> >
> > I'd be +1 on adding a distinct limit() method, and keeping the legacy
> > list method for masochists who actually enjoy coding in that way.
>
> And.. it's late and I'm possibly not thinking clearly, but I feel like
> fleshing out what I've already said, because this is something I have
> a strong opinion on.
>
> Let's step back from the case at hand and consider something else so
> it'll be a bit more objective to look at. That means another "magic"
> Python method, so I'll pick the __str__()/__unicode__() combo we do on
> model classes.
>
> To someone who's not familiar with Python, the fact that defining
> these methods will cause a complex object to -- in certain
> circumstances -- "magically" become a string is undoubtedly confusing.
> But the solution to that isn't to stop using them, it's to help people
> become familiar with the conventions of Python programming; if we
> switched to, say, defining 'toUnicodeString()' and 'toByteString()' on
> models, a lot more people would be able to immediately pick up Django
> and grok what's going on, but we'd be going against the grain of
> Python, which provides __unicode__() and __str__() for these purposes
> already, and we'd be confusing people who are familiar with Python and
> who expect that "convert Object X to a string" is going to call
> __unicode__() or __str__().
>
> I don't think there's anybody here who'd advocate adding explicit
> string-generating methods on models just for the sake of letting
> people avoid the need to understand how Python works; we'd be working
> against the language in a painful way, and in the long run it'd hurt a
> lot more than it helped.
>
> Getting back to the issue at hand, slicing a QuerySet is the same
> situation: a lot of people would undoubtedly grok things more quickly
> if there were explicit "limit()", "offset()", etc. methods on
> QuerySet, but Python already provides a standard language feature for
> objects which want to emulate a sequence and allow users to retrieve
> only a portion of the sequence, and defining our own separate set of
> methods for this would be working against the language in a big way,
> and we'd be doing it, essentially, so that people don't have to learn
> how Python works. Which is a disservice to everyone who uses Django:
>
> 1. Experienced Python programmers would wonder why the hell we're not
> just using the features Python provides for this use case.
> 2. Inexperienced Python programmers would just get bitten the first
> time they tried to slice some other sequence type and be right back in
> the same boat they were in originally.
>
> And, ultimately, referring to a standard language feature as "magic"
> does a large disservice both to Python and to people who are trying to
> learn Django and Python: the slicing syntax, and the way it's
> implemented, is no more or less "magical" than, say, a Java class
> which implements standard interfaces out of java.util or java.lang.
>
> So if it's possible to have a negative vote which involves aleph
> numbers or other such suitably infinite quantities, that's how I'd
> 

DB API - the limiting syntax, is it magic?

[Mike Scott]

Hi all,

I was in two minds about writing this as a ticket, mainly because I
understand that it is something that is a design decision.

Okay so the issue I came across today was that one of my python developers
changed some syntax on one of my views with loads some data from the
database, this particular model was being filtered, and limited. However due
to the fact that the limit syntax was using pythons slicing syntax, and not
a limit method, he thought that it wouldn't affect db (I have since showed
him that the table in question has 3 million+ rows, and that grows by a few
thousand every night). However it does raise and interesting point - should
the limit syntax be apart of a method, rather than hijack the python syntax,
is it too magic?

I'm very open to opinions here, as it is both clearly labeled in the
Documentation and has stuck so long, but it was an interesting development
for a python developer to come into Django for the first time and discover
this.

Regards,


Mike Scott

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Suggestion: DEPs - Django Enhancement Proposals

[Mike Scott]

+1 from me, this also a document that developers can look at and plan around
very succinctly.

On Dec 1, 2007 3:02 PM, Simon Willison <[EMAIL PROTECTED]> wrote:

>
> Here's an idea that's been kicking around in the back of my head for
> far too long: Django Enhancement Proposals, or DEPs. At the moment,
> large changes to Django (auto escaping, queryset refactor etc) are
> discussed in quite an ad-hoc way - if you want to stay completely up
> to date on them you need to be following mailing lists, tracking
> branches and talking directly to the developers. It would be great if
> these changes had a slightly more formal structure, and in particular
> a single document that described the design decision and what was
> going on.
>
> We're already doing this on the wiki for most things so it wouldn't be
> an enormous change, but formalising it a bit could help make things
> clearer. Python's PEPs work brilliantly; could the same idea work for
> Django as well?
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Adding a hook for pre-runtime setup (ticket #5685)

[Mike Scott]

Ah,

Sorry all. Knew I missed it.

Thanks Ben. I might go about documenting all this sometime then. We really
need to improve those docs :)

On 10/9/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
>
>
> On 10/8/07, Mike Scott <[EMAIL PROTECTED]> wrote:
> > Can I throw a hat in the ring and suggest a post-send-request hook?
>
> Perhaps you mean `request_finished`? [0,1,2]
>
> - Ben
>
> [0]
> http://code.djangoproject.com/browser/django/trunk/django/core/signals.py#L2
> [1]
> http://code.djangoproject.com/browser/django/trunk/django/core/handlers/wsgi.py#L205
> [2]
> http://code.djangoproject.com/browser/django/trunk/django/core/handlers/modpython.py#L161
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Adding a hook for pre-runtime setup (ticket #5685)

[Mike Scott]

Can I throw a hat in the ring and suggest a post-send-request hook?

I have an existing script in PHP which used shutdown_functions() and was
looking for ways to do this in python. Certain use cases for this arise.
(Though could be easily solved by sending to a queue server like
django-queue).

If I've missed something, point me in the right direction.

Mike.

On 10/9/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
>
>
> On 10/8/07, Paul Davis <[EMAIL PROTECTED]> wrote:
> > Something to think about though is providing a way to add
> > callbacks to this hook that is independant of settings.py.
>
> Having to modify settings.py doesn't both me here.  It's done for
> middleware and context processors, so it seems to fit with the rest of
> the project.  Additionally, it allows one to pick from a number of
> functions that may be provided in a library-type application.
>
>
> On 10/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> > I've been thinking this morning, between actual work tasks,
> > about an app-cache-populated signal.
>
> I'm +0 on this approach.
>
> From my perspective, we're trying to provide hooks into two
> application states... *before* and *after* the Django runtime
> environment is setup.  An app-cache-populated signal would just be a
> proxy for the latter.  If we ever add any other dependencies to what
> it means for the environment to be ready we'd need to create one more
> signal.
>
> Still, I'd rather see this than nothing at all... I'll be interested
> to revisit it when Adrian's INSTALLED_APPS replacement plan lands.
>
> - Ben
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Non-Western person names

[Mike Scott]

This is something that has been a gripe of mine in a current project, where
by originally we had organisations as users, rather than users themselves.

I think what should happen is the django user class should have a
"displayname" field, for which defaulted to the username if none was
provided, if users wanted more finegrained user information then they should
use the user profile feature.

Further to this again, perhaps a good idea for the contrib.auth is
for when django's model inheritence is sorted if someone wishes to expand
the user field in some way then all they do is inherit the base
contrib.auth.models.User model and add their own data, and then all that
would happen is in the configuration file users can specify the user model
used by the auth framework (could also be a list of models if you want
multiple types for any reasons), thus solving the current user profile
issue?


On 9/29/07, 周濟是母老鼠 <[EMAIL PROTECTED]> wrote:
>
>
> I created #5638 ( http://code.djangoproject.com/ticket/5638 ), would
> you like to have a discuss?
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django 100% threadsafe with DB?

[Mike Scott]

Istvan,

It should be threadsafe - the way web applications and web loads work mean
that lots of simultaneous connection will mean that it pretty much becomes a
threaded application, and for that reason I think more research should be
done into this sort of operation?

On 9/26/07, Istvan Albert <[EMAIL PROTECTED]> wrote:
>
>
>
>
> Django is 0% threadsafe (as in nada, null or zilch)
>
> it is not supposed to be run that way, but if you must keep locking
> around every operation.
>
> i.
>
>
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Missing patch files on code.djangoproject.com

[Mike Scott]

Also Jacob, on the documentation the link ot the contenttypes docs have gone
missing. As well as a few other documentation files that don't seem to be on
the index link.

Is this intentional?

On 9/19/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 2007-09-18 at 15:51 -0500, Jacob Kaplan-Moss wrote:
> > Hi folks --
> >
> > OK, I figured out what went wrong, but unfortunately in the process
> > wiped away the ones uploaded in the last couple hours.
> >
> > Sigh.
> >
> > I'm gonna consider that "good enough" and stop fucking around until
> > I've got proper backups running.
>
> I think there may be something wrong with the CSS that's supposed to get
> used when displaying patches. Can you drop that file where it belongs
> when you have a chance (assuming that's the problem)?
>
> And once you get all this sorted out, feel free to take the morning off
> tomorrow. You deserve it. :-)
>
> Todd
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Visual recognition of Django website

[Mike Scott]

I second Todds suggestion.

I'm also just +0 on the whole affair. While it would be nice I think it has
far surpassed the effort needed.

On 9/19/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, 2007-09-19 at 00:29 +, Johann C. Rocholl wrote:
> > On Sep 17, 10:17 am, "Justin Lilly" <[EMAIL PROTECTED]> wrote:
> > > I personally would also like a favicon for the django sites. I took
> the
> > > liberty of creating one using django's colors and fonts (stole the d
> from
> > > the logo).
> > >
> > >  http://www.flickr.com/photos/[EMAIL PROTECTED]/1397125183/
> >
> > Here's another attempt, with improved vertical alignment
> > (mathematically perfect), and in Windows ICO format:
> > http://johann.rocholl.net/django-icon/favicon.ico
> >
>
> While I'm +0 on the favicon thing, I personally think "d" is
> insufficient and "dj" would be much more identifiable as uniquely
> Django.
>
> Todd
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---