On Mar 29, 6:44 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> Hi!
>
> On Mar 27, 3:12 pm, Thejaswi Puthraya <[EMAIL PROTECTED]>
> wrote:> May 27th - June 10th : Work on the bindings
>
> There already exist new pam bindings based on
> ctypes:http://atlee.ca/software/pam/module-index.html
Hi!
On Mar 27, 3:12 pm, Thejaswi Puthraya <[EMAIL PROTECTED]>
wrote:
> May 27th - June 10th : Work on the bindings
There already exist new pam bindings based on ctypes:
http://atlee.ca/software/pam/module-index.html
> June 11th - June 24th : Work on the auth-backend
import pam
from
Ah. I'm glad I brought it up.
When the time comes to port my code, I'll try skipping step 1 first.
--
Daryl
On Fri, Mar 28, 2008 at 5:48 PM, Martin v. Löwis
<[EMAIL PROTECTED]> wrote:
>
> > I think you misunderstand the role of 2.6. See the seven steps under
> > "The recommended
> I think you misunderstand the role of 2.6. See the seven steps under
> "The recommended development model for a project that needs to support
> Python 2.6 and 3.0 simultaneously..." in
> http://www.python.org/dev/peps/pep-3000/#compatibility-and-transition.
> Step 1 reads "Port your
On Fri, Mar 28, 2008 at 5:54 AM, Yuri Baburov <[EMAIL PROTECTED]> wrote:
> schema-evolution is separable from applications -- it's utility, and
> applications codes are still compatible with each other, but different
> querysets features as 3rd-party libraries could make project code
>
> So this means, though, that folks running from SVN will still need to
> run setup.py every time they update, right? Not that that's a
> dealbreaker -- I think Django-on-Py3k'ers will be on the cutting edge
> anyway -- just wanna check.
Correct. distutils operates using time-stamps, so it
The idea of adding custom methods to QuerySets seem interesting but I
think that subclasing a core part of the framework is quite messy and
will require for the developers to know/understand the inner workings
of the framework (and there goes abstraction). With this approach you
would end up, if
Though search is of primary importance, object history is obviously
very important as well -- both auditing (Audit Log pattern) and
rolling back/comparing changes (Temporal Object pattern) are very
common use cases (see Martin Fowler's treatment of these and some
other patterns for things that
> In my opinion the answer is this:
> 1. A BaseQuerySet that all internal Django calls could rely on staying
> the same.
> 2. A setting (DEFAULT_QUERYSET_CLASS for example) which, by default,
> points to BaseQuerySet, but could be changed to point to any sucblass
> of BaseQuerySet.
>
>
On Fri, Mar 28, 2008 at 3:35 PM, Collin Anderson <[EMAIL PROTECTED]> wrote:
> So maybe I should ditch the web-interface and just make a good, robust
> inspectfile.
Glad my hint wasn't all that subtle :)
I, for one, would use ``inspectfile`` all the damn time.
Jacob
Hi Jacob,
> My main point of feedback is that you're dealing with a *HUGE* problem
> -- dabbledb represents literally years of work, and trying to
> reproduce that in a single summer is seriously unrealistic.
Yes, I realize that the types of migrations that dabbledb does are
currently not
Interesting. I wasn't sure if it'd be valid since I believe in 2006
Search was a GSoC idea. I guess I assumed it wasn't going to be
considered since it has been 2 years since and it's not on the list
any more, but I did realize of course it doesn't exist. :D
I think I will likely take your
I think you misunderstand the role of 2.6. See the seven steps under
"The recommended development model for a project that needs to support
Python 2.6 and 3.0 simultaneously..." in
http://www.python.org/dev/peps/pep-3000/#compatibility-and-transition.
Step 1 reads "Port your project to Python
In my humble opinion a search abrastraction app bundled in
django.contrib is a really high priority and has suitable scope for a
SoC project. Qouting James http://www.djangosnippets.org/about/faq/:
"Why isn't there a search system?
Because no-one's yet written a good generic search system for
On Fri, Mar 28, 2008 at 8:07 PM, Daryl Spitzer <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 28, 2008 at 8:57 AM, Jacob Kaplan-Moss
> > Ahh -- this was the part I was missing; my apologies for being dense.
> > I've been thinking of 2to3 as a one-time tool -- run it to move to
> > 3.0, and never
On Fri, Mar 28, 2008 at 8:57 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2008 at 5:10 PM, Martin v. Löwis
> <[EMAIL PROTECTED]> wrote:
> > So leave the code as-is, and have 2to3 fix it at installation
> > time (whenever setup.py is invoked by 3.x; setup.py itself
>
On Fri, Mar 28, 2008 at 9:05 AM, Waylan Limberg <[EMAIL PROTECTED]> wrote:
> Have you seen the dbsettings [1] app? If I'm understanding you
> correctly, it does everything you want.
>
> [1]: http://code.google.com/p/django-values/
Well, not exactly everything, since dbsettings doesn't export
On Fri, Mar 28, 2008 at 10:01 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> Hi Colin --
>
> Neat ideas!
>
> My main point of feedback is that you're dealing with a *HUGE* problem
> -- dabbledb represents literally years of work, and trying to
> reproduce that in a single summer is
Hi Colin --
Neat ideas!
My main point of feedback is that you're dealing with a *HUGE* problem
-- dabbledb represents literally years of work, and trying to
reproduce that in a single summer is seriously unrealistic.
I think you should scale back your proposal. "inspectfile" would be a
nifty
On Thu, Mar 27, 2008 at 5:10 PM, Martin v. Löwis
<[EMAIL PROTECTED]> wrote:
> So leave the code as-is, and have 2to3 fix it at installation
> time (whenever setup.py is invoked by 3.x; setup.py itself
> runs without changes on 3.x)
Ahh -- this was the part I was missing; my apologies for
Hello,
My name is Collin Anderson and I am interested in participating in
Google Summer of Code for django. I am a junior at the University of
Minnesota studying computer science. My idea is inspired by a
suggestion on the 2006 Summer of Code ideas list:
"add dabbledb (http://dabbledb.com/utr/)
On Fri, Mar 28, 2008 at 4:50 AM, Michael Radziej <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> > [ugly stories about other source transformer tools and
> > how they failed deleted]
>
Actually, the translator was successful. I'm not talking about any
specific project, I'm mentioning my opinion of
Hallo Martin,
offensichtlich hält sich das Interesse der Django-Entwickler in Grenzen.
Kann ich die Sache anderweitig unterstützen, eventuell als Co-Mentor von der
Django-Seite? Mit was für zeitlichen Anforderungen müsste ich da rechnen?
Ich hab das noch nicht gemacht.
Ich bin allerdings von
On Fri, Mar 28 2008 at 11:20:52AM BRT, Peter Herndon <[EMAIL PROTECTED]> wrote:
> As Alberto said, and James and Jacob, I don't see enough value for
> Django. The key here is to define a project that results in a usable
> code contribution by the end of the summer *for the project*. Not for
>
Have you seen the dbsettings [1] app? If I'm understanding you
correctly, it does everything you want.
[1]: http://code.google.com/p/django-values/
On Fri, Mar 28, 2008 at 8:15 AM, Alberto García Hierro <[EMAIL PROTECTED]>
wrote:
>
> Hi Django developers,
> In first place, let me
El 28/03/2008, a las 11:50, Michael Radziej escribió:
>
> Hi,
>
>> [ugly stories about other source transformer tools and
>> how they failed deleted]
Not to understimate the student nor the Python community, but think
about it in terms of developer time. TrollTech worked on Qt4 for
schema-evolution is separable from applications -- it's utility, and
applications codes are still compatible with each other, but different
querysets features as 3rd-party libraries could make project code
incompatible, and that's baaad.
On Fri, Mar 28, 2008 at 11:07 AM, [EMAIL PROTECTED]
Hi,
> [ugly stories about other source transformer tools and
> how they failed deleted]
I don't understand all the negative thinking.
Django would probably be a great show case to see whether the planned
transition to python 3.0 works as it is designed. If things do not work out,
this might
El 28/03/2008, a las 5:42, Sage La Torra escribió:
>
> I'll throw in my 2 cents too:
>
> I think machine based translation is iffy at best. I'm not the most
> up-to-date on py3k, but I have experience with other such projects (I
> wrote a Perl 5 to Perl 6 translator for Summer of Code 2006).
Your post contains a lot of lines, but I don't see where the leaking
files descriptor should be.
You can find the open files with this command line (linux). You need to
modify the -C parameter
to fit your binary.
ps -C httpd2-prefork -opid= | while read pid; do ls -l /proc/$pid/fd/*;
done |
30 matches
Mail list logo
