from:"Chuck Harmston"

Re: Possible contrib.humanize addition

2010-01-06 Thread Chuck Harmston

More of an academic question, as it likely isn't a feasible solution for
Django, but might a soundex solve this problem? Best I can tell, rules for
articles, without exception, are based on the pronunciation of the following
word..

Of course, phonology can be regional, subjective, and unpredictable. "Wind"
(the flow of gases) and "wind" (circular weaving) are identical to a
template tag but have different vowel sounds. The "a" sound in "bag" is
pronounced much differently in northern Minnesota (where it's bay-g) than
they do in Baltimore.

This feels unsolvable.

On Wed, Jan 6, 2010 at 9:56 AM, Hanne Moa  wrote:

> 2010/1/6 sago :
> >> If you present some research to
> >> demonstrate how this tag could/would work for non-English languages,
> >> it would be a lot more compelling.
> >
> > That's not going to work, in any meaningful sense. That peculiarity of
> > the article is highly English-specific. The generalization would
> > surely be something like
> >
> > {% if /some-regex/.matches(word) %}{{ form1 }} {{ word }}{% else %}
> > {{ form2 }} {{ word }}{% endif %}
>
> Disclaimer: I have a masters degree in Computational Linguistics. Ths
> is a simplified account of  "last year of bachelor"-stuff:
>
> Human language cannot (mathematically proven) be modelled by a mere
> regexp, as human language is not only context-free, (needing a full
> parser) but context-sensitive (needing parsers we don't really have
> yet). Nice, yes?
>
> It cannot go in humanize but it could go in localflavor for English.
> It would be necessary with a stemmer and a replaceable wordlist
> though, as what words get "an" and what get "a" not only depends on
> country but also on specific publishing styles - and all of this has a
> tendency to change over time.
>
>
> HM
>
> --
> 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.
>
>
>
>
-- 

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: please help me about enum attribute..

2010-01-12 Thread Chuck Harmston

As Gert said, these are questions that should be asked on django-users [1];
this list is for discussion about the development of Django, not development
with Django.

That said, there are detailed instructions in the docs [2] for using
multiple databases. This support was rolled out recently (since the last
tagged release), so you will need to be using a recent checkout from the
Django SVN repo [3] to do so.

[1] http://groups.google.com/group/django-users
[2] http://docs.djangoproject.com/en/dev/topics/db/multi-db
[3] http://code.djangoproject.com/svn/django/trunk/

On Tue, Jan 12, 2010 at 7:14 AM, chiranjeevi muttoju
wrote:

>
> hello girt thank for ur reply.
>
> i have another problem, could u please help me..
>
> i want to use the multiple database in django.. i fallowed somany
> procedures.. but i cont able to get how to use.. could u please tell me in
> detailed the process for multiple databases in django.. with sample
> settings.. please help me if u know this..
>
> thank you..
>
> On Tue, Jan 12, 2010 at 5:21 PM, Gert Van Gool wrote:
>
>> You should use instance.get_gender_display().
>> See http://www.djangoproject.com/documentation/models/choices/ for more
>> information...
>>
>> I do believe this is more a question for django-users.
>> -- Gert
>>
>> Mobile: +32 498725202
>> Web: http://gert.selentic.net
>>
>>
>> On Tue, Jan 12, 2010 at 12:38, 'chiru'tha  wrote:
>>
>>> Hi every one..
>>>  i got a problem.. please help me..
>>>I create a class for my model, in that class i declare an property
>>> gender and i make it as enum..
>>> it stores M or F only to the database. the sample code is shown
>>> bellow..
>>>
>>> GENDER_CHOICES = (
>>>(u'M', u'Male'),
>>>(u'F', u'Female'),
>>>)
>>> class Player:
>>> -
>>> gender = models.CharField(max_length=2, choices=GENDER_CHOICES,
>>> null=True, blank=True)
>>>  -
>>>
>>>
>>> The problem is, i want to get the fields from data base , it returns
>>> only M or F.. but i want the real values that is  Male and Female..
>>> how to achieve this one.. please help me..
>>>
>>> thank you..
>>>
>>> --
>>> 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.
>>>
>>>
>>>
>>>
>>
>> --
>> 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.
>>
>>
>
>
> --
> ▒▒�...@g@d...@◄▒▒
>
> --
> 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.
>
>
-- 

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: Moving all validation into the model layer.

2010-02-21 Thread Chuck Harmston

Unless I misunderstand what you're looking for, the link Brett provided
explains that this is a feature that is coming to Django. Some useful links:

The original ticket: http://code.djangoproject.com/ticket/6845
The patch: http://code.djangoproject.com/changeset/12098
The branch:
http://code.djangoproject.com/browser/django/branches/soc2009/model-validation


On Sun, Feb 21, 2010 at 6:15 PM, orokusaki  wrote:

> Does anyone have interest in this?
>
> --
> 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.
>
>

-- 
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: truncate filter

2010-03-06 Thread Chuck Harmston

Hi Wilm,

This is an issue which has been discussed several times before. A quick
search yields:

http://groups.google.com/group/django-developers/browse_thread/thread/924112bf84709225/56e623e758b08465
http://code.djangoproject.com/ticket/3963
http://code.djangoproject.com/ticket/5025

If you have suggestions for the docs, they are treated exactly like code:
they're in the repository [1] and are open for patches like any of the code.
Given the frequent requests for a truncate filter, I think that the
requested doc changes would be welcome. Feel free to submit a ticket with a
patch for this.

To your second point, what do you mean by "fails, because of unicode
characters"? Do you mean encoded HTML entities (e.g. &)?

[1] http://code.djangoproject.com/browser/django/trunk/docs

Best,
Chuck

On Sat, Mar 6, 2010 at 7:05 AM, Wim Feijen  wrote:

> Hello,
>
> Truncatewords is in Django, but I've been missing the (for me) more
> obvious "truncate"-filter, which truncates to a specified amount of
> letters, which is really important to me for formatting purposes.
>
> After some thorough looking on Google, I found out that I didn't need
> to write the filter myself, slice can do the same trick. I didn't get
> that from the official Django filter documentation, so my first
> question is:
> 1. Can we update the filter docs, so
> a) slice shows an extra example of slicing a string; and
> b) truncate_words refers to slice for truncating by letters, to give
> readers a helpful hint.
> These might sound trivial, but I am pretty sure that I am not the only
> one misunderstanding.
>
> 2. As I understand it, there are several cases where slice fails,
> because of unicode characters? What would be the proper solution to
> that, and can we include that in django trunk as well?
>
> Thanks for making Django better and better and better!
>
> Wim
>
> --
> 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.
>
>

