What really annoys me is all the talk about how important it is that
its designed for non-programmers but if i recall corectly jacob said
on djangocon that they never aimed for making django a general purpose
webframework, they just made something that fit their needs. With that
said, how many dja
I dont know if this has been covered in some of the mentioned previous
multi db support threads but how is it supposed to work with admin?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
I guess this just proves there's too many multi db threads and that we
are many who're happy Adrian is making it happening. :)
On Apr 6, 11:04 pm, Alex Gaynor wrote:
> On Mon, Apr 6, 2009 at 5:04 PM, Alex Gaynor wrote:
>
> > On Mon, Apr 6, 2009 at 5:00 PM, Andreas wrote:
I know everyone is fed up with discussions about schema evolution and
multi db support but when it comes to schema evolution I think it's
time to have a discussion about it again.
I think we all can agree that picking a schema evolution app for a
django project isnt one of those things everybody
My point wasnt to pick a solution, in this case South and just throw
it into django.
What I mean is, there is no winner nor any loser. I was more looking
for taking it,
and changing it in a way making most the core devs happy, and
hopefully a majority
of the community happy. Just to fork any of al
On Apr 27, 10:49 pm, Malcolm Tredinnick
wrote:
>
> Permit me to correct that impression: you are mistaken.
Good! That's what I want'ed to be.
>
> That's also not a really valid assumption. There are still significant
> differences and different limitations and advantages with each approach
>
By the way, rails is going agnostic in 3.0... Says it all.
On Aug 18, 4:06 pm, diogobaeder wrote:
> Hi there,
>
> After reading this
> posthttp://groups.google.com/group/django-developers/browse_thread/thread...
> I decided to ask you guys about your opinions in choosing an official
> JavaScrip
?
I don't think this is just an issue for those planning to edit the
admin-view code.
Andreas
I'd love to help with the Django development. If I encounter a
Traceback in the admin interface, how would you recommend I start
debugging? Running the webserver in Komodo's debug mode fails since
multi-thread debugging is not supported. Is there a way to "simulate" a
request for a page like http:
html4 is derecated.
xhtml is deprecated.
With google chrome frame out there theres absolutly no reason to not
begin with html5 already.
The longer we wait, the longer it will take before html5 becomes "the
it".
On Sep 27, 1:46 pm, Simon Willison wrote:
> On Sep 27, 10:49 am, veena wrote:
>
Hello,
i'm trying to get Django running in Aptana Studio. I've got PyDev installed and
can create a new project. The point that's missing is the "run as". Does
anybody know how to setup a run configuration.
(Im running it on mac, if that's important to know). Or is there a better dev
environme
jango 1.3 with the logging framework and
AdminEmailHandler:
https://docs.djangoproject.com/en/dev/topics/logging/#django.utils.log.AdminEmailHandler
-Andreas
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, sen
thing that might break with such a change? Are
there any specific reasons it works the way it does?
I will be happy to create a ticket and patch for this, I would get to input in
case I miss something obvious.
Cheers
Andreas
--
You received this message because you are subscribed to the Goo
On Thursday 3 May 2012 at 21:17, Karen Tracey wrote:
> On Thu, May 3, 2012 at 12:29 PM, Andreas Pelme (mailto:andr...@pelme.se)> wrote:
> >
> > Djangos default testrunner reorders the test suite to run all TestCase
> > tests before TransactionTestCases, which avoids thi
On Thursday 3 May 2012 at 22:14, Ramiro Morales wrote:
> On Thu, May 3, 2012 at 1:29 PM, Andreas Pelme (mailto:andr...@pelme.se)> wrote:
> > I am trying to run my Django test suite with an alternative test runner
> > (py.test), and found some issues w
On Thursday 3 May 2012 at 19:23, Anssi Kääriäinen wrote:
> On May 3, 7:29 pm, Andreas Pelme http://pelme.se)> wrote:
> > I am trying to run my Django test suite with an alternative test runner
> > (py.test), and found some issues with test isolation.
> >
> > Tran
_fixture_teardown (which could be
considered private?). Unless that is done, I cannot see how tests can be
affected by this, but there can certainly be something I am missing here!
I guess we need someone who wrote the initial TransactionTestCase or knows why
it is the way it is to give his/hers
On Friday 4 May 2012 at 13:30, Karen Tracey wrote:
> On Fri, May 4, 2012 at 4:46 AM, Andreas Pelme (mailto:andr...@pelme.se)> wrote:
> >
> > That's a good question. Anyone who wrote to original
> > TransactionTestCase/reordering implementation that wants to chime
spective).
I guess it boils down to where to draw the line for backward compatibility
here. :-) I personally think it is acceptable since we can offer a very easy
fix for the existing (already broken) tests out there.
Andreas
--
You received this message because you are subscribed to the Goog
itialised state would be very very useful in situations like this,
and would have saved us many hours of confusion.
--
Andreas Pelme
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop recei
can take care of making the issue + pull-request.
>
> Greetings.
> Jesus.
Hi,
This is a tricky issue that has been discussed earlier, you will probably want
to check out ticket #14051:
https://code.djangoproject.com/ticket/14051
—
Andreas Pelme
--
You received this message becaus
s what the output from a similar test with pytest would result in:
(Screenshot at http://pelme.se/~andreas/private/pytest_assertion.png to give
the correct colors/formatting.)
$ py.test test_foo.py
= test session starts
===
uple class for "easy"
notation within the settings.py might be an option, but after server
startup all of those should be immutable. So for the sake of logic, take
tuples, please.
Andreas
--
You received this message because you are subscribed to the Google Groups
"Django deve
>
>
> On Monday, January 19, 2015 at 12:35:10 PM UTC+1, Andreas Kahnert wrote:
>>
>> I'm strongly against lists. Lists are mutable objects, their components
>> can be changed in place. The settings are initialized at server start and
>> after that changes on
eing a tuple is making it
> necessarily more safe than a list - is the above code really much different
> to:
>
> from django.conf import settings
> settings.TEMPLATE_DIRS.append('foo')
>
> On 19 January 2015 at 14:45, Andreas Kahnert > wrote:
>
>> I'm
sequence in the pattern:
A = (
1,
2,
)
which is perfectly PEP-conformant and makes reodering elements manually
also more easy because you can cut'n'paste whole lines.
Am Montag, 19. Januar 2015 17:35:44 UTC+1 schrieb Florian Apolloner:
>
> On Monday, January 19, 2015 at 3:45:18
PS: python should be able to access tuple members faster, because it can be
implemented as array instead of double-linked-structs which are necessary
mutable lists. But as far as I know it doesn't.
--
You received this message because you are subscribed to the Google Groups
"Django developers
rting, which minimizes the risk
of accidently assigning to it.
Am Montag, 19. Januar 2015 18:53:26 UTC+1 schrieb Loïc Bistuer:
>
> Hi Andreas,
>
> As Florian pointed out, you can't mutate a tuple, but you can mutate the
> settings object, so using a tuple or a froz
Interesting, ... so excuse me.
The next point also clearifys my PS from above, lists are over-allocated
dynamic sized arrays. (this explains why python is such an memory eater as
well as why I experienced performance loss when using the mutability of
lists extensivly)
Am Montag, 19. Januar 201
I advertise that strongly against lists, because we actually had that kind
of issue in our company.
One colleague created a list with phrases for some verbose logging in the
settings.py. In the view function he promoted this list together with the
actual data, also a list which is used for stori
Just for completness: accidential assignment to the settings object itself
could be easily prevented with a __setattr__ method on its class, since
django yields on various other places about configuration problems it could
not be wrong if the programmer gets noted about an illegal assignment. If
Hi again,
Well, I can acknoledge that your reasons for list (beginner friendly) are
as good as my reasons for tuples (seems to be more logical choice for
things that are static). To say it in other words, my idea was simply: Use
tuples and the programmer will know that these arn't ment to be alt
. Let me know what you think and I’ll be happy to continue working on a
proper patch to get it into a merge-able state.
Cheers,
Andreas
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To un
open questions would be very
welcome and helpful!
Cheers,
Andreas
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
response
73. callback, callback_args, callback_kwargs =
resolver.resolve(request.path)
Exception Type: TypeError at
Exception Value: unpack non-sequence
--------
Andreas
signature.asc
Description: This is a digitally signed message part.
On Donnerstag 26 Juni 2008, [EMAIL PROTECTED] wrote:
> To avoid spam detection sign up.
Well, then the web site should hint at this fact, too. I was fairly close to
just abandoning the effort of trying to tell you about the issue I
encountered.
Andreas
signature.asc
Description: This i
On Donnerstag 26 Juni 2008, Collin Grady wrote:
> Andreas Klöckner said the following:
> > Well, then the web site should hint at this fact, too. I was fairly close
> > to just abandoning the effort of trying to tell you about the issue I
> > encountered.
>
> It does.
This, with more elaborate explanation, is now issue 7550, at
http://code.djangoproject.com/ticket/7550.
Andreas
On Donnerstag 26 Juni 2008, Andreas Klöckner wrote:
> Hey there,
>
> I tried to submit this bug, but it wouldn't let me--it thought I'm a
> spammer. You shou
[This messages is related to
http://groups.google.com/group/django-developers/browse_thread/thread/64e4d42590145347
]
On Jul 27, 11:39 pm, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On Sun, 2008-07-27 at 16:39 +0200, Andreas Pelme wrote:
> > Hello
>
> > I have sta
without any issues.
Is there any chance we could get this into 1.1? What is currently
keeping it from not being committed to trunk? If there is something I
can do to help getting it into trunk, please let me know.
Best regards
Andreas Pelme
[1] http://code.djangoproject.com/ticket/9289
[2]
http
legacy databases should be enhanced by a section
about extendig a consisting django application. A web application
isn't static and changes in the schema from time to time are
inevitable.
Thanks
Andreas
--~--~-~--~~~---~--~~
You received this message because yo
he two weeks before the SoC midterm evaluations
on July 9 I am writing eight exams and therefore I don't expect to get
much coding done. I'll make a bit of an early start to make up for this.
Andreas
[1] www.aiplayground.org/artikel/improving-django/
--~--~-~--~~~-
_and_files and the
inclusion of resource urls in serialized output until next Friday.
Regards,
Andreas
[1] Like this:
http://django-rest-interface.googlecode.com/svn/trunk/django_restapi_tests/urls.py
--~--~-~--~~~---~--~~
You received this message because you are
:1 to models on the other hand. I will take a closer look
at the tickets you opened when I get to the second half of my
proposal, but note that what I am working on is not XMLRPC or SOAP.
Regards,
Andreas
On 6/2/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> On 6/1/07, Andreas Stu
uch a REST API or if you have
specific comments on the code, please let me know.
Regards,
Andreas
[1] http://code.google.com/p/django-rest-interface/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django develop
k for next week is to think about the
relationship between the REST interface and authentication. It should
be possible to have different levels of access for authenticated and
unauthenticated users.
Criticism, ideas and suggestions are welcome!
Regards,
Andreas
[1] http://code.google.com/p/d
it testing framework. Another issue that
needs to be resolved next week is that authentication should allow
different levels of access to the same resource for authenticated and
unauthenticated users.
As always, criticism, ideas and suggestions are welcome!
Regards,
Andreas
[1] http://code.go
very REST app
in some way or the other and that we can take care of?
Expect the next update around July 20th.
Regards,
Andreas Stuhlmüller
[1] http://code.google.com/p/django-rest-interface/
--~--~-~--~~~---~--~~
You received this message because you are subscr
d b) which insights we gain from the
work on the non-model-based part of the project. I will remember your
point when I write the documentation on how to use the API.
Regards,
Andreas
[1] http://code.google.com/p/django-rest-interface/
--~--~-~--~~~---~--~~
You receiv
ry URL pattern.
Note that in the the above example we might replace the url() call
with an api_url() call that saves us from repetitive definitions.
Regards,
Andreas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Grou
lete"
button to the template example and verified that it works if you add
HttpMethodsMiddleware to your middleware classes.
Thanks for your comments!
Regards,
Andreas
[4] http://www.djangosnippets.org/snippets/174/
--~--~-~--~~~---~--~~
You received this mess
chapter on best practices for REST-oriented architectures with short
notes on where the REST interface still needs improvement.
If you feel that there are important issues I am missing, please write
me or just open a ticket [4].
Regards,
Andreas Stuhlmüller
[1] http://code.google.com/p/django-res
you can, wait at least until Fri, August 24th before using the REST
interface in any kind of production environment. By then I hope to
have done more thorough testing. If you stumble upon a bug, please let
me know.
Thanks for your feedback.
Regards,
Andreas Stuhlmüller
[1]
http://django
t you end up with is "work on your own, supported by your mentor"
(which, admittedly, works quite well).
Regards,
Andreas Stuhlmüller
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django d
l [2] that describes
how to provide an API for an existing Django application using the
REST interface. If you have any questions, ideas, can't get the
interface to work or want to contribute bugfixes and other
enhancements, please go ahead.
Regards,
Andreas Stuhlmüller
[1] http://code.goog
ld be interesting to use the given
> form_class instead.
You're right, it might be nice to be able to change the validation and
data cleanup behavior of resources. Check out the latest revision and
tell me if this is along the lines you were thinking.
Regards,
Andreas
--~--~-
tions or suggested features and, of
course, to the community of Django developers in general.
I hope you like and use the Django REST interface.
Cheers,
Andreas Stuhlmüller
[1] http://code.google.com/p/django-rest-interface/
[2] http://www.aiplayground.org/artikel/improving-django/
[3]
http://djang
rwise
everything is fast. You don’t have to remember any special command line options.
Cheers,
Andreas
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receivi
To me one approach would be to put a cut off for any merged code /PR start
inlining type hints/annotations for all new code. This seems to simple to
be a solution but at the end of the day as code gets updated even
bigger part of the codebase will have type hints. The question is whether
parti
I agree with you, but at some point, we could combine solid annotated core
with a cut off for non annotated code? Otherwise, this will end up being a
loop.
On Wednesday, 11 April 2018 17:16:21 UTC+3, dmoisset wrote:
>
>
>
> On 11 April 2018 at 11:21, Andreas Galazis > wrote:
it be designed in som other
way? I could not find any previous discussion/tickets on this and thought it
would be a good idea to discuss it here before opening a ticket or making an
attempt at a PR. :)
Cheers,
Andreas
--
You received this message because you are subscribed to the Google Groups
aware of multiple
keys. Everything that is already using django.core.signing such as signed
cookies, sessions and password reset tokens would need *not* need to change.
Cheers,
Andreas
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contri
On 10 Nov 2018, at 13:29, Adam Johnson wrote:
>
> Hi Andreas
>
> I like your proposal, moving to a backend is an elegant way of solving both
> the immediate problem and opening up the other possibilities you mentioned.
Thanks Adam, I am glad you like the proposal. :)
> I t
Just stumbled on this blog post:
https://www.willmcgugan.com/blog/tech/post/adding-type-hints-to-the-django-orm/.
An interesting but too theoretical suggestion: We could even get rid of
field/ field configuration. But I guess that's far ahead of what we are
trying to achieve xD.
On Wednesday,
3 -m timeit -s "import sys, os; sys.path.append(os.getcwd()); from
datetime_heuristic_parser import datetime_heuristic_parser”
"datetime_heuristic_parser('04/12/2018 09:7:4Z’)"
Cheers,
Andreas
--
You received this message because you are subscribed to the Google Groups
t(online__exact=False)
>>> articles.Klass._meta.where_constraints = original_constraints
But is this safe or will it eventually cause problems?
Andreas
plementation for
magic removal, the sooner the better. If there is anything I can do to
help just drop me a note.
Andreas
efault query
sets. See
http://code.djangoproject.com/wiki/RemovingTheMagic#YoucanoverridedefaultQuerySets.
Using python parameters instead of SQL is a nice improvement over the
where_constraints method.
Andreas
ssions into the auth_* tables.
nothing happened.
how does it differ from the default branch?
Thanks for the hint
Andreas -- http://andreas.neumeier.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Dj
, rev 2917.
Regards,
Andreas
http://lovebox.ath.cx
--~--~-~--~~~---~--~~
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 unsubsc
apper), which looks that it works perfectly. rev 2917 on Breezy seams
to fail for some reason i cannot describe. Where could I have a deeper
look? Does django depend on certain mod_python versions?
Adrian Holovaty schrieb:
> Hi Andreas,
>
> RequestContext is working perfectly for me. If
Adrian Holovaty schrieb:
> Does the problem happen on both the Django development server and mod_python?
Actually, this didn't come to my mind before, but I tried it just now
and the development server is working
What could be the issue there?
--
Andreas
lovebo
[EMAIL PROTECTED] schrieb:
> Isn't this just a mysql libs in php vs libs in mysqldb issue?
> Died silently with a blank page until i switched to postgresql.
> Or recompile php correctly yourself.
I'm not quite sure about the meaning here: why should I compile php
_at_al
is quite hard since there are no
errormessages at any point :(
I would be glad, if anyone could point out to any possible issue here
--
Andreas Neumeier
lovebox.ath.cx
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&
74 matches
Mail list logo
