t; the way Pandoc and docutils work).
If anyone wants to play with that idea, I suggest to look at the HAML
syntax: <http://haml-lang.com/tutorial.html>. The way it uses
indentation for closing tags (just like Python) and CSS syntax for
making it concise is very clever.
Just saying...
--
the bug description or patch, as
always I'll be happy to help.
Regards,
[1] http://code.djangoproject.com/ticket/11621
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&q
__() to delegate attribute acces from one
model to the other? (if that's the central problem).
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers&qu
he db cache isn't!).
If someone is going to commit fixes to the DB cache backend, please
also take a look at <http://code.djangoproject.com/ticket/11483>
(which is causing failures with Jython backends).
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~--
;).
I wonder if it is also failing on the cx_Oracle backend, as I don't
see any new relevant code which protect against those cases. (Ref:
<http://code.djangoproject.com/ticket/4140>)
Regards,
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~
On Tue, Jan 20, 2009 at 2:02 AM, Malcolm Tredinnick
wrote:
>
> On Tue, 2009-01-20 at 01:54 -0300, Leo Soto M. wrote:
> [...]
>> So I've uploaded a small patch on #10071[4] which does the
>> normalization to int instead of unicode. I tested it with sqlite
>> (w
[1] http://code.djangoproject.com/ticket/7560
[2] http://code.djangoproject.com/changeset/8494
[3] http://code.djangoproject.com/changeset/8526
[4] http://code.djangoproject.com/ticket/10071
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message b
-really thread safe". You know, there
are GIL-less Python implementations out there ;-)
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gro
t; and
looks like the complete test suite runs correctly there (I mean,
without spurious errors):
http://testing.ingenium.cl/hudson/job/django-trunk/
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed t
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Sun, Aug 24, 2008 at 2:53 PM
Subject: GSoC Final Report: Django on Jython
To: JythonDevelopers <[EMAIL PROTECTED]>
Looks like many people already know about my SoC results. But I wanted
to "o
On Tue, Jul 22, 2008 at 5:29 PM, Sean Legassick
<[EMAIL PROTECTED]> wrote:
> On 22 Jul 2008, at 17:13, Leo Soto M. wrote:
> >
> > > Anything I can do to help? (I do a lot of development with the gis
> > > branch and PostGIS so I can try out the patch
On Tue, Jul 22, 2008 at 12:01 PM, Sean Legassick
<[EMAIL PROTECTED]> wrote:
>
>
> On 22 Jul 2008, at 15:01, Leo Soto M. wrote:
>
>> I'm not going to pretend that I know why there is not
>> TimeField.to_python. But some changes on #7560 needed it, so it is
&
On Tue, Jul 15, 2008 at 12:38 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 2008-07-15 at 11:49 -0400, Leo Soto M. wrote:
>> After fixing some corner cases of #7560[1], and realizing that it is
>> too easy to write a wrong get_db_prep_lookup method (ex
string-happy", such
as JDBC backends.
[4]
http://www.djangoproject.com/documentation/custom_model_fields/#get-db-prep-lookup-self-lookup-type-value
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed
connection.connection.autocommit(True)
> +else:
> +connection.connection.autocommit = True
> elif hasattr(connection.connection, "set_isolation_level"):
> connection.connection.set_isolation_level(0)
As this is also needed for JDBC backends, I fille
atibility.
+1
That also would help to be compatible with other Python VMs, which
don't recognize the PYTHONPATH environment variable (IronPython uses
IRONPYTHONPATH; Jython uses a Java VM property)
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~---
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Mon, Jul 7, 2008 at 1:08 PM
Subject: GSoC Weekly Report (#6): Django on Jython
To: Jython Developers <[EMAIL PROTECTED]>
Hi again!
Here is my report of what was done on the past week:
- Benchmar
On Fri, Jul 4, 2008 at 12:27 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> So the new [...]
A quick update: After more testing with real django applications I
discovered that I was breaking get_next_by_FIELD. This fourth patch[1]
fixes this issue and includes tests for this use case (whi
as just a lame excuse :-).
I just pushed that logic to DatabaseOperations and named it
"year_lookup_bounds".
So the new posted patch[1] is updated to svn trunk, and also fixes a
test that would broke because get_db_prep* now may return different
values for different backends.
[1]
http:/
On Thu, Jul 3, 2008 at 8:27 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 4, 2008 at 4:57 AM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
>>
>> Hi all!,
>>
>> I've posted a patch[1] with a small refactor to some Field's
>
ins an external django database
backend.
I would appreciate thoughts on the general approach, and some guidance
if I missed something.
[1] http://code.djangoproject.com/ticket/7560
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this mess
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Mon, Jun 30, 2008 at 12:12 AM
Subject: GSoC Weekly Report (#4 and #5): Django on Jython
To: Jython-Dev Developers <[EMAIL PROTECTED]>
Here is me again, back to doing weekly reports (sorry for miss
I don't think that it should be
resolved at the BooleanField level. The anonymous commenter there has
shown that, unless this issue is fixed at the mysql backend level,
values() will continue yielding 0,1 for False,True.
[1] http://code.djangoproject.com
On 12 jun, 21:37, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 12, 2008 at 8:35 PM, Ramiro Morales <[EMAIL PROTECTED]> wrote:
> [...]
>
> > Since then I've opened ticket [2]#7420 with a patch
>
> I see that part of the patch deals with
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Sun, Jun 15, 2008 at 11:25 PM
Subject: GSoC Weekly Report (#3): Django on Jython
To: JythonDevelopers <[EMAIL PROTECTED]>
So, I'm a bit late with the weekly report. in part because it has been
ot alone. Same happens with zxJDBC. Same
workaround as yours:
https://hg.leosoto.com/django.doj/rev/235b40d3da2e
[1]
http://groups.google.com/group/django-developers/browse_thread/thread/fb1afa93451008a2/0fed055c00cb64e7
[2] https://hg.leosoto.com/django.doj/l
As nobody said anything against forwarding my SoC reports here, I'm
assuming it is OK to continue doing it :)
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Fri, Jun 6, 2008 at 11:16 PM
Subject: GSoC Weekly Report (#2): Django on Jython
To: Jytho
On Tue, May 27, 2008 at 2:50 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
> On Mon, May 26, 2008 at 11:26 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > dates, times, and datetimes are converted to string _before_ being
> > passed to the backend.
>
> O
On Wed, May 28, 2008 at 5:08 PM, Alex Koshelev <[EMAIL PROTECTED]> wrote:
> On May 29, 12:57 am, "Leo Soto M." <[EMAIL PROTECTED]> wrote:
>> I see that almost all Field subclasses which implements
>> get_db_prep_save end calling Field.get_db_prep_sa
Hello django-devs!
FWIW, I'm forwarding my GSoC weekly report to this list. Any ideas,
comments, flames, etc are welcome.
-- Forwarded message --
From: Leo Soto M. <[EMAIL PROTECTED]>
Date: Sat, May 31, 2008 at 12:00 AM
Subject: GSoC Weekly Report: Django o
I see that almost all Field subclasses which implements
get_db_prep_save end calling Field.get_db_prep_save anyway. That's
curious, because Field.get_db_prep_save is a no-op.
Is it just some OOP style which we want to keep?
--
Leo Soto M.
http://blog.leosot
nd try to coordinate something once I
get the core Django working flawlessly on Jython.
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To p
les
>
> now, you have to write
>
> user has {% if num_files %} {{ num_files }} {% else %} no {%
> endif %} files
It already exists:
{{ num_files|default:"no" }}
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You receiv
On Mon, Mar 24, 2008 at 10:30 AM, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
>
> On Sat, Mar 22, 2008 at 3:04 PM, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> ...
> > On the other hand, all this gymnastic is done to allow receivers which
> > do not conform to the
, *args, **kwargs):
while True:
try:
return klass.get_or_create(*args, **kwargs):
except TheExceptionThatShouldNotEscape:
pass
Note that I tend to agree that Django should provide some way to deal
with this situations. My point is that if core developers don't agree
with us, w
other's problems but no
> acceptable solution was ever implemented.
Isn't the serializable transaction isolation level[1] what you are looking for?
[1]
http://www.postgresql.org/docs/7.4/interactive/transaction-iso.html#XACT-SERIALIZABLE
--
module is also not used
> afterwards.
To put it into sys.modules? (Not very useful, but it's the only
side-effect that occurs to me)
--
Leo Soto M.
http://blog.leosoto.com
--~--~-~--~~~---~--~~
You received this message because you are subscribed to
to the localflavor.py file.
Well, the file was recently split into per-flavor testing files, so
you now have to import your tests into regressiontests/forms/tests.py
, just as it's done with the other flavors.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received thi
On 9/25/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
[...]
> At least on SVN trunk , object.__unicode__ is gone too. So, #5560 is
> no longer needed.
Forget that. object__unicode__ is gone on Jython, but the __unicode__
attribute on the instances is not recognized yet.
So #5560 is
On 9/25/07, Ian Kelly <[EMAIL PROTECTED]> wrote:
>
> On 9/20/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > Oh, yeah. That's Jython's unicode(foo) calling foo.__str__ even when
> > hasattr(foo, '__unicode__') under some circumstances.
>
> I
asattr(self, '__unicode__'):
return force_unicode(self).encode('utf-8')
return '%s object' % self.__class__.__name__
The key is the hasattr() check. It's always true on Jython because
__unicode__ is defined on object.
Anyway, I just noticed that the upl
nd thanks for the head up about my broken patch. I didn't made a
full build after doing it, so I didn't realized the problem.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
it's not Django business.
--
Leo Soto M.
--~--~-~--~~~---~--~~
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 unsubscrib
exist, why
> does it in jython?
Heh. I'm also having headaches with this behaviour. But people on the
jython-dev mailing list are in a better position to answer this.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are su
the origin server, since they will contain
more than one (comma-separated) value if the original request already
contained one of these headers."
[1]http://wiki.squid-cache.org/SquidFaq/ConfiguringSquid#head-3518b69c63e221cc3cd7885415e365ffaf3dd27f
[2]http://httpd.apache.org/docs/2.2/mod
majority fails because strptime
is not present on Jython's datetime module]
As I touched many parts of Jython and Django, I'm now organizing all
the bits, to get presentable patches (or bug reports) to both
projects.
--
Leo Soto M.
--~--~-~--~~~---~--~~
Yo
code for Django, I'm trying to write it in
> such a way that it might be useful for other Python frameworks.
Maybe I completely misunderstood you, but what would be the difference
with modjy <http://www.xhaus.com/modjy/>?
--
Leo Soto M.
--~--~-~--~~~---~
ght: documentation can fix it, saying
loudly that, *when using this middleware, you can't trust the remote
IP, even if you trust the proxy server*. That's all.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to t
d that too. But I don't know what side effects could it have.
[...]
> i also applied the jython patch to fix the __module__ problems.
>
> and that's about all for major stuff i think.
Cool. Keep up the good work! And file some tickets here when you think
is appropriate.
--
Le
On 9/20/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> Now, if having a reliable remote IP address is important, then a
> setting (NUMBER_OF_TRUSTED_PROXY_SERVERS?) specifying how many values
> you can trust is the only thing that occurs to me. (I'm not that
> crea
using
x_forwarded_for.split(",")[-NUMBER_OF_TRUSTED_PROXY_SERVERS].strip().
What do you think?
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, sen
use case for reverse proxy users who want
to have a *reliable* remote address is not even hard: is impossible.
No documentation can fix it.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django dev
everse proxying
> rather than proxying
The middleware is about reverse proxying too. According to the doctests:
"[...] if you're not behind a reverse proxy that sets
HTTP_X_FORWARDED_FOR automatically, do not use this middleware"
--
Leo Soto M.
--~--~-~--~~~-
it. Such change would make easy to fake
the remote address when using that middleware. If people are _really_
using more than one trusted proxy (a transparent Squid getting in the
way maybe?), the middleware could have a settings to let the user
indicate how many values of X-Forwarded-For are know
On 9/19/07, Jacob Kaplan-Moss <[EMAIL PROTECTED]> wrote:
>
> On 9/19/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> > Well, I did it, see: http://code.djangoproject.com/ticket/5546
>
> Committed in [6379] -- thanks a bunch for the grunt work. The length
> of t
On 9/19/07, Leo Soto M. <[EMAIL PROTECTED]> wrote:
> I'm working on the splitting [...]
Well, I did it, see: http://code.djangoproject.com/ticket/5546
Please, if someone is currently working on such tests, ping me so I
can update the split version and post another patch. Or wait
y.
c) Dive into the django test infraestructure to fix it in the Right Way.
d) I'm missing something.
I'm for (a) followed by (c). That is, the split will leave this
unpleasant code on regressiontests/forms/tests.py, but it would be
better than the current situation anyway. Later, I can
s
> has the same functionality just had a quick look.
Thanks, it looks possible to solve this problem with a custom DataHandler.
Although it's not a direct conversion path (datetime -> string ->
java.sql.TimeStamp), it has the benefit that doesn&#
_save(self, False)) for f in non_pks]
One could write something like:
db_values = [connection.adapt_field_value(f, self) for f in non_pks]
Am I on the right track? Do you people have other ideas?
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because y
rounds.
That's why I've set up a separate mercurial repository to do some
exploratory work. Anyway, if people here thinks otherwise, I have no
problem on filling tickets with the changes.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message becau
e doctest
string is bigger than 32KBytes), but at least nothings seems broken
when running it on regular python.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group
t works" page. And now I'm trying run syncdb.
I'll post my changes (well, hacks) against the Django svn codebase as
soon as I can.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
ackend would do.
No, you still need to manage the differences between SQL dialects.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, s
importing
the __builtin__ module.
I'm working on a patch to get rid of those small problems. But I'm
pretty sure there are bigger ones.
--
Leo Soto M.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"D
we can move them all to count(id_col), which is faster).
Just curious: In which backends is count(id_col) faster than count(*)?.
I'd say that any decent database engine should take both as the same
(as long as a PK exists and no outer joins are performed), but I cou
65 matches
Mail list logo