-- 
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: dbsettings, and user configurable app settings

2010-03-10 Thread Chuck Harmston

1) In implementation, how is a YAML configuration file any different than
the Java/XML example that you offered? Syntactical differences between XML
and YAML aside, both systems define settings in markup languages (which by
definition have minimal capability for logic) that are eventually parsed (by
potentially faulty parses) into programming language datatypes.

2) The beauty of a programming language configuration system like Django's
is that it gives developers the option and ability to refactor settings
systems in ways that make sense to them and their projects.

For example, it provides you with the flexibility to keep settings in a YAML
file, if you so choose. My use case is a bit unique: I wanted
environment-specific (e.g. dev, staging, production) settings
overrides, kept in source-controlled files unless they were of sensitive
nature (DATABASE_PASSWORD, SECRET_KEY, etc). Python's flexibility gave me
the ability to turn settings into a full-blown module, with magic-keyworded
imports based on the machine's hostname and path of the settings module.

This flexibility is not by accident.

On Wed, Mar 10, 2010 at 8:16 AM, Joan Miller  wrote:

> It's a disaster from the maintenance view point. If it were not so,
> then people would not be proposing to refactor the settings as has
> been made in Pinax, or from multiple posts so many times.
>
> This is nothing new. Many people dislikes that kind of configuration,
> of the same that many people hates java by its fu**ing XML config.
> files.
>
> On 10 mar, 13:49, Russell Keith-Magee  wrote:
> > On Wed, Mar 10, 2010 at 6:18 PM, Joan Miller  wrote:
> > > Whatever configuration system using variables of a language is a
> > > disaster and it's going not maintainable as has been showed in Django.
> >
> > That's a pretty wild assertion to make without any evidence, and it's
> > completely contrary to my personal experience. Care to back it up? In
> > what way has Django demonstrated that using a programming language for
> > configuration files is a disaster?
> >
> > 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-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.
>
>

-- 
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: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

2010-03-13 Thread Chuck Harmston

This particular use case (having predefined sets of information loaded into
the database on either syncdb or other command) is what Django's fixture
loading/creation system is for.

http://docs.djangoproject.com/en/dev/ref/django-admin/#what-s-a-fixture
http://docs.djangoproject.com/en/dev/howto/initial-data/#providing-initial-data-with-fixtures

Does this proposal add any functionality that fixtures do not already
provide?

Best,
Chuck

On Sat, Mar 13, 2010 at 5:50 AM, Rajeev J Sebastian <
rajeev.sebast...@gmail.com> wrote:

> On Sat, Mar 13, 2010 at 3:56 PM, Gabriel Hurley  wrote:
> > "domain = Site.objects.get_current().domain"
> >
> > The "Site" model in that code comes from the
> > django.contrib.sites.models, part of the Sites framework I mentioned
> > above. This is not some bizarre buried database mishap; this is the
> > app developer taking advantage of a contrib app that is included in
> > Django.
> >
> > You complain "The trouble is, there is no straightforward way to
> > configure the name and domain of a site" but if you actually *include*
> > django.contrib.sites in your INSTALLED_APPS you'd see that it's EASILY
> > configurable using the Django admin, and that it in fact offers you
> > some very useful features if you want to publish similar content on
> > multiple domains.
> >
> > As of Django's 1.0 release the Sites framework is supported as an
> > *optional* component, allowing developers to take advantage of it in
> > their apps without requiring that everyone use contrib.sites. This is
> > accomplished using the RequestSite object. You can read about that
> > here:
> >
> >
> http://docs.djangoproject.com/en/dev/ref/contrib/sites/#requestsite-objects
> >
> > However, if you're in the habit of using 3rd-party apps that take
> > advantage of the Sites framework, I strongly suggest you simply *add*
> > "django.contrib.sites" to your INSTALLED_APPS in settings. Then you
> > can edit it via the Django admin, the Django shell, or by whatever
> > method you choose.
> >
> > Adding another setting in place of the actual contrib.sites app would
> > be a *different* solution to the problem solved by RequestSite, but I
> > don't see that it offers any real advantages.
> >
> > Please read the docs I linked you to carefully. It really does explain
> > everything you need to know to understand why your proposal is off-
> > base. Again:
>
> Gabriel,
>
> I think, you haven't read the proposal correctly.
>
> The suggestion was that, syncdb for e.g., would create the default
> Site using the settings SITE_DOMAIN and SITE_NAME instead of blindly
> using 'example.com'.
>
> This prevents the need to go in an edit the domain within the admin
> (or run some python code in shell) everytime one does a syncdb. It is,
> quite simply, a suggestion to allow overriding the django default when
> creating the *default* Site object.
>
> Regards
> Rajeev J Sebastian
>
> --
> 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.
>
>

