Hi,
On 04/03/16 07:00, 'Moritz Sichert' via Django developers
(Contributions to Django itself) wrote:
Hello,
I want to propose a refactor of the Form class to make it
easier to customize and subclass.
I've recently had thoughts in this direction, so seeing your post
intrigued me...
Howeve
Hi
On Thursday, March 3, 2016 at 9:00:47 PM UTC+1, Moritz S. wrote:
>
> For example, it's conceivable that the form data doesn't
> come from a HTTP request with x-www-form-urlencoded or
> multipart/form-data content but gets transferred as JSON. In
> this case it should be easy to replace the H
I’m not too keen on a contrib.pg field. CharField is the base class of many
fields, a __init__ kwarg approach such as max_length=None allows us to reach
those as well.
> On Mar 5, 2016, at 3:05 AM, Marc Tamlyn wrote:
>
> Voting:
>
> 1) should there be a default?
>
> I'm lazy, so I would be h
I was happy to read that part of the Mozilla Open Source Support program
funding that was recently awarded to the Django Software Foundation will go
toward integrating key components of Django REST Framework into Django.
Since I haven't found any update since the initial announcement in
Decembe
Rather than guess at the appropriate string length to get some level of
security, I'd like to add a (minimum) bits of entropy argument to
get_random_string, so I could say something like get_random_string(bits=256)
and have it do the math for me: math.ceil(bits /
math.log2(len(allowed_chars))).
I don't what all updates to be in one commit each so I can't wrap just the
update with a atomic block I would need to have it over a bigger chuck of
code. That chunk might call a subrutin that also needs a commit and if I
wrap that update in a atomic block that atomic block is nested and results
Please read https://code.djangoproject.com/
On Friday, March 4, 2016 at 4:47:39 PM UTC-5, Cristiano Coelho wrote:
>
> Where do I get an account for Trac tickets? :) I guess I should still open
> a ticket first
>
> El viernes, 4 de marzo de 2016, 18:31:41 (UTC-3), Tim Graham escribió:
>>
>> Sure,
Where do I get an account for Trac tickets? :) I guess I should still open
a ticket first
El viernes, 4 de marzo de 2016, 18:31:41 (UTC-3), Tim Graham escribió:
>
> Sure, I mean... my impression as indicated by the lack of response to the
> thread is that no one provides much expertise in javasc
If you do what Simon and I suggest, you should get the result you just
described. If you don’t, please explain what happens.
Within a transaction — and disabling autocommit means you’re within a
transaction — transaction.atomic() uses savepoints.
Note that in Django 1.6, after set_autocommit(Fa
Sure, I mean... my impression as indicated by the lack of response to the
thread is that no one provides much expertise in javascript_catalog() these
days (although it's only been a couple days). I don't use it myself so I do
my best to review proposed changes and then we wait for bug reports. M
Try emptying your __init__.py file -- its contents aren't necessary and
"import apps" may be causing the problem.
In the future, please use django-users for usage/debugging questions like
this. This mailing list is for discussion about the development of Django
itself. Thanks!
On Friday, March
Whoops. Wrong list. Sorry about that.
On Fri, Mar 4, 2016 at 1:18 PM, Becka wrote:
> Hi,
>
> I'm building a pretty basic CRUD application for a community I'm part of.
> I'm now getting "ImportError: No module named [myappname]" when I run the
> server, and an operational error in the admin.
>
Hi,
I'm building a pretty basic CRUD application for a community I'm part of.
I'm now getting "ImportError: No module named [myappname]" when I run the
server, and an operational error in the admin.
I looked at the documentation, and followed the steps, but I'm not doing
something correctly. I'd
Would a pull request be accepted? Does it need to be a new branch even if
the change is just a few lines? Does it need an open ticket first?
El martes, 1 de marzo de 2016, 22:26:00 (UTC-3), Cristiano Coelho escribió:
>
> Looking through git history seems like the "always load english
> translati
As it so happens, someone else ended up tackling this problem for a
different use case in https://github.com/django/django/pull/6233.
There's a small design discussion on the pull request about how to
structure OPTIONS (possibly deprecating the current behavior of pylibmc
that passes them direc
Hi, Simon
No, I would need to wrap everything i a atomic block to start the
transaction and it's only when that outermost atomic block exits that I
actually get a commit the nested ones just makes save point.
/Tore
Den fredag 4 mars 2016 kl. 21:09:17 UTC+1 skrev charettes:
>
> Hi Tore,
>
> Is
Hi Tore,
Is there a reason you can't simply wrap your updates in a
`transaction.atomic()` blocks?
You should be able to avoid deadlocks and control exactly when data is
written to disk
with this construct.
Simon
Le vendredi 4 mars 2016 15:02:45 UTC-5, Tore Lundqvist a écrit :
>
> Reply to com
Voting:
1) should there be a default?
I'm lazy, so I would be happy to have one. Where validation matters you can
change it, where it doesn't you don't have to. I'd draw an analogy to
(Positive)(Small)IntegerField - I often use the normal one when I mean some
variant of validation, or some other
Reply to comments in ticket:
https://code.djangoproject.com/ticket/26323#comment:10
Hi,
@Aagustin: I get your point but in the code I'm working on there is a lot
of transaction.commit(), not to handle transactions but to manage when data
is written to disk and to avoid deadlocks. Running in a
One of the other reasons why contrib.postgres is in core is that it
required some changes to internals of the ORM. It's possible that all of
those we need are done now (except custom indexes) - is there anything
about contrib.mysql which would benefit from this?
I'm happy for JSONField to be made
I agree regarding choosing the most most useful bits. When we discussed
this at DUTH I did mention that there were some features that would be very
difficult to get included in Django. I guess you'd have to consider whether
or not you'd be willing to move features from django-mysql into contrib
Hi,
I will be working on preparing a proposal for sql-alchemy support on
django. [thorugh model meta].
Thanks
On Wednesday, September 16, 2015 at 2:35:15 PM UTC+6, Asif Saifuddin wrote:
>
> Hi,
>
>
> How much difficult it will be to add SQLalchemy support to django? what
> are the technical d
22 matches
Mail list logo
