On 2/3/07, Ivan Sagalaev <[EMAIL PROTECTED]> wrote:
> - Turn Field.get_choices into a generator. It now actually fetches rows
> and wraps them into a list and adds a 'blank' choice.
> - Allow a callable in 'choices' param of a Select widget that will be
> called on 'render'. It then can be passed
On 2/4/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 1. Full if support - if/elif/else with python access - It could be
> done in the view but making a loop in view and second one in template
> isn't a nice solution.
As far as I know, support for arbitrary Python expressions in
templates (wh
I just noticed a couple tickets posted tonight by Brian Harring which
look like they'll need some discussion before a clear decision can be
reached on them; since he's raised some good points, I thought I'd
point them out so we can get that discussion going:
http://code.djangoproject.com/ticket/3
On 2/6/07, Graham King <[EMAIL PROTECTED]> wrote:
> I also use AWstats for this, except when marketing people are involved
> then I tend to use Google Analytics. It provides pretty much the same
> information but keeps them busy longer :-)
Analytics is good stuff. Certainly an improvement over
Forwarding this here, because the problem would go away if we could
get some attention on ticket #3185:
http://code.djangoproject.com/ticket/3185
-- Forwarded message --
From: Mike H <[EMAIL PROTECTED]>
Date: Feb 7, 2007 6:16 AM
Subject: passing arguments to the login_required
With the recent talk of things that need to get done before 1.0, I
think something that'd be great to hit is a list of the thing which
most commonly confuse new users, or which they have the hardest time
figuring out -- getting that information into the official docs would,
hopefully, save a lot o
(unrelated to the other message about documentation I just sent)
After seeing Malcolm mention it in a blog comment, I got to thinking
about the various "developer-ish" things in Django that currently have
no documentation, but are still useful to folks who know what they're
doing -- Malcolm's wri
On 2/8/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Since SHA-1 was recently found to have some collisions, and since sha
> is deprecated in Python 2.5 in favor of hashlib, should an attempt to
> import hashlib be added to contrib.auth.models (both check_password
> and set_password) so when Python
On 2/8/07, TR <[EMAIL PROTECTED]> wrote:
> Which would be right, if you couldn't use a broken hash algorithm to
> login without the right password, but something that just generates
> the same hash - in other words, knowing the hash (poking at the db,
> SQL injection, anything) you don't need the
(moving to django-developers since that's where this sort of discussion belongs)
On 2/9/07, Jon Colverson <[EMAIL PROTECTED]> wrote:
> Adrian and Jacob didn't think that it was worth posting to
> django-announce about it, since it only affects newforms. The
> justification given was that newforms
On 2/8/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
> But set_password will only set a sha1 password. So why would the
> global check_password need to check if the algo is 'md5' if
> set_password could never use md5?
Django used to use MD5 hashes; that function is in there so that an
old installati
First thoughts: subjectively, I'm not sure it'd be any prettier than
what we have now. I'm also wary of overloading the concepts of the
standard Python operators when whet we're really doing is translating
to SQL operations -- sooner or later, there's going to be an impedance
mismatch.
I'm also n
On 2/12/07, zbelzer <[EMAIL PROTECTED]> wrote:
> The question I have is where does one begin on figuring out how things
> work in detail (behind the scenes) and where I should start in trying
> to contribute. Do I try to follow the execution of something like
> syncdb or do I start somewhere else?
On 2/16/07, Rob Hudson <[EMAIL PROTECTED]> wrote:
> Cool. I was looking at how I'd do this but I wouldn't have known
> about the add_to_class in __new__.
There are some notes on the wiki about how the model system works,
useful for anyone who wants to venture in there and patch stuff:
http://co
On 2/16/07, jfagnani <[EMAIL PROTECTED]> wrote:
> It'd also be nice if fields had an 'error' property, so that you could
> do some things in the template like {% if field.error %}
You can do this in the template as
{% if form.fieldname.errors %}
...special stuff here to highlight the field...
{{
On 2/17/07, Gary Wilson <[EMAIL PROTECTED]> wrote:
> I can't speak for other developers, but I'm just looking for some
> direction on where to focus my spare time in the days leading up to
> the sprint, as I would like to see 0.96 get out the door.
I've got a list of stuff that we're holding on;
On 2/17/07, Simon G. <[EMAIL PROTECTED]> wrote:
> I've gone on a bit of a triage rampage tonight (..and this morning),
> and there are many tickets regarding edit_inline bugs, and there are
> *many* more that are marked as dupes. If someone can fix this up a
> bit, this will clean out a lot of bug
On 2/20/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> 'context processor' sounds more difficult than it is. That's how it's
> actually done:
>
> from django.conf import settings
>
> def processor(request):
> return {'MEDIA_URL': settings.MEDIA_URL}
>
> ... and then add it to TEMPLATE_CONTEX
On 2/21/07, Matias <[EMAIL PROTECTED]> wrote:
> I need to create a comment system in wich could be made per-reply
> replies, I mean something like slashdot's one, and add some features
> like mail notifications and so on.
You can already do comments on comments, actually -- a comment can
"attach"
I've gone ahead and added a patch to this ticket which adds
'django.core.context_processors.media' and places it in the default
TEMPLATE_CONTEXT_PROCESSORS tuple (and documents the new processor and
its inclusion in the default setting). The context processor simply
adds the values of the ADMIN_ME
On 2/21/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> Regarding ADMIN_MEDIA_PREFIX however there is already a way to do
> this:
> Not sure if it's documented but there is a template tag in
> contrib.admin.templatetags.adminmedia which provides this
> functionality already, do we want to be doubling
On 2/25/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> Let's stop going down this path. This isn't a thread about whether to
> switch to SQLAlchemy. If you want to work on that, there is a branch
> already created and a maintainer appointed for that branch. I've got
> nothing against it, but
Upcoming Django release, and the future
As we sit here in warm, sunny Dallas, meditating on how next year's
PyCon will be in cold, cloudy Chicago, we're also getting ready to
push out a new release of Django, and with that there are some things
you all need to know, and as your friendly neighborh
On 2/26/07, Espen Grindhaug <[EMAIL PROTECTED]> wrote:
> I got a little suggestion, and I think a lot of people agrees with me:
> how about trying to merge one or two of the 100 development branches
> into trunk.
We can only merge a branch when it's done, and unfortunately there
aren't many branc
On 3/1/07, David Larlet <[EMAIL PROTECTED]> wrote:
> What about bug #2282? What's the actual status? A patch is proposed,
> it doesn't suit any case but it's a good start for a part of the
> world.
It still needs a discussion and decision about how far we want to go
to support (essentially) arbit
On 3/1/07, Kai Kuehne <[EMAIL PROTECTED]> wrote:
> Could you decide on whether to name the attribute maxlength or max_length?
> Well... it's not *that* important but it this is ugly, imho.
AFAIK it will be migrated eventually to being 'max_length' everywhere,
but probably not for this release bec
On 2/27/07, Bas van Oostveen <[EMAIL PROTECTED]> wrote:
> As with js u can add some javascript to fields of your choosing, an added
> option
> css would let u add a file with the 2 extra .imgfoo {} and .imgbacon {} css
> classes.
I think one of the goals of the admin reworking is that it'll be ea
On 2/28/07, Nicolas Steinmetz <[EMAIL PROTECTED]> wrote:
> I added the following piece of "code" in settings.py (is it the right
> place ?) but it does not work (it looks it's not take into account with
> django svn 4643).
>
> ABSOLUTE_URL_OVERRIDES = {
> 'cab.Language' : lambda o: "/snippets/
On 3/5/07, Jeroen van Dongen <[EMAIL PROTECTED]> wrote:
> Then I proceeded and closed a ticket as 'wontfix', with the resulting
> discussion as can be seen in http://code.djangoproject.com/ticket/2415
I don't think we have or really need an "official" policy on it, but
I'd personally *prefer* tha
On 3/7/07, Phil Powell <[EMAIL PROTECTED]> wrote:
> It renders a new Django installation on Python 2.3 pretty unusable,
> which could be a kicker for any newbies.
>
> Is this the right place to flag things like this?
Yes, but note that Malcolm committed a patch for it, so Django itself
should be
On 3/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> You may be unlucky here in who chose to respond. There's evidence to
> suggest that I'm more of a hard-ass on this front than the other core
> developers, but only by a little bit.
Bah. Now I have to respond, because I've got a reputation
On 3/9/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> How close are we to tagging the tree for 0.96?
Close :)
There are still a couple bugs to be knocked off, and a couple
documentation things I'd like to see shored up, though.
And since this release is going to be the recommended stable v
On 3/8/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> The main reason I suspect it hasn't been resolved one way or the other
> is in Russell's comment #23 in early March: it's become a nest of
> competing implementations, which is never an easy thing to untangle.
> Having discussion in bugs i
On 3/9/07, Tristan <[EMAIL PROTECTED]> wrote:
> Do you have news about Oracle Sprint stuff? Will this be included in
> 0.96?
For a major feature like that, the answer to "when will it merge into
trunk" is actually a set of further questions :)
Have people used it and found it to be stable?
Does
While working on a small personal project I've run into a bit of a
wall because I'd like to use a third-party module which looks for
information about HTTP requests. It doesn't know (and shouldn't need
to know) about Django's HttpRequest object, and simply looks for the
things it wants in os.envir
On 3/11/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> [Insert standard rant about components intended to be reusable that do
> not provide an alternative way to specify the environment. Makes testing
> kind if hard. Their developers are probably cruel to small animals as
> well.]
:)
In thi
On 3/11/07, Max Battcher <[EMAIL PROTECTED]> wrote:
> Anyway, I think my suggestion is that in this particular case maybe
> the better approach is to push for better genericity in the Comments
> app (particularly as it gets rewritten and better documented)...
I've done that, actually :)
Right no
On 3/12/07, ouds <[EMAIL PROTECTED]> wrote:
> if in j2ee or nomal html file, i can define in table as style="behavior:url(/htc_path/js/TableSort.htc) url(/htc_path/js/
> TableHL.htc) url(/htc_path/js/DragDrop.htc);">
Django outputs HTML the same way as any other system; the only thing
you need t
On 3/13/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> Anton Khalikov opened a new ticket pointing out a hole in the current
> session framework which can cause session id collisions.
The proposed solution for collision (more on that in a moment) seems
good -- the bug seems to happen solely because
On 3/13/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> a) the client can sit behind a NAT that might hand out different IPs
> b) the server can be behind NAT and not see the true IP at all. It
>might see different IPs for the same client over time.
> c) a crazy load balancer might get in the
On 3/13/07, ak <[EMAIL PROTECTED]> wrote:
> 1. REMOTE_IP. I think it is a good idea to check it. Load balancers
> acts as proxy servers. Every web server has a module that allow to
> restore REMOTE_IP from X-FORWARDED-FOR, for example apache's module is
> called mod_rpaf. And ofcourse it's very ea
On 3/14/07, ak <[EMAIL PROTECTED]> wrote:
> 2. I have an ethernet connection @home and I sometimes log in to our
> private web apps from home. Any 'c00l hacker' is able to scan network
> traffic, get my session id and use it to join to my session too just
> because there is absolutely no checking
On 3/14/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> 2) James has suggested that the answer is, perhaps, better seeding. I
> really don't think that this is an issue. Regardless of the seed,
> there is still a mathematical chance that a collision will occur.
This is true, but given the rang
On 3/14/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> If you have multiple processes which initialize their random
> module at exactly the same system time (how granular is it?, you'll get the
> same seed and therefore the same sequence of pseudorandom numbers in
> python2.3
>
> In python2.4, t
On 3/14/07, Arvind Singh <[EMAIL PROTECTED]> wrote:
> What I don't understand is: Why the developers don't do the correct
> thing by providing separate insert() and update() in addition to
> save() ? All it requires is a trivial refactoring and actually
> simplifies the code (also clarifying the i
On 3/14/07, Benjamin Slavin <[EMAIL PROTECTED]> wrote:
> Do we really need to re-seed the RNG? What if we did something like:
> session_key = md5.new("%x%s%s" % (random.getrandbits(64),
> datetime.datetime.utcnow(), settings.SECRET_KEY)).hexdigest()
That works too :)
I'm just wanting anything w
On 3/15/07, Michael Radziej <[EMAIL PROTECTED]> wrote:
> The point is: It's not possible to extend the session in a
> upwards-compatible way, because there's no way to make sure
> that INSERT is used when you need to set the pk before save().
Again, I'm not disagreeing with the INSERT/UPDATE sugg
On 3/19/07, frank h. <[EMAIL PROTECTED]> wrote:
> My questions are:
> - who is maintaining this oracle branch and how can I get in touch
> with them (I looked on the wiki but found no branch homepage, this
> would maybe be a good idea to create?)
> - can somebody look at the SQL I get from man
On 3/20/07, Brad Fults <[EMAIL PROTECTED]> wrote:
> Is there a specific reason that newforms' Fields are using an
> inconsistent name? If not, I suggest that these all be normalized to
> "maxlength" and "minlength".
Actually, the plan over the next couple releases is to normalize to
"max_length"
On 3/21/07, Emeka Mosanya <[EMAIL PROTECTED]> wrote:
> Is there any update about the SQL Alchemy integration ?
> I have checked out the sqlalchemy branch but there is not reference to SQL
> Alchemy in it.
It's sleeping right now. The upcoming refactoring of Django's QuerySet
mechanism looks like
On 3/21/07, jbronn <[EMAIL PROTECTED]> wrote:
> Is there any place (e.g. a trac page) where interested parties can
> check out the progress on the QuerySet refactor? Since I recently
> completed PostGIS integration for the GeoDjango branch (will be
> committed to SVN branch pending Jeremy Dunck's
On 3/25/07, Jonas Maurus <[EMAIL PROTECTED]> wrote:
> man, now I feel stupid :-). I didn't realize that someone already
> implemented this and the size of the middleware-class clearly suggests
> why it's the right decision to do it this way. Thanks for your quick
> reply.
Yeah, the middleware's a
On 3/25/07, David M. Besonen <[EMAIL PROTECTED]> wrote:
> at first glance it does not appear that django users can
> contribute to the documentation at:
The documentation is managed in Subversion, same as the code, so the
same process for contributions works for either one (and documentation
patc
On 3/29/07, Ted <[EMAIL PROTECTED]> wrote:
> Were I work we have had to do this very thing to support I18N in our
> forms. Something as simple as a ":" is not a given. Maybe I want a
> " :" instead? This could be a form parameter or even a locale setting.
FWIW I think the ideal would be for the d
On 3/29/07, Noah Slater <[EMAIL PROTECTED]> wrote:
> I have been instructed by mtredinnick to bring the discussion here.
>
> Can someone please justify why this wont be fixed?
See also this thread from earlier today which covers some
technical/performance reasons:
http://groups.google.com/group/
On 3/29/07, topper <[EMAIL PROTECTED]> wrote:
> Still, $HOME is a normal UNIX environmental variable, and because
> Django does use those in other places (i.e django_settings), a user
> could think that environment variables are accessible from Django. And
> when the user is told in Template loade
I was looking over some of the things in localflavor this morning, and
noticed that for a couple of countries there are already pretty good
validation routines for social security numbers (or locally-named
equivalent), which got me thinking I'd write one for US SSNs.
So my question, from a Django
On 3/31/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> Ok. I'll wait a day or two to make sure there aren't any late
> objections but otherwise go ahead with making spaceless actually
> spaceless.
I'll give it a +1; having "spaceless" really mean "well, kind of
spaceless but not really" see
On 3/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> As far as SSNs, we should validate format and maybe some versions
> that are obviously wrong (000-00-, etc) but otherwise I think if
> it is too smart, then it gets to be a pain to manage. If I really
> need to collect SSN's or some
On 4/1/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> How does that sound as a policy?
Sounds good to me. Based on that, I'll whip up a US SSN field, and I
think that following this it will:
1. Validate the number of digits (9).
2. Validate that the number is not one which is known to be
perma
On 4/1/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> Sounds good. You've probably already thought of this, but it should
> accept numbers with or without hyphens, and normalize it to the number
> *with* hyphens.
Ha. Uploaded a patch right before I saw this; it's late and I didn't
think of it,
On 4/1/07, David M. Besonen <[EMAIL PROTECTED]> wrote:
> Django needs an equivalent to Mongrel
> http://jyte.com/cl/django-needs-an-equivalent-to-mongrel
>
> are there any other possibilities on the horizon besides Aspen?
Mongrel is not Rails-specific; it's meant to run any Ruby application.
Ther
At the moment, BaseForm.as_table() does a fairly good job of
presenting the form cleanly, but I think there are a couple things
worth tweaking.
Consider a simple example form:
class SampleForm(forms.Form):
name = forms.CharField()
Calling as_table() will print out an instance of this form l
On 4/3/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
> 1. app_label, model_name = settings.AUTH_PROFILE_MODULE.split('.')
> 2. model = models.get_model(app_label, model_name)
>
> First, it does not behave properly if the settings.AUTH_PROFILE_MODULE
> is something like 'path.to.app.models.Profile'.
On 4/4/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
> Well, User do nothing with the profile other then simply loading it in
> get_profile.
Except that 'get_profile' uses a Django database API lookup. Suppose
we remove that, though:
1. How do we know what sort of object the "profile" is?
2. How
On 4/4/07, Max Derkachev <[EMAIL PROTECTED]> wrote:
> That's not a problem. The API lookup can be easily emulated in custom
> class. The problem is that it tries to load the profile from django's
> internal models cache, and that can't be easily emulated. One needs to
> cheat django the hard way f
On 4/4/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
> I can work around this problem in a messy way in the deserializer by
> manually resetting the sequence to the largest PK value that was found
> during deserialization, but that isn't really clean, and doesn't fix
> the manual allocation p
On 4/7/07, Noah <[EMAIL PROTECTED]> wrote:
> I'm worried about a trend I've seen before in other frameworks etc.
> They start off easier to use and over time get more and more
> generalized and then become so general and so academically correct
> that there is no point in using them because they'r
On 4/12/07, jp <[EMAIL PROTECTED]> wrote:
> That doesn't make a whole lot of sense to me. I would think that with
> the newforms admin stuff it would be an ideal time to completely
> remove all display-related information from the models. It really just
> doesn't belong there.
What "display-relat
On 4/12/07, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> The options that apply to the admin interface have been factored out
> as options to the admin class. Here's more information:
Since it doesn't seem to have come under the axe yet, I'd like to go
ahead and suggest that 'choices' stay in the
On 4/13/07, Anders Olsson <[EMAIL PROTECTED]> wrote:
> portable and decoupled from the project where it is used. But doesn't
> the project being the top level python package make it almost
> impossible to move an app from a project to another without modifying
> the import statements?
If you insi
Short and sweet: since we're already planning some
backwards-incompatible changes for the next release, how about we
hammer out auto-escaping of template output while we're at it? Even
those of us who don't like it (myself included) are probably at the
point of accepting that we have to do it even
On 4/16/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> On or off by default seemed to be the only debate (and it's not really a
> debate -- Adrian didn't like it).
I don't *like* it, but I've come around to accepting that it's better
for us not to point the gun at a developer's foot and say
On 4/18/07, SmileyChris <[EMAIL PROTECTED]> wrote:
> I can also see a solution which would maintain backwards compatibility
> for old sites:
> TEMPLATE_AUTOESCAPE=False in conf.global_settings
> TEMPLATE_AUTOESCAPE=True in conf.project_template.settings
I'd be against this; any solution which has
On 4/22/07, Florian Apolloner <[EMAIL PROTECTED]> wrote:
> I would like to be able to do something like this:
> http://groups.google.at/group/django-users/browse_thread/thread/62ef2b417fad1b8d/532c9b3fdf2ad36d
>
> Any chance to get this into the new admin?
Please keep in mind when suggesting feat
On 4/23/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Why isn't patch #2070 added to trunk yet? The current patch(es) won't
> work with trunk either. Is this "in the works"?
>From a quick glance at the discussion in the ticket, it appears that
there hasn't been much activity on it since arou
On 4/23/07, Joseph Perla <[EMAIL PROTECTED]> wrote:
> I understand where you are coming from. However, I do not think I am
> stepping out of bounds. The patch is self-contained, has proper
> documentation, has been accepted, has been tested, is clearly labeled ready
> for check in, has been revi
On 4/26/07, tonnzor <[EMAIL PROTECTED]> wrote:
> This feature is demanded and it is easy to implement w/o side effects.
> We should do it.
The ticket for this has been closed multiple times and Adrian has
asked that it not be reopened. Malcolm has asked that this thread be
allowed to die. That se
On 4/28/07, David Larlet <[EMAIL PROTECTED]> wrote:
> I'm just curious about SoC, especially the REST one, listed on this
> page: http://code.google.com/soc/django/about.html
>
> Maybe it's time to make an "official" announcement?
Well, what would you like to know? ;)
I'm mentoring a project (th
On 4/30/07, Simon G. <[EMAIL PROTECTED]> wrote:
> We've warned people off using the svn version to run production sites
> because of the post-1.0 code breakage that's going to be happening.
> So, we don't need to worry as much about stability of trunk, since
> 0.96 is the stable, recommended versi
On 5/6/07, Honza Král <[EMAIL PROTECTED]> wrote:
> I know Jacob was planning on rewriting the comments framework to work
> with newforms. Is there any work done there?
I believe the plan is -- much as with newforms-admin -- to take
advantage of the rewrite and build more flexibility into the comm
On 5/9/07, foobarmus <[EMAIL PROTECTED]> wrote:
> It's a tightly modelled, configurable, business administration tool.
> If used in a business of significant size, I would expect and hope
> that a DBA was employed to administer the database. Many of the tables
> will contain information that is re
On 5/10/07, foobarmus <[EMAIL PROTECTED]> wrote:
> Unfortunately, pushing access control up the stack means I
> have to rewrite all the functionality has been carefully and
> comprehensively facilitated by my RDBMS. Also it means that access
> control logic has to be written into every app that co
On 5/10/07, Sebastian Macias <[EMAIL PROTECTED]> wrote:
> Do any of you guys when the django-admin.py updatedb command will be
> completed? updatedb is basically all django is missing for me and many
> developers at the company I work for to abandon CakePHP and move to
> django.
As far as I know,
On 5/15/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote:
> Will there be a branch for the SoC work?
If a student wants a branch, I'm sure we'll provide one, but we won't
force it on them; it should be up to each student/mentor pair to
decide how best to manage their project (I'm mentoring one, for
exa
On 5/15/07, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
> It's probably more important to check the web page than follow the
> developers' list, I would say. It's a bug if we don't update the webpage
> after a real incompatible change.
I've posted a followup reminder to django-users about this,
On 5/18/07, Jason Davies <[EMAIL PROTECTED]> wrote:
> Is there any way around this, or is it just something inherent to
> Python?
Personally, I think the sanest way to handle a standalone app is to
assume it'll be directly on the Python path and build around that
idea; asking people to install in
On Wed, May 11, 2022 at 2:21 PM Yonas
wrote:
> What does the community think about adding a feature to Django where
> disposable or temporary emails are not accepted during account registration?
I used to try to do this in my django-registration package, but eventually
gave up on it because mai
On Thu, Jul 14, 2022 at 4:09 PM Dave Gaeddert
wrote:
> Yeah, I hope I'm not coming off as being too pushy, but I'm just curious
> why that is. Mariusz or Adam, did what I said about it being *more* than
> just an alias for `filter().first()` make sense or am I missing something?
> (Different beha
On Sun, Jul 24, 2022 at 10:06 AM Ofek Lev wrote:
> Hello! This is about using only `pyproject.toml` for packaging
> https://github.com/django/django/pull/15874
My initial reaction is "no", and that this request kind of rubs me the
wrong way. In the pull request you say:
> As a result, the exec
On Sun, Jul 24, 2022 at 1:34 PM Ofek Lev wrote:
> > My initial reaction is "no", and that this request kind of rubs me the
> wrong way. In the pull request you say [...] But the blog post you quote is
> just saying to run "python -m build" instead of "python setup.py"
>
> This issue is that the `
On Mon, Jul 25, 2022 at 8:04 AM Ofek Lev wrote:
> Can we please quantify such heuristics? I want something concrete to write
> in my OSS to-do list :)
>
I don't think we can or should provide an exact number of other projects
that need to adopt what you're doing before we will. It's more of a "w
I see a lot of people mentioning that other ORMs do validation, but not
picking up on a key difference:
Many ORMs are designed as standalone packages. For example, in Python
SQLAlchemy is a standalone DB/ORM package, and other languages have similar
popular ORMs.
But Django's ORM isn't standalone
On Thu, Oct 6, 2022 at 9:00 AM Aaron Smith wrote:
> James - The problem with moving validation up the stack, i.e. to logical
> branches from Model (Form, Serializer) is that you must duplicate
> validation logic if your data comes from multiple sources or domains (web
> forms *and* API endpoints
On Fri, Oct 7, 2022 at 6:21 PM Aaron Smith wrote:
> Mariusz - fair enough, I will consider my point made and apologies if it
> came off too strong. FWIW it's not just my opinion, it's shared by every
> developer (dozens) I've had this conversation with up until now. It's a
> stark contrast that m
On Sat, Oct 8, 2022 at 8:44 AM Aaron Smith wrote:
> The reason I don't want to use serializers or forms in celery tasks is
> because validation should happen every time a model attribute is changed.
> This pattern would mean more imports and boilerplate scattered around my
> codebase any time I w
On Sat, Oct 8, 2022 at 8:32 PM Aaron Smith wrote:
> Surely we can agree that *something* should happen here? The status quo
>> is confusing, a footgun and a gotcha. If it's not Model's concern, then get
>> it out of Model.
>>
>
I've already said that I wish model-level validation hadn't been adde
On Wed, Oct 12, 2022 at 3:25 PM 'Adam Johnson' via Django developers
(Contributions to Django itself) wrote:
> Thank you for diving into this John! All seems sensible then.
>
Yeah, the threat model here is you have, say, Endpoints A and B that each
work with HMAC'd values, and Endpoint A generate
Something I note here is that it's presenting a solution, but not clearly
(at least, from my reading) presenting the problem to be solved.
Is it a lack of people proposing features? If so, I'm not sure this helps
-- it would, to me, suggest that only members of the Technical
Board/Steering Council
On Mon, Oct 24, 2022 at 2:24 PM Andrew Godwin wrote:
> Proposing features - this is already in DEP 10, so I more just want to get
> that aspect of the Board actually going (and, as a side-effect, have
> something to aid fundraising). I am talking with the current Board
> separately on an internal
301 - 400 of 1014 matches
Mail list logo