-- 
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: DjangoCon.eu sprint proposal: New field type "CompositeField"

2010-05-26 Thread Chuck Harmston

For those not familiar with the previous discussion on the subject:

http://groups.google.com/group/django-developers/browse_thread/thread/e7de5d07d614761a/e3147d2f93bcc804
http://groups.google.com/group/django-developers/browse_thread/thread/32f861c8bd5366a5/22732dc88e644f77


On Wed, May 26, 2010 at 10:32 AM, Michael P. Jung  wrote:

> Some time ago I proposed a new field type called "CompositeField". It's
> basicly a way of doing composition in Django models.
>
> Its usage looks like:
>
>class CoordField(CompositeField):
>x = models.FloatField()
>y = models.FloatField()
>
>class Place(models.Model):
>name = models.CharField(max_length=10)
>coord = CoordField()
>
> And basicly creates this model:
>
>class Place(models.Model):
>name = models.CharField(max_length=10)
>coord_x = models.FloatField()
>coord_y = models.FloatField()
>
>
> Right now the code lives in a scrap heap repository, which is reused in
> many of the projects I work on. All the stuff is BSD licensed!
>
> https://hg.labs.terreon.de/common/chimes/
>
>
> It would be nice to get some feedback on this proposal and make it more
> useful to others. I would like to make a first class project out of it and
> add the possibility for composite fields to contain other composite fields.
> Admin integration would be awesome, but I've never really looked into that.
> The sub fields are normal model fields and can be accessed from queries and
> admin naturally.
>
>
> I'll join the sprints on thursday.
>
>
> --mp
>
> --
> 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.
>
>

-- 
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: django template revision (for 1.4?)

2010-05-27 Thread Chuck Harmston

The inability to assign variables is an intentional design decision; one of
Django's core tenets is that business logic and presentational logic should
be separated. The template language was crafted to provide non-programmers
(front-end developers and designers) the ability to work directly on
templates without having to touch the business logic. Though there are use
cases where defining variables would be helpful, it's a good flag that
you're approaching the problem the wrong way.

Additionally, you can call functions that take arguments, it just takes a
slightly different form than you might expect: custom template tags [2].
This allows you to extend the functionality of the template language while
still maintaining the separation of business and presentational logic.

An interesting historical example of the above two paragraphs: the smart {%
if %} tag [1], which was borne of the lack of an ability to use complex
logic in Django templates.

And the important footnote: I don't mean to stifle your suggestion; quite
the opposite, actually! As Jacob has admitted [3], there is an occasional
need in the Django for designers to tell the programmers to STFU. To extend
the previous example: the smart {% if %} tag was originally shot down but
was ultimately implemented in core [4].

[1] http://djangosnippets.org/snippets/1350/
[2]
http://docs.djangoproject.com/en/dev/howto/custom-template-tags/#passing-template-variables-to-the-tag
[3]
http://groups.google.com/group/django-developers/browse_thread/thread/18bca037f10769e9/cfd908f97b44e324?lnk=gst#cfd908f97b44e324
[4] http://code.djangoproject.com/changeset/11806

On Thu, May 27, 2010 at 7:36 AM, Tom Evans  wrote:

>
> Most PHP templating languages allow you to do things that are by
> design not in django's templating, for example in Smarty, one can
> assign new variables on the fly in the template, and even do crazy
> stuff like call functions that take arguments.
>
> Whether that is 'better' or not is a point of view - as you've a
> commit bit, and patches for this sort of stuff in django are rejected,
> I'd guess you are of the view that it is not ;)
>
> Cheers
>
> Tom
>
> --
> 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.
>
>

-- 
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: How to post data to the admin form by urllib2 ?

2010-07-27 Thread Chuck Harmston

Please do not cross-post to django-developers and django-users.

http://groups.google.com/group/django-users/browse_thread/thread/6fb15b60f1e551c0#

This group is for discussion about development *of* Django itself, not
development *using* Django.


On Tue, Jul 27, 2010 at 9:05 PM, jerry  wrote:

