On Sep 16, 2005, at 2:19 PM, Eugene Lazutkin wrote:
+1 from me.
Me three.
Additionally, we should make the manipulator methods work the same way::
class MyModel(meta.Model)
f = meta.CharField(...)
class META:
...
class MODULE:
...
On Sep 19, 2005, at 11:39 AM, Robert Wittams wrote:
Well, I'm not an author of the framework, but the admin code is very
hard to understand (imo). I'm sure the authors understand it fine, but
for open source to instill confidence clarity is key. The admin view
should be a great example to djang
On Sep 19, 2005, at 1:42 PM, Robert Wittams wrote:
The parts which I consider to be real hacks are the bits which just
plain don't work in generic views, and require huge messing around in
the view functions. Eg select fields do not pick up their values (
http://code.djangoproject.com/ticket/338
On Sep 19, 2005, at 3:21 PM, HBTaylor wrote:
For example, there are two tickets which come to mind
(http://code.djangoproject.com/ticket/337 and
http://code.djangoproject.com/ticket/338) which deal with things which
work correctly for firlds within admin but which don't for generic
views. There
On Sep 19, 2005, at 3:56 PM, Eugene Lazutkin wrote:
I would love to see an application, which looks at my models and
provide
different Admin UI --- current Admin provides all necessary basic
functionality but it would be nice to extend it even more for some
custom
apps. As soon as I have it,
On Sep 26, 2005, at 9:43 AM, Maniac wrote:
I'm a little confused about practices of working with Trac in
Django community and decided to ask here.
[snip]
So here are my questions:
- what is the best way to discuss decisions in tickets and
proposing patches? (I come from bugzilla.mozilla
hugo --
I like your plan of attack, and svn switching to the i18n branch
didn't cause any headaches for me, so likely we're good to go. I'd
like to take some time to review the branch and see if there's
anything we should discuss, but at first glance I'm blown away by how
awesome this i
Howdy folks --
I've had a chance to review the i18n branch, and here are my thoughts:
1. Awesome. Seriously, this rocks; all of my criticisms to follow
are trivial next to how cool this is.
2. Once this hits the trunk we'll need documentation about any
backwards incompatibilities this in
On Nov 2, 2005, at 6:51 PM, hugo wrote:
based on the ideas of Jacob and Robert and based on the discussion on
IRC tonight, I propose the following changes to the i18n branch:
[snip excellent proposal]
Great; this is exactly what I had in mind. As far as I'm concerned,
once these changes
Howdy --
I've merged the i18n branch into the trunk; major thanks are due to
hugo! I'm running it live on all the LJW sites and it works fine,
but there could be some lurking issues, so caveat programmer. Adrian
will have a blog post on the matter some time in the next day or two
(he's
I've fixed that problem; thanks for pointing it out, Luke.
Jacob
Howdy --
I'm about halfway done with an error middleware that handles this,
but my knowledge of how tracebacks/exceptions work is rusty. Can
anyone point me to information about how to extract the source code
context from a traceback frame? That's the only component I don't
have yet.
On Nov 8, 2005, at 10:13 AM, Adrian Holovaty wrote:
On 11/8/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
The general feeling from those using or considering Django (including
some rubyists) seemed to be "Release a 0.7 tarball, for the love
of all
that is holy!"
It seems that quite some peo
On Nov 8, 2005, at 11:08 AM, Adrian Holovaty wrote:
Here's what we should finish before this first 1.0 version:
* Transactions.
Agreed.
* New-admin branch.
What's the state of this branch? Last time I tried it out -- a few
weeks ago, IIRC -- there seemed to be a bunch more work to be d
On Nov 8, 2005, at 11:30 AM, Adrian Holovaty wrote:
I'd like to see a solution to "core=True" before 1.0 -- i.e., not
having to use that anymore. This goes beyond what new-admin offers,
and it would probably be a backwards-incompatible change (hence the
1.0 requirement).
That's a good point --
On Nov 8, 2005, at 2:33 PM, Ian Holsman wrote:
personally I'd like to see the user-registration app get
documented/released as well.
what is the state of this?
The registration app (as opposed to just the user module) is
currently part of our proprietary software package and I'm not sure
i
On Nov 8, 2005, at 3:41 PM, Robert Wittams wrote:
Ok, so this generated quite a bit of traffic.
Ha -- thanks for kicking this off; it needed to be discussed.
I *really* don't think that 1.0 should be considered on the basis of
stability and usability of the implementation. It should be on
On Nov 9, 2005, at 10:48 AM, Adrian Holovaty wrote:
Before we "release it to the masses," so to speak, we should take care
of a small, but important, set of features and fixes. That list is at
http://code.djangoproject.com/wiki/VersionOneFeatures . We'll leave
the list open for discussion until
Hey folks --
With Wilson's help I've mocked up some nice-looking error pages to
replace the ugly tracebacks when DEBUG is on. Right now they're
implemented as a middleware component, but I think they'd be best
rolled into the Django core -- good looking, functional error
messages by def
We'll have to think about how to fit the template debugging work I did
in new-admin into this as well
Ooh, this is nice -- I hadn't seen it before. I'll take a look at
your code and think about how the two could work together, but to
keep SVN conflicts to a minimum I won't actually integ
On Nov 11, 2005, at 9:32 AM, Wilson Miner wrote:
My conclusion is that app error pages shouldn't be wrapped in the
admin. I
think that's the right way to go, but I'm open to arguments to the
contrary.
I agree; they need to be as simple as possible to avoid re-raising
exceptions in the err
On Nov 11, 2005, at 1:54 PM, pbx wrote:
Actually, Ian's idea was part of my original thinking as well -- if
you
make "__exact" optional, you can completely remove "pk" (which is
itself a weird exception to the keyword rules).
Except if you remove "__exact" then you can't have fields named
Hey folks --
Man, it's fun having such smart and passionate people on this list!
I've been thinking about how Django might leverage DHTML^H^H^H^H^H
AJAX a lot recently, and I think the framework I'll sketch out below
should make a bunch of people happy.
As I see it, there are three layers
On Nov 14, 2005, at 4:34 PM, Adrian Holovaty wrote:
This is a good conversation, and I hope it continues.
Like ships passing in the night... :)
Jacob
Hey folks --
As some have pointed out in the past, there are some potential
pitfalls in the current way the middleware API works. As it stands
now, MIDDLEWARE_CLASSES is implemented as a stack: the middleware
bits are called in order on the process_request and process_view
phases, and i
On Nov 14, 2005, at 4:45 PM, Ian Holsman wrote:
I was also thinking of something a whole lot more simplistic as well.
javascript-enabling some of the validators.
I was planing on this being one of the web services views -- a
"validate" view that you would pass a new or modified object into
On Nov 14, 2005, at 5:05 PM, Ian Holsman wrote:
you might want to implement something similar to what apache2 did with
their hooks.
it sounds pretty complex, but in reality you hardly need to use all
the options.
1. define when the middle ware will be run .. FIRST, MIDDLE, or LAST.
2. define
On Nov 15, 2005, at 9:31 AM, Adrian Holovaty wrote:
On 11/15/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
It seems auto_now_add is not really recommended - LazyDate is. I'm
wondering if it is a sensible thing to keep around?
We should remove it, because it causes problems with the admin. (It
Hey folks --
We're looking for a volunteer to update and maintain Django's FAQ
(http://www.djangoproject.com/documentation/faq/). It's pretty
unhelpful at the moment, unfortunately. We'd love it if someone
could become the FAQ maintainer and keep it as cool as the rest of
the docs.
L
Hey folks --
We've wrapped up a 0.90 release of Django; let the Subversion-less
rejoice! http://www.djangoproject.com/weblog/2005/nov/16/
firstrelease/ has the full details, but suffice to say that we've now
got a tarball (and and egg for those who are into that sort of thing).
Enjoy!
J
Eugene --
Can you add this to the discussion on the wiki?
Thanks,
Jacob
On Nov 16, 2005, at 2:34 PM, Eugene Lazutkin wrote:
Will do. I was hoping that it would be discussed publicly before being
canned.
I didn't mean to "can" anything -- I think your assesment of what's
good about AJAX in Rails is quite useful, so I want it somewhere
slightly more prominent th
On Nov 17, 2005, at 7:05 PM, Ian Holsman wrote:
I thought this should be off-line.
Thanks for being sensitive, but there's no reason to and I think
other might be interested so I'm replying back to the list.
but have you guys thought about django's IP?
I see you have trademarked the name,
On Nov 18, 2005, at 1:55 PM, Adrian Holovaty wrote:
Thoughts?
+1 -- great call.
Jacob
On Nov 20, 2005, at 6:11 PM, Simon Willison wrote:
The idea is to make developers have to go out of their way to avoid
input filtering. This is certainly something that would greatly
benefit the world of PHP. Developers who use Django may like to
think themselves above such mistakes, but mi
On Nov 20, 2005, at 3:15 PM, Adrian Holovaty wrote:
On 11/20/05, Robert Wittams <[EMAIL PROTECTED]> wrote:
Ok. Now that we have the 0.9 release, shall we merge new-admin, and
people who are worried about short term stability can just stick with
the release?
Then, after it has stabilised in tru
On Nov 21, 2005, at 2:40 PM, Robert Wittams wrote:
I think thats a good set of features, but I would change the order a
little (just because of what I have done and what I think is already
done by others atm)
maybe
0.91: new-admin
0.92: transactions, OR stuff (hugo has these in reasonable shape
On Nov 22, 2005, at 7:36 AM, Krzysztof Drozd wrote:
it would by nice to have a new extra field in the django admin panel
thats can work as a publish un publish poll/site/... or
publish_on_date.
This is best done at the view level; an object is an object and the
database shouldn't know about
On Nov 23, 2005, at 8:22 AM, Simon Willison wrote:
He's right too - the hoops you have to jump through changing schema
with Django do slow you down if you haven't figured out your full
data model in advance.
Wow, so developing applications without a good design up-front is
difficult? Who
Hey Brent --
Thanks for your feedback.
However, as I see it, arguing about the syntax that an ORM should use
is just a rehashing of the argument over what color to paint the
bikeshed (http://www.unixguide.net/freebsd/faq/16.19.shtml). The
fact is that there's a serious mismatch between p
On Dec 2, 2005, at 11:05 AM, pgross wrote:
A bit off topic, but on our project, we run every parsed page through
xmllint to verify that it is valid XHTML (validates against the XHTML
DTD).
If you can do the same functionality at the template layer (in DEBUG
mode, of course), that would be reall
On Dec 6, 2005, at 12:28 AM, Adrian Holovaty wrote:
Finally, along those lines, we could introduce a vary_on_get
decorator, which, used with the NO_GET_PARAMS setting, would be an
opt-in signifying a view *does* rely on query string. This could be
for stuff like search engines, which do vary bas
Howdy --
My two bits:
* Class methods basically exist to mask dogmatic language design.
They make sense in languages with shitty namespace support (Java,
Objective-C) but they're lame in Python. Speaking as someone who has
taught a lot of people to program in a lot of languages: nobody
On Dec 6, 2005, at 1:38 PM, kmh wrote:
MODULE_CONSTANTS is ugly. Perhaps I should get over this, but I find
it so ugly that I often end up explicitly importing things inside each
method of my magic module. And that's pretty ugly too.
Note that this change would fix the MODULE_CONSTANTS hack.
On Dec 6, 2005, at 11:00 PM, Adrian Holovaty wrote:
http://code.djangoproject.com/wiki/RemovingTheMagic
* Model definitions (with properties, etc): +1; this is a no-brainer
* Database connections: -0; seems like name-churn to me; unless
there's a big reason to change the name let's just lea
On Dec 7, 2005, at 2:47 AM, Amit Upadhyay wrote:
How about supporting an SQL where clause, as seen in Rails?
FYI, you can already do this with the "where", "tables", and "params"
keywords; you just have to be a bit more explicit about it. See
http://www.djangoproject.com/documentation/db_
Hey folks --
Want to get paid to write Django apps? You know you do...
Well, we're hiring a Django developer, and I obviously want to hire
someone out of the community if at all possible. Full details are at
http://www.jacobian.org/2005/dec/07/job/; drop me an email if you're
interested
On Dec 8, 2005, at 7:07 PM, Lachlan Cannon wrote:
Is there a reason we use a DoesNotExist rather than just
using a
single ObjectDoesNotExist exception for everything?
Yes.
Consider::
try:
do_something_that_involves_multiple_models()
except ModelOneDoesNotE
Hey folks --
I've been thinking about this proposal for a while... First, in the
interest of full disclosure I've got to say that's it's difficult to
accept something like this knowing that I'll need to change thousands
of lines of code... I'll try to set that aside, though.
I think all
On Dec 13, 2005, at 8:15 AM, [EMAIL PROTECTED] wrote:
{% recurse through get_reply_list as post starting with
forum_post.get_root_post %}
Hey Matt --
This looks really good, and I'm personally +1 on adding this to
Django's default tags. However, there are a few things that would
need to
On Dec 14, 2005, at 10:03 AM, Jason Davies wrote:
_group
_batch
_bundle
_bunch
_clump
_cluster
_crowd
_gaggle (!)
_lot
Wait, I've got it!
reporter.get_article_list()
Wow! So readable, so clear!
(Sorry)
Jacob
On Dec 14, 2005, at 8:47 PM, Tim Keating wrote:
I expected to see 1 call to function_get_iterator, or, at worst, 1
call
for every GET_ITERATOR_CHUNK_SIZE rows. Instead, I'm seeing *3* calls
to function_get_iterator for every row, which I find perplexing. I
intend to dig into this further but I
On Dec 14, 2005, at 9:15 PM, Adrian Holovaty wrote:
Or maybe get rid of the "models" cruft:
/admin/myproject/blog/entry/add/
This one's my favorite.
Double points if /admin/myproject/ shows a list of models under
myproject (and /myproject/blog/ shows all the ones under
myproject.blo
On Dec 16, 2005, at 2:01 PM, Robert Wittams wrote:
Brant Harris wrote:
However, Why do they have to be all caps? "class Admin" and "class
Meta", seem nicer.
I think so too. It would be easy enough to make it accept both.
I always think capitals are constants, or I'm using something scary
l
Hey Robert --
Thanks for your work on this -- I've just had a chance to check out
the branch for the first time, and it's just amazingly awesome.
On Dec 16, 2005, at 8:09 PM, Robert Wittams wrote:
Ok, so in the magic-removal branch, I've refactored things in a way
which makes it very easy t
On Dec 17, 2005, at 6:09 AM, Robert Wittams wrote:
I really don't like this. It is *not extensible* from the outside. The
point about just having things in your class that are able to add
to it
is that it just works like this anyway (it would be harder to forbid
it). The TagCollection etc can
Hey Russ -
I'm still reading through your proposal, but one quick note:
On Dec 19, 2005, at 12:30 AM, Russell Keith-Magee wrote:
2) A 'columns' keyword to restrict column returns
This already exists; look at the get_values() function: http://
www.djangoproject.com/documentation/db_api/#get-
Hey folks --
I'm starting to gear up on the removing core fields bit, and before I
get too deep into it I want to run my plan by everyone:
First, "core" as a field option will die. Until 1.0 it will be
accepted and ignored -- but django-admin validate will complain about
it. 1.0 will r
On Dec 19, 2005, at 6:55 PM, Eugene Lazutkin wrote:
If you need any help, write me.
I will; thanks.
I would suggest to keep an eye on potential reusability of your
widgets. It
would be nice to use them in custom interfaces.
Yeah, depending on how well it works I might write Dojo widgets
On Dec 19, 2005, at 8:48 PM, oggie rob wrote:
One comment: something that has been bugging me for a while is the
location where you specify the inline behaviour.
For example (using the Poll/Choice models):
class Choice(meta.Model):
poll = meta.ForeignKey(Poll, edit_inline=meta.STACKED,
num_
On Dec 19, 2005, at 10:30 PM, oggie rob wrote:
Jacob says:
I kinda think it should be::
class Poll(Model):
...
class Choice(Model):
poll = ForeignKey(Poll)
class ADMIN:
edit_inline_on_relation = 'poll'
But in (almost?) all other ways the admin section r
On Dec 20, 2005, at 8:36 AM, Adrian Holovaty wrote:
How do you envision Ajax use for the edit-inline interface? Would you
be using Ajax simply to return the form widgets for an extra inline
object, or would you be using it to actually *save* the related
objects to the database?
Yeah, the idea
Hey Robert --
As always, great questions...
On Dec 20, 2005, at 8:36 AM, Robert Wittams wrote:
What are you planning to do with the automatic manipulators? I had
planned to make the manipulators "recursive", ie a parent manipulator
would hold a list of child manipulators for each inline-editab
Hey Ian --
I think the best way to do this is with the event framework that's
being introduced in the magic-removal branch. The Template can send
an event with its Context at render time, and interested plugins can
listen to that event and modify the Context appropriately.
How does that
On Jan 2, 2006, at 2:13 PM, Amit Upadhyay wrote:
Djando URL resolution causes some problem with applications hosted
in different subdomains. Consider www.example.com and
blog.example.com. Both of them are running off the same database
and share common admin, and so on, but are hosted in dif
Howdy --
A quick reminder: PyCon 2006 is coming up, and early-bird
registration ($65 discount) is open until Jan 15th. There's a good
bit of Django stuff planned, so if you can make it you should
register! Here's what we've got going on:
* Both Adrian and I will be giving a talk. Mine
On Jan 7, 2006, at 6:54 AM, kmh wrote:
As Aaron says, it is not obvious to the outsider what the underlying
structure of the package hierarchy is. I suspect this is a common
problem in projects that have evolved to meet the needs of a busy
production environment.
Yeah, this is a very good poi
On Jan 7, 2006, at 12:51 PM, Dody Suria Wijaya wrote:
Can I also vote? Or is it something reserved for the core developers?
The "votes" aren't really official, but are more a way of succinctly
expressing an opinion. See http://www.djangoproject.com/
documentation/contributing/#deciding-on-
On Jan 9, 2006, at 7:24 AM, Russell Keith-Magee wrote:
Any objections to me cleaning up these methods and removing the
kwargs?
Sounds like a good idea - go for it.
Jacob
I think this is a very good idea, and I like the precedent of adding
methods to the inner Admin class to influence the admin behavior. I
do agree, however, that this should wait until after we finish the
magic-removal branch. There's nothing in this proposed change that
would break any
On Jan 17, 2006, at 4:27 PM, oggie rob wrote:
Maybe it's just me...
I doubt it's *just* you...
Why in the world would we want development documentation in the admin
interface? I noticed that the "Documentation" link was added to the
user links section, but none of the users of any real world
On Jan 18, 2006, at 8:23 PM, Adrian Holovaty wrote:
On 1/18/06, hugo <[EMAIL PROTECTED]> wrote:
How about something like this:
INSTALLED_APPS = (
'foo.bar.baz',
('foo.baz.baz', 'baz2'),
)
This seems to be a good compromise -- it requires no change for the
common case, and it's not "cod
On Jan 25, 2006, at 9:57 PM, Adrian Holovaty wrote:
I've written up my latest proposal here:
http://code.djangoproject.com/wiki/DescriptorFields
Yum!
I agree with Joseph -- I like this new syntax a *lot*.
I do have a few semantic questions, though. WARNING: Much nit-
picking follows; I sh
On Jan 26, 2006, at 5:27 AM, Peter Ferne wrote:
I'm about to implement a RESTful API to some Django models and
wondering whether to try and build on any of the patches checked in
against any of the tickets marked as duplicates or subsets of #115. Or
wait? Or just code from scratch?
I can't help
On Jan 26, 2006, at 2:23 AM, hugo wrote:
One nice thing about chained methods is, you can pass around the query
object and modify it after the fact. Think "curried queries" - you
build a partial query and pass it to a function, which itself can add
more query specifications or ordering or stuff
On Jan 26, 2006, at 9:04 AM, petef wrote:
That sounds like it could be very handy. Is there somewhere I can
check
to see when you check your stuff in? Are you likely to close any
tickets? Are the commits available via email or rss or anything?
There's a few places you can see that stuff: on
On Jan 26, 2006, at 10:28 AM, Adrian Holovaty wrote:
The reason is consistency. If we enforce the "_set" thing (or whatever
other name we come up with), that means there's a simple rule to
remember:
[snip]
Make sense? But, yeah, I realize that the "sites" attribute name in
that model is essent
On Jan 26, 2006, at 12:26 PM, Joseph Kocherhans wrote:
http://code.djangoproject.com/wiki/ModelInheritance
Thanks for doing this, Joseph! It looks really good, too, but here
are the (inevitable) nitpicks:
1. Modeling parent relations in SQL: #3 seems to make the most sense
for me -- I c
On Jan 27, 2006, at 4:25 PM, Joseph Kocherhans wrote:
I think that's the main point of disagreement. Does this capture it
all?
1. Model.objects vs. Model.objects.all()
(and also instance.sites vs. instance.sites.all()?)
2. len(q) vs. q.count()
3. related_name for ForeignKey and ManyToMa
On Feb 2, 2006, at 2:53 PM, Wojtek/brandlay.com wrote:
any idea how to speed Django up? my servers have load 140 now even
though I'm caching templates. any sites/hints on speading the whole
machinery up?
Yikes!
Most of what I know is summed up here: http://www.jacobian.org/2005/
dec/12/dja
On Feb 3, 2006, at 3:28 AM, [EMAIL PROTECTED] wrote:
a simple solution would be to use lazy loading of the settings
module in django.template, change all template code to access
the settings via django.template.settings, and let an external
user configure the template package *before* loading th
On Feb 3, 2006, at 6:46 AM, Wojtek/brandlay.com wrote:
without psyco:
265822 function calls (207471 primitive calls) in 3.547 CPU
seconds
with psyco:
66865 function calls (63420 primitive calls) in 1.457 CPU
seconds
So basically - if you want a quick Django - use psyco :)
Wo
On Feb 3, 2006, at 9:20 AM, Adrian Holovaty wrote:
Thanks for this patch. I've added it to trunk. My only concern is that
the Psyco Web page says "[t]here are some subtle semantic differences
(i.e. bugs) with the way Python works; they should not be apparent in
most programs." Perhaps some of Dj
On Feb 9, 2006, at 2:55 AM, Ian Holsman wrote:
a while back Euguene mentioned on djnago-users that 0.92 will have
dojo ajax components in the admin interface.
is this being developed on a seperate branch?
I'd like to talk about the json layer, and how a common method for
sending errors in valid
On Feb 3, 2006, at 6:39 PM, Jeremy Dunck wrote:
What's on the board for the pycon sprint?
Although I'm signed up officially as the "coach", I don't really have
much of an agenda to what I'd like to get done.
My plan is to make a "pycon2006" branch in SVN and give anyone who's
there check
On Feb 9, 2006, at 3:03 PM, Ian Holsman wrote:
> I've been working more on things at the Add/ChangeManipulator level,
> to allow you to bring up a dialog box and post a comment through
> Dojo's post thingy. the only real difference is that instead of a HTML
> template returning, it just returns a
Hey folks --
Right now (thanks to Robert's awesome admin work a few months ago)
you can easily make a custom template for an admin change form. I've
found at times that this is too heavyweight for me since often all I
want to do is override the display of a specific field. For example:
On Feb 13, 2006, at 11:22 AM, Adrian Holovaty wrote:
I strongly object to this, because that means for *each widget on your
admin form* it's going to hit the filesystem for *all of those* files.
So if your admin form has 10 fields (average), and none of them has a
custom field widget (average),
On Feb 13, 2006, at 11:57 AM, Adrian Holovaty wrote:
Seems a bit boilerplatish, compared to a simple list of field names,
but the advantage of this would be that you could easily reuse
widget-specific templates. On the other hand, you could reuse
widget-specific templates with the field-name lis
On Feb 13, 2006, at 12:05 PM, Joseph Kocherhans wrote:
Another option (although I'm not sure that I like it) is to allow
either style. The tuple would use the template lookup described in
Jabob's first email, and the dict would of course allow you to supply
*any* template path. It's more flexibl
On Feb 17, 2006, at 10:40 AM, pbx wrote:
> That got me thinking: How about annotating the default settings
> file to
> describe all available settings? I'm talking about something along the
> lines of Apache's default httpd.conf.
You mean something like http://www.djangoproject.com/documentatio
On Feb 20, 2006, at 9:38 AM, Martin Ostrovsky wrote:
>
>
>
>
>
> I would want one python function to correspond to each of
> submit_action1 and submit_action2.
def my_view(request):
if request.POST.has_key('submit_action1'):
do_action_one(request)
elif
On Feb 21, 2006, at 3:33 PM, gabor wrote:
> http://wiki.python.org/moin/PyCon2006/Sprints/DjangoSprint
>
> unfortunately no trace of magic-removal :(
That's really only a rough guide. I'd hoped that magic-removal would
be mostly done by PyCon, but as that won't happen chances are much of
PyC
Hey Adrian --
In general, I think this is a pretty good idea. However, I've got
quite a bit of code the does something similar to the following:
obj = SomeObject()
for field in some_dict:
setattr(obj, field, some_dict[field])
obj.save()
i.e. build up o
Howdy folks --
Four days of PyCon sprints start tomorrow! A bunch of us here at PyCon
met this afternoon to plan out what we'll be working on over these next
four days. You can find those topics and notes from our meeting today
at http://code.djangoproject.com/wiki/PyConSprint06.
Anyone who's i
Hey folks --
I've posted (over 1200 words of) my thoughts on schema evolution to the
wiki: http://code.djangoproject.com/wiki/SchemaEvolution.
Any thoughts before I start on this?
Jacob
--~--~-~--~~~---~--~~
You received this message because you are subscribed
On Mar 2, 2006, at 3:16 PM, Michael Radziej wrote:
> Now, did I miss something and is this already fixed? Should this be
> treated differently? How do other people handle this?
The problem in the admin was fixed in [1982]: http://
code.djangoproject.com/changeset/1982; in your own templates you'
Hey folks --
I've thought about this a bit more; lots of good points have been
raised. What I'd like to do would be to add a new tag that takes
care of auto-escaping variables used within it. Something like::
{% autoescape %}
Any {{ variables }} used within this {{ block }}
Howdy --
Russ, I can't thank you enough for your work on this stuff. Half
these edge cases I wouldn't have even thought of 'til they bit me in
the ass -- I really appreciate it :)
Now, onto your questions:
> I propose that: 'Article.reporter_set = X' be allowed, where X is any
> iterable.
On Mar 5, 2006, at 6:31 AM, Malcolm Tredinnick wrote:
> Was there any discussion at PyCon about validation-aware models?
Yeah, we talked about this quite a bit, but never actually got to a
final solution.
Adrian's actually on vacation right now -- in Hawaii, the lucky
bastard -- but he told
401 - 500 of 1372 matches
Mail list logo