> Hi:
>  I build a website and want to login the admin form by python code. I
> have disabled the CSRF in my project  and use urllib2 to post data.
> here are my codes:
>
> 
> import urllib
> import urllib2
> import cookielib
>
> cj = cookielib.CookieJar()
> url_login ='http://127.0.0.1:8000/admin/'
> body =
>
> {'csrfmiddlewaretoken':'f85a33be11bd85108a1030fcce96a5ea','username':'root','password':'mypass','this_is_the_login_form':'1'}
> opener=urllib2.build_opener(urllib2.HTTPCookieProcessor(cj))
> opener.addheaders = [('User-agent','Mozilla/4.0 (compatible; MSIE 7.0;
> Windows NT 5.1)')]
> urllib2.install_opener(opener)
> req=urllib2.Request(url_login,urllib.urlencode(body))
> u=urllib2.urlopen(req)
> print u.read()
> print urllib2.urlopen("http://127.0.0.1:8000/admin/sites/
> site/").read()
>
> 
>
> but the codes don't seem to work,here is some part of the response
>
> ---
> 
> Looks like your browser isn't configured to
> accept cookies. Please enable cookies, reload this page, and try
> again.
>
> 
>  style='display:none'> value='678f0507075332a87211dff43d6f9ee4' />
>  
>   Username:  name="username" id="id_username" />
>  
>  
>   Password:  name="password" id="id_password" />
>   
>  
>  
>    
>  
> 
> 
>
> Could anyone give some suggestion?
>
> --
> 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.
>
>

-- 
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: Inclusion of easy-thumbnails into Django Contrib

2010-09-16 Thread Chuck Harmston

t;
>> > > > > D
>> >
>> > > > > On Thu, Sep 16, 2010 at 3:00 PM, Yo-Yo Ma <
>> baxterstock...@gmail.com>
>> > > wrote:
>> > > > >> Is there any plans to incorporatehttp://
>> > > github.com/SmileyChris/easy-thumbnails/
>> > > > >> into django.contrib? I have seen so many apps/libraries come into
>> and
>> > > > >> go out of existence (
>> http://code.djangoproject.com/wiki/ThumbNailsfor
>> > > > >> instance mentions sorl-thumbnails which is no longer being
>> developed).
>> > > > >> I just turned the key with easy-thumbnails and voila. It's like
>> magic,
>> > > > >> but not. It's easy enough to see what's going on behind the
>> scenes.
>> >
>> > > > >> This is something that, with the help of the core and other
>> > > > >> contributors, could be really great. It works for me as it it is,
>> but
>> > > > >> it may not work for a more "enterprise" application that uses S3,
>> etc.
>> > > > >> It might not be highly efficient (I wouldn't know). It might have
>> bugs
>> > > > >> that I just haven't noticed yet. I'm mentioning all of this
>> because I
>> > > > >> know somebody will say, "Why move it into Django if it's doing
>> just
>> > > > >> fine as a separate project?". After experiencing the bliss I
>> thought
>> > > > >> I'd drop a line here about it, and see what you guys thought.
>> >
>> > > > >> --
>> > > > >> 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 athttp://
>> > > groups.google.com/group/django-developers?hl=en.
>> >
>> > > --
>> > > 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.
>> >
>> > --
>> > Brian O'Connor
>>
>> --
>> 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.
>>
>>
>
>
> --
> Brian O'Connor
>
> --
> 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.
>



-- 
*
---
Chuck Harmston*
ch...@chuckharmston.com
http://chuckharmston.com

-- 
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: Something.is_live instead of implementation specific is_live settings

2010-09-24 Thread Chuck Harmston

; instance, passing a variable to the "Development" server to tell it
> > > >> you're in "Development" seems a bit redundant, no?
> >
> > > >> On Sep 23, 3:39 pm, "David P. Novakovic" 
> > > >> wrote:
> > > >>> As for running different configs:
> >
> > > >>> manage.py runserver --settings=settings_test
> >
> > > >>> etc..
> >
> > > >>> On Fri, Sep 24, 2010 at 7:25 AM, Jacob Kaplan-Moss <
> ja...@jacobian.org> wrote:
> > > >>> > On Thu, Sep 23, 2010 at 3:33 PM, Yo-Yo Ma <
> baxterstock...@gmail.com> wrote:
> > > >>> >> I'm simply proposing the idea of having the development server
> > > >>> >> explicitly set something to indicate a "in development" status,
> so
> > > >>> >> that if that does not exist you can make the assumption that the
> > > >>> >> project is live.
> >
> > > >>> > This is exactly what the settings.DEBUG flag is for. Use it. Love
> it.
> >
> > > >>> > Jacob
> >
> > > >>> > --
> > > >>> > 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 athttp://
> groups.google.com/group/django-developers?hl=en.
> >
> > > >> --
> > > >> 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 athttp://
> groups.google.com/group/django-developers?hl=en.
>
> --
> 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.
>
>


-- 
*
---
Chuck Harmston*
ch...@chuckharmston.com
http://chuckharmston.com

-- 
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: Something.is_live instead of implementation specific is_live settings

2010-09-24 Thread Chuck Harmston

My technique, which allows you to:

   - Segregate settings per environment
   - Keep environmental settings under version control
   - Have multiple environments on a single host (using an environment
   variable set by the WSGI script)
   - Keep passwords and other sensitive information out of source control
   - Conditionally modify settings based on the value of settings.DEBUG

https://gist.github.com/5e0e3d58e92f7530b396

Feel free to steal/modify/improve as you wish.

At this point, I think we're veering into django-users territory. Let's
bring it over there unless someone still feels strongly about Yo-Yo Ma's
original suggestion.


On Fri, Sep 24, 2010 at 4:58 PM, Simon Meers  wrote:

> If everything is under version control, you'll need to detect the server
> status somehow. Some options:
> - check the absolute path of the settings file on the filesystem if you can
> ensure this path is different on the production server
> - import socket; and check socket.gethostname()
> - check for "runserver" in sys.argv
> - etc.
>
>
> On 25 September 2010 06:50, Yo-Yo Ma  wrote:
>
>>
>> What if I want dev settings in version control?
>>
>> What if I want "explicit"?
>>
>>
>> On Sep 24, 11:09 am, "burc...@gmail.com"  wrote:
>> > How it's better from both of the following:
>> >
>> > 1)
>> > try:
>> > from dev_settings import *
>> > except ImportError:
>> >pass
>> >
>> > 2)
>> > if DEBUG:
>> > from dev_settings import *
>> >
>> > Because to have "project.is_dev" you'll have to write it somewhere
>> already!
>> >
>> > It's bootstrapping problem.
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Sep 25, 2010 at 12:01 AM, Yo-Yo Ma 
>> wrote:
>> > > I read that article. The problem is that it's deployment specific. I
>> > > dint even know what host name "omh.cc" is, but I have a feeling that
>> > > you couldn't work on that from your laptop to your desktop without
>> > > changing something. What I propose isn't a is_production variable. I'm
>> > > proposing an explicit is_development variable so that I can choose my
>> > > settings "explicitly" instead of trying to import something and then
>> > > something else if that's not there. That is very un-pythonic. If I can
>> > > say something to the effect of:
>> >
>> > > if project.is_dev:
>> > >import dev_settings
>> > > else:
>> > ># is live
>> >
>> > > just example. I'm not suggesting "project" as a global. It's just to
>> > > show the type of setting I want.
>> >
>> > > That's much cleaner, and far more explicit than "import os, socket,
>> > > etc".
>> >
>> > > On Sep 23, 7:41 pm, Yo-Yo Ma  wrote:
>> > >> Thanks for the link David. I'm gonna check it it now.
>> >
>> > >> On Sep 23, 6:16 pm, "David P. Novakovic" 
>> > >> wrote:
>> >
>> > >> > This link and the comments suggest some good stuff... particularly
>> the
>> > >> > comment from Malcolm and the original post.
>> >
>> > >> >
>> http://www.protocolostomy.com/2009/08/17/django-settings-in-dev-and-p...
>> >
>> > >> > On Fri, Sep 24, 2010 at 10:01 AM, David P. Novakovic
>> >
>> > >> >  wrote:
>> > >> > > The thing is, in production mode you normally have to define
>> where
>> > >> > > your settings are anyway, so you pass the unusual settings file
>> name
>> > >> > > there, and just use the regular settings.py for your development.
>> >
>> > >> > > So then you are passing the settings configuration information
>> once in
>> > >> > > the production server's configuration, not every time you run
>> your
>> > >> > > development server.
>> >
>> > >> > > I think people with any decent sized project have addressed this
>> issue
>> > >> > > in their own way that suits their own needs.
>> >
>> > >> > > For example we have lots of settings files and just import the
>> > >> > > relevant settings into a final file.
>> >
>> > >> > > For testing I do what i mentioned in my previous email.
>> >
>> > >> > > Like anything on here, you need to ask whether what you are
>> suggesting
>> > >> > > would actually be better off as part of the core or if it works
>> just
>> > >> > > fine as something that people can choose to use themselves...
>> >
>> > >> > > I think most people use whatever system they are happy with and
>> it
>> > >> > > doesn't get in the way of deployment/development. Thus this fails
>> to
>> > >> > > meet one of the critical requirements for consideration for
>> inclusion
>> > >> > > into core.
>> >
>> > >> > > D
>> >
>> > >> > > On Fri, Sep 24, 2010 at 9:27 AM, Yo-Yo Ma <
>> baxterstock...@gmail.com> wrote:
>> > >> > >> Thanks David, but I'm talking about having something built in.
>> For
>> > >> > >> instance, passing a variable to the "Development" server to tell
>> it
>> > >> > >> you're in "Development" seems a bit redundant, no?
>> >
>> > >> > >> On Sep 23, 3:39 pm, "David P. Novakovic" <
>> davidnovako...@gmail.com>
>> > >> > >> wrote:
>> > >> > >>> As for running different configs:
>> >
>> > >> > >>> manage.py runserver --settings=settings_test
>> >
>> > >> > >>> etc..
>> >
>> > >> > >>> On Fri, Sep

Re: #12991 Adding support for unittest2: request for review

2010-09-26 Thread Chuck Harmston

I just ran it on Python 2.4, 2.5, 2.6, and 2.7 with each of SQLite, MySQL,
and PostgreSQL on Debian with no problems.

Thanks for the work you put into this, Russell!


On Sun, Sep 26, 2010 at 6:24 PM, Karen Tracey  wrote:

> I've run it on Python 2.4 & 2.5 (Ubuntu, sqlite DB) with no problems.
>
> I do have some feedback on the @skipIfDB addition: I'd really like if this
> could be used to distinguish between the different MySQL storage backends.
> From a very brief look it seems like currently there are a bunch of tests
> skipped when the DB backend is MySQL, under the assumption that MySQL does
> not have transaction support. However MySQL does have transaction support
> when the InnoDB storage engine is used, so it would be nice if these tests
> were only skipped when the MySQL/MyISAM combination were in use, not when
> MySQL/InnoDB was used.
>
> Similarly there are a bunch of tests that fail or produce errors when the
> MySQL/InnoDB combination is in use, because that combination does not
> support forward foreign-key references when loading fixtures. It's not ideal
> to skip a bunch of tests for function that really should be tested on this
> combination (aggregates, for example), but for now at least the fixtures
> used by these tests do not allow them to pass on MySQL/InnoDB, so they might
> as well just be skipped. I have quit ever trying to run the full Django test
> suite using MySQL/InnoDB because there are just too many "known failures"
> there. It would be nice if the addition of @skipIfDB improved that. (For
> that matter I also never run the full suite with MySQL/MyISAM because the
> lack of transaction support with that combo makes it just too slow to run
> the full suite, but I don't know of any way to improve that situation.)
>
> One difficulty in adding this extra check is that it is hard to know for
> sure what storage engine is in use. If the database definition dict includes
> 'OPTIONS': { "init_command": "SET storage_engine=" } then we know
> the  engine is in use. If not, the default configured engine for
> the MySQL server will be used, and that could be either one. I'd be inclined
> to say if you want to skip tests based on a particular storage engine being
> used, then you need to make it explicit in the test settings what engine you
> are using. So I'd be happy if this @skipIfDB threw an error if it was asked
> to skip based on storage engine but could not find in the test settings what
> storage engine was being used.
>
> Another difficulty is figuring out how to nicely specify this additional
> requirement. Have not given that a whole lot of thought yet. Right now the
> @skipIfDB takes a simple string (matched against DB ENGINE key) or iterable
> of strings. Supporting querying both ENGINE and OPTIONS, and allowing for
> more than one to be listed, might get a bit ugly. I am curious why the
> iterable option here was added -- are there a lot of cases in the current
> suite where tests need to be skipped on a set of DB backends and not just
> one?
>
> Karen
>
>
>
>
>
>
>
>
>
>  --
> 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.
>



-- 
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com

-- 
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: ANN: Improving our decision-making and committer process

2010-09-29 Thread Chuck Harmston

In my world, the "accepted" status should only be used in one circumstance:
when a person is actively developing under or maintaining a patch for the
ticket. It's an indicator that someone has taken ownership of a ticket, to
prevent duplication of effort, etc. For example, I accepted ticket #25
during the DjangoCon sprints to prevent other developers at the sprints from
attempting to develop against the ticket.

Then again, my world also has purple skies and orange grass, so take it with
a grain...errr, a bushel of salt. ;)

-- 
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com


On Wed, Sep 29, 2010 at 5:32 PM, Ivan Sagalaev
wrote:

> Hello Jacob and everyone.
>
>
> On 09/29/2010 09:59 PM, Jacob Kaplan-Moss wrote:
>
>> Starting today, we're going to be making some minor but significant
>> changes
>> to the way the Django core committer team "does business."
>>
>
> That's about time :-). Congratulations and thank you!
>
> I have a comment and a suggestion:
>
>
>  This new process allows a proposal to be carried if:
>>
>> * There are at least 3 "+1" votes from core committers.
>> * There are no "-1" votes from core committers.
>> * A BDFL hasn't issued a ruling on the issue.
>>
>
> This doesn't explain what's one is supposed to think in situation when a
> proposal is ignored by core devs, which may happen for all sorts of reasons.
> I suspect that "less than 3 +1 votes" means the same as any -1 vote but I
> think that an explicit clarification would be nice.
>
> ---
>
> My suggestion is about this unfortunate ticket status -- 'Accepted'. This
> now works as a sort of a dusty shelf: when anyone of the core team looks at
> the patch and decides that there's nothing wrong with it he puts it on that
> shelf where the ticket has all the chances to lie for months or even years.
> And if the author of the patch tries from time to time pitching it to get it
> into trunk he can easily fall into all sorts of "not-a-good-times":
> conferences, feature freezes, hot discussions on other topics etc.
>
> My proposal is simple: 'Accepted' status shouldn't exist. If the patch is
> good it should be committed right away. If it's not there have to be an
> explanation why it needs improvement or why it's going to be wontfixed.
> Simple waiting doesn't really improve quality of the patch.
>
> What do you think?
>
>
> --
> 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.
>

-- 
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: rethinking raw_id_fields

2010-10-03 Thread Chuck Harmston

An Ajax admin solution (of the autocomplete sort, which I presume is what
you're proposing) does not have the same use case for raw_id_fields. It's
based on the assumption that the user knows the value of the unicode
representation of the object. It does not allow for discovery like the
raw_id_fields popup does: no filtering, no sorting, no searching, and no
browsing. I am a strong -1 this.

An aside: I may be wrong, but I believe that Zain's GSOC 2009 admin-ui
project [1] includes a completed Ajax autocomplete widget.

[1] http://code.djangoproject.com/svn/django/branches/soc2009/admin-ui/

-- 
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com

On Sun, Oct 3, 2010 at 9:34 PM, subs...@gmail.com  wrote:

> Does anyone besides me think that an AJAX field admin solution
> effectively deprecates raw_id_fields?
>
> I'm interested in seeing a ticket like #14370 go forward if only to
> close a slew of dusty old tickets about raw_id_fields.
>
> -Steve
>
> On Oct 3, 5:58 am, Marcob  wrote:
> > Well, M2M and raw_id_fields are a big player in wonderful admin
> > contrib with a poor interface: why do not improve them?
>
> --
> 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.
>

-- 
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: rethinking raw_id_fields

2010-10-04 Thread Chuck Harmston

We're playing semantic leapfrog here, but I don't see the proposed Ajax
solution as "searching", I see it as "autocompleting"; people won't use it
to discover content, they will use it as a shortcut for accessing content
that they are familiar with. As I said, much of the utility of the
raw_id_fields popup is that it allows content discovery, which is an
important use case—not all admin users will be perfectly familiar with the
content.

I am in full favor of an Ajax autocomplete widget (which, as I said, already
exists in the admin-ui branch), but do not want it to replace raw_id_fields;
their uses cases are completely disparate.

On Mon, Oct 4, 2010 at 12:05 AM, subs...@gmail.com wrote:

> With the AJAX field implementation on the table you're free to
> represent the objects however you want. Yeah, there's a few things
> left out but did you really say 'no searching'?
>
> -Steve
>
> On Oct 3, 10:09 pm, Chuck Harmston  wrote:
> > it's based on the assumption that the user knows the value of the unicode
> > representation of the object. It does not allow for discovery like the
> > raw_id_fields popup does: no filtering, no sorting, no searching, and no
> > browsing. I am a strong -1 this.
>
> --
> 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.
>
>

-- 
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com

-- 
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: Using jQuery.noConflict() instead of jQuery.noConflict(true) in contrib.admin

2010-10-22 Thread Chuck Harmston

A good

Moreover I wont' be able to use any jQuery plugin (that directly
> references `jQuery`) in the admin (without hacking with
> ModelAdmin._media), because the `jQuery` object does not exist. I am
> forced to include jquery twice ...


Per the jQuery docs , plugins
should *not* directly reference the jQuery object; they should do it in a
scope-controlled closure executed at creation with jQuery passed to it as a
parameter. This way, plugins can safely use the $ shortcut without worrying
about whether or not noConflict mode is on, whether it is assigned to a
separate namespace (like django.jQuery), etc; you simply need to change the
parameter passed to the closure. In the case of django.jQuery, it should
look like this:

(function( $ ){
$.fn.myPlugin = function() {
this.each(function() {
this.doSomething();
});
};
})( django.jQuery );

- CH

-- 
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: Giving Users Permissions on a Subset of Models

2010-12-18 Thread Chuck Harmston

Hi James,

Welcome to Django!

The terminology that you're looking for is either "row-level permissions" or
"object permissions." At a simple level, it allows you to define methods
that return a boolean indicating whether the user should be able to
add/view/change/delete the object. Fortunately this is already built into
Django (as of 1.2), so we're veering into django-users territory. There are
two ways to go about it:

   1. contrib.admin.ModelAdmin has three methods that implement this
   functionality within contrib.admin: has_add_permission() [1],
   has_change_permission() [2], and has_delete_permission() [3]. You can easily
   override these methods (which are passed the request and object) in the
   subclass, though you may want to incorporate a super() call to preserve the
   default permissions [4] behavior.
   2. You can also handle this at the authentication backend level. This is
   enabled by creating a custom backend with the supports_object_permissions
   property set to True. When this is True,
   backend.get_group_permissions(), backend.has_perm(),
   and backend.get_all_permissions() are passed additional parameters (the User
   object and object in question). Your custom backend should override these
   functions to provide the default behavior. This is detailed in the docs [5]
   and contrib.auth code [6].

You can take this an additional level and add field-level permissions—that
is, controlled access to specific fields on models—to contrib.admin [7].

Hope this helps!

Chuck

[1]
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L301
[2]
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L306
[3]
http://code.djangoproject.com/browser/django/trunk/django/contrib/admin/options.py#L317
[4] http://docs.djangoproject.com/en/dev/topics/auth/#permissions
<http://docs.djangoproject.com/en/dev/topics/auth/#permissions>[5]
http://docs.djangoproject.com/en/dev/topics/auth/#handling-object-permissions
<http://docs.djangoproject.com/en/dev/topics/auth/#handling-object-permissions>
[6a]
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/backends.py
[6b]
http://code.djangoproject.com/browser/django/trunk/django/contrib/auth/models.py
[7] https://github.com/chuckharmston/django-fieldlevel-permissions

On Sat, Dec 18, 2010 at 3:05 AM, James Hancock  wrote:

> Django Developers,
>
> This is my first post on Django-dev, so I thought I would start with a
> short introduction.
>
> My name is James Hancock, and I love python. Right now I live in
> Japan, and am developing an application for managing volunteer english
> classes throughout the country. (You can see the site at www.goeigo.org.)
> Obviously, the development is done in Django. As I have been
> developing the site I have really wished that Django would have one
> feature.
>
> Being able to grant permission to view, update, and create objects
> based on a subset of the models, rather than giving access to all of
> them. I don't know if this is correct terminology, but I like to think
> of it as adding rules to the permissions. So a teacher has permissions
> to see students, but only on the rule that they are signed up for his
> class. This would really help my project and I think that it would
> help others as well.
>
> I have a lot of time this summer to really get into coding when I get
> back to the States, and I was thinking about submitting the idea for a
> Google Summer of Code project.
>
> My questions are.
>
> 1. What Experience would I need in order to tackle a feature like
> this?
>
> 2. What is the general feel about the inclusion of a feature like
> this?
>
> Cheers,
> James Hancock
>
> @Andrew Ball
> I saw you posted something about this a while back and said you have a
> home grown system to manage this. What kind of functionality has
> worked for you? I would be very interested to hear how it has worked
> in the real world for you.
>
> --
> 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.
>
>

-- 
*
Chuck Harmston
*
ch...@chuckharmston.com
http://chuckharmston.com

-- 
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: ANN: Server upgrade on djangoproject.com

2011-01-31 Thread Chuck Harmston

Since you're installing directly from SVN, you'll need to preface the URL with 
"svn+". Just 20 minutes ago I successfully did a pip install using the 
following command:


pip install svn+http://code.djangoproject.com/svn/django/trunk/#egg=django


Chuck

On Monday, January 31, 2011 at 12:57 PM, Renato Garcia Pedigoni wrote:

> I don't know if it's related to this server upgrade, but I can't install 
> django from svn with pip anymore [1]. However, it's still working with 
> easy_install.
> 
> 
> [1] I'm using: pip install http://code.djangoproject.com/svn/django/trunk
> 
> 
> Pip error log on http://dpaste.com/371850/
> 
> 
> Thanks
> 
> 
> --
> Atenciosamente,
> Renato Garcia Pedigoni
> 
> 
> On Sun, Jan 30, 2011 at 11:15 AM, Russell Keith-Magee 
>  wrote:
> 
> > On Sun, Jan 30, 2011 at 2:11 PM, Russell Keith-Magee
> >  wrote:
> > > On Sat, Jan 29, 2011 at 5:45 AM, Jacob Kaplan-Moss  
> > > wrote:
> > >> On Fri, Jan 28, 2011 at 3:33 PM, Jacob Kaplan-Moss  
> > >> wrote:
> > >>> I'm starting the switchover to the new djangoproject.com server right
> > >>> now. Might be around 5 mins of downtime or so.
> > >>
> > >> Migration should be complete now. I'm still cleaning up a few
> > >> last-minute things, but if you notice anything wrong please pop into
> > >> #django-dev on freenode and let me know.
> > >
> > > You're not around in IRC (I'm guessing you're in bed) so here's a
> > > couple of issues:
> > 
> > 
> > One more -- it looks like SVN checkin triggers aren't working. I've
> >  just checked in a couple of tickets, and they weren't autoclosed by
> >  the commits.
> > 
> >  Russ %-)
> > 
> >  --
> >  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 
> > django-developers+unsubscr...@googlegroups.com.
> >  For more options, visit this group at 
> > http://groups.google.com/group/django-developers?hl=en.
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
>  -- 
>  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 
> django-developers+unsubscr...@googlegroups.com.
>  For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 
> 
> 




-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: database issue when using test_server MySQL Windows

2011-02-23 Thread Chuck Harmston

Hey Tim

Thanks for the report! I don't think this is a bug; you might want to read the 
documentation a little more closely.

http://docs.djangoproject.com/en/dev/ref/django-admin/#testserver-fixture-fixture

testserver runs the Django development server using data from the passed 
fixtures. This has two use cases, which are documented at the above link. I 
believe that you're looking for the functionality of manage.py's runserver 
command, which runs the development server with the database defined in the 
settings module.

http://docs.djangoproject.com/en/dev/ref/django-admin/#runserver-port-or-address-port

What you describe is the intended behavior and this thread is, needless to say, 
definitely in django-users territory at this point.

Chuck

On Wednesday, February 23, 2011 at 7:19 AM, Tim wrote: 
> Hi,
> 
> I'm new to Django and Python but I think I've found a bug with the
> testserver.
> 
> What happened is that Django wouldn't let me log in to my newly-
> created superuser account and kept saying "Please enter a correct
> username and password" despite the fact that I was 100% sure the
> information was correct. Also, I checked the data in the database I
> was using and the account was true for is_superuser, is_active and
> is_staff (in MySQL).
> 
> After a lot of messing around, I realized that Django testserver
> actually creates a separate "test_[databasename]" database with its
> own users - but when you create a superuser in shell, it only updates
> the real database (i.e. not in test_[databasename]).
> 
> Anyway - the only way I found around this was to manually copy the
> auth_user table after testserver is started from the actual database
> into the test_[databasename] database...
> 
> If anyone thinks I'm doing something wrong and this is not a bug,
> please let me know
> 
> Here's my setup:
> 
> Python 2.7
> Django 1.2.5
> MySQL for Python 1.2.3
> MySQL 5.1.41
> Windows 7 Pro
> 
> -- 
> 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 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: math tag

2011-05-05 Thread Chuck Harmston

How does the divisibleby filter not serve your needs here?


{% for object in list %}
{% if forloop.counter|divisibleby:"3" and not forloop.last %} 


{% endif %}
{{ object }}
{% endfor %}



http://docs.djangoproject.com/en/dev/ref/templates/builtins#divisibleby

Chuck

On Thursday, May 5, 2011 at 6:30 PM, Jesus Noland wrote: 
> A modulus or a row tag would not take away from the design principles
> of Django. All I want to do is just make rows based on data I am
> passing in from the related view function. I hope this can be added to
> Django very soon.
> 
> Regards,
> 
> On May 3, 12:42 pm, Ian Kelly  wrote:
> > On Tue, May 3, 2011 at 12:57 PM, Johannes Dollinger
> > 
> >  wrote:
> > > * __mul__: Display a value of 0.42 as 42%.
> > 
> > This would be better implemented as a "percentage" filter, IMO. It
> > would be a natural candidate for inclusion in django.contrib.humanize.
> 
> -- 
> 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 
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-developers?hl=en.
> 

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

New django.shortcuts methods: get_object/list_or_404

2009-06-24 Thread Chuck Harmston

Hello everyone!
I recently posted a patch that adds two methods to django.shortcuts:
get_list_or_none() and get_object_or_none(). These function identically to
their get _x_or_404 cousins, with one exception: they return empty QuerySets
rather than raising a 404. I've used get_list_or_none() several times in my
own projects, but in ticket #2659 Adrian dismissed get_object_or_none() as
scope creep. Since then, however, objects.none() has been added, which would
greatly enhance the utility of such methods (rather than just returning
false).

http://code.djangoproject.com/ticket/11352

Any comments/feedback/improvements are, of course, welcome. Thanks!

Chuck Harmston
http://chuckharmton.com

--~--~-~--~~~---~--~~
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 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Possible contrib.humanize addition

Re: please help me about enum attribute..

Re: Moving all validation into the model layer.

Re: truncate filter

Re: dbsettings, and user configurable app settings

Re: Adding optional SITE_DOMAIN and SITE_NAME variables in settings.py

Re: DjangoCon.eu sprint proposal: New field type "CompositeField"

Re: django template revision (for 1.4?)

Re: How to post data to the admin form by urllib2 ?

Re: Inclusion of easy-thumbnails into Django Contrib

Re: Something.is_live instead of implementation specific is_live settings

Re: Something.is_live instead of implementation specific is_live settings

Re: #12991 Adding support for unittest2: request for review

Re: ANN: Improving our decision-making and committer process

Re: rethinking raw_id_fields

Re: rethinking raw_id_fields

Re: Using jQuery.noConflict() instead of jQuery.noConflict(true) in contrib.admin

Re: Giving Users Permissions on a Subset of Models

Re: ANN: Server upgrade on djangoproject.com

Re: database issue when using test_server MySQL Windows

Re: math tag

New django.shortcuts methods: get_object/list_or_404

22 matches

Site Navigation

Mail list logo

Footer information