Hi all,
I have tried my chance in the user group with no avail. I think this
might be of interest for the developer's community.
I've been trying to create a custom widget using the newforms-admin
branch. This widget is to replace the classic select box for
ManyToManyFields by a list of grouped
under construction. I don't know if this is already done
somewhere, but it would be great to have a full example of a custom
widget implementation, including the refresh javascript method when
adding new objects on the fly.
Cheers,
Julien
On Nov 26, 4:31 am, "Honza Král" <[EMAIL PRO
that would give the ability to extend the use of
non-db fields.
Please let me know your thoughts on this and/or pointing me to some
other similar discussions in the mailing list or elsewhere.
Cheers!
Julien
--~--~-~--~~~---~--~~
You received this message becaus
The ticket http://code.djangoproject.com/ticket/3397 is looking at
that issue and seems to provide a good alternative for ordering non-db
fields. Is that patch viable?
On Dec 2, 3:03 pm, Julien <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I find that displaying non-db fields is quite
select query, so that the virtual field can be
sortable/filterable.
Would anyone have an idea how to implement this approach?
Cheers,
Julien
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" gr
for sub_obj in getattr(self, rel_opts_name).all():
sub_obj._collect_sub_objects(seen_objs)
Now, does that look like a bug to you? If so, is my proposed fix
appropriate? If not, have I missed something?
Cheers,
Julien
--~--~-~--~~~---~--~~
You received
and 'userprofile_related'. The fact is that it may
not have those attributes, hence the suggested 'hasattr' test.
What do you think?
On Jun 2, 11:39 pm, "Karen Tracey" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 2, 2008 at 4:56 AM, Julien <[EMAIL PROTECTED]&
> Newforms-admin needs to get done. Putting it off from the first couple
> betas or RCs will just increase the temptation to put it off further,
> so what we should do is identify anything that's slowing it down and
> work to resolve that. If that means organizing a sprint or two on it
> and then
+1 for merging newforms-admin ASAP.
On Jun 10, 7:13 pm, "Gábor Farkas" <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 9, 2008 at 11:02 PM, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Jun 7, 2008 at 2:06 PM, Jacob Kaplan-Moss
> > <[EMAIL PROTECTED]> wrote:
> >> * Start a "train release" sch
And I would also organise a sprint 3-4 weeks after the merge dedicated
to fixing bugs in NFA.
On Jun 10, 7:40 pm, Julien <[EMAIL PROTECTED]> wrote:
> +1 for merging newforms-admin ASAP.
>
> On Jun 10, 7:13 pm, "Gábor Farkas" <[EMAIL PROTECTED]> wrote:
>
&
Seems like a very good roadmap, and it must clear a lot of concern and
uncertainty some people may have.
In the must-have features, or at least in the maybes, I'd put the bugs
introduced by, or not properly fixed by, the merge of the queryset-
refactor branch. A list of related open tickets has b
e or less matches
your assumption. It is documented here:
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/submitting-patches/#claiming-tickets
However, the doc could certainly do with further clarifications. Patches
welcome :P
Julien
--
You received this message because
should be reverted, then please provide
concrete arguments for it. If you know how this question is handled in other
frameworks then that would also be quite useful to hear about.
Many thanks!
Julien
[1] https://code.djangoproject.com/changeset/16415
[2]
http://groups.google.com/group/django-
in turn inform the parallel
development of newadmin.
- This would make the future transition and upgrade path to newadmin easier.
If someone is willing to take this on then I'd be happy to provide some
support by reviewing patches, giving feedback etc.
Cheers,
Julien
[1] http://lukeplant.me
ionality?
Yep. Could you outline your plan of attack for this?
Julien
--
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 unsubscribe from this group, send
hat step #4 could be done in core regardless,
though, and my point is that this work would benefit other efforts that are
put into the full newadmin rewrite as it'd give us some empirical evidence
of what does or doesn't work, quickly highlighting any major snag in the
process.
Julien
--
the Python
way of handling *args and **kwargs.
The only thing that's still not possible with these is to define a complex
or custom syntax, e.g.: {% mytag with myvar using "blah" %}
However, if one is OK to not have a custom syntax, then the following is now
dead-easy:
{% mytag with=m
fo)
>
> In django this leads to unsubstituted admin mail messages.
This should already be fixed in trunk:
https://code.djangoproject.com/changeset/16715
Regards,
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
n trivial and
most likely backwards incompatible. It would be a welcome change though,
and also a good opportunity to clean up some parts of the admin's codebase.
So I'd absolutely encourage anyone to dig into it and I'd personally be
happy to follow it up and provide feedback as
ing parameters, unless those parameters match a custom list filter and
that filter raises an unhandled exception. There is already a system in place
to avoid this problem though, so if you've found an edge case could you please
create a new ticket in Trac with a test case?
Thanks a lot,
Julien
smime.p7s
Description: S/MIME cryptographic signature
On Apr 11, 2012, at 11:44 AM, 3point2 wrote:
> Julien, I'm not describing an edge case. Django will return an HTTP
> 500 for ANY field lookup on a related model that is not in the
> list_filter option.
>
> To test, simply create a model that has a ForeignKey to another mo
layout. However, will all
that said, it might eventually be worth considering to move the
documentation entirely to RTD one day (with some special branding).
The prototype's code is available on github [5]. I hope this is of
some help to the person or team that will be driving this projec
min views into CBVs in ticket #17208
(https://code.djangoproject.com/ticket/17208).
Once good progress has been made, then it would also be very helpful to keep
the maintainers of all major custom admin apps (Armstrong, FeinCMS, Django-CMS,
Grapelli, Mezzanine, etc.) in the loop for feedback.
Thanks a lot for your great work!
Julien
smime.p7s
Description: S/MIME cryptographic signature
On Aug 25, 2012, at 1:15 AM, Russell Keith-Magee wrote:
> Hi all,
>
> So, I've been working on a Django branch [1] to implement the approach
> to pluggable user models that was decided upon earlier this year [2]
>
> [1] https://github.com/freakboy3742/django/tree/t3011
> [2] https://code.django
Hi Marijonas,
I've left a comment in your ticket. The conversation can continue there.
Thanks,
Julien
On Nov 4, 2012, at 8:15 AM, Marijonas Petrauskas wrote:
> Yes, it's created by me. Sorry for not referencing it.
>
>
> On Sun, Nov 4, 2012 at 2:06 PM, Łukas
ngo has similar functionality.
> How about making that application a little bit more configurable and
> convinient?
> It doesn't seems to be difficult, so I can do it myself.
More customization hooks would be welcome. Please feel free to create tickets
in Trac. Please keep each pr
ifying Django to reduce that noise, but only if it gets proven that ignoring
those errors won't either cause the tests to fail or to pass as false positives.
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this gro
and more difficult to handle properly.
For that reason, I'm also in agreement to eventually remove this type of
validation altogether in favor or more explicit runtime error messages. While
the current static validation can be useful, it's most likely that you would
try testing the adm
about this? Does this ticket have a chance to
be accepted or is it fundamentally a bad idea?
Many thanks.
Kind regards,
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
Am I missing something or are there really no tests for
this yet?
Many thanks.
Kind regards,
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubsc
On Jul 6, 5:54 pm, Russell Keith-Magee
wrote:
> On Tue, Jul 6, 2010 at 1:43 PM, Julien Phalip wrote:
> > Hi,
>
> > I'm starting to work on ticket #2367 ("Pagination for date based
> > generic views" -http://code.djangoproject.com/ticket/2367) and I'm
&
ant this and that there's a chance to make it ship in 1.3
(since 1.3's focus is on scratching all those annoying little itches).
In summary, what do you think about enabling context access in
simple_tag (using the takes_context syntax)? If the response is
positive, I'm very keen to lead th
ruft.
Any chance these two decorators could be considered for inclusion in
Django core?
Cheers,
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To
On Dec 14, 7:34 pm, Christian Hammond wrote:
> On Dec 14, 12:02 am, Julien Phalip wrote:
>
>
> > On Dec 13, 10:16 am, Tai Lee wrote:
>
> > -snip-
>
> > > One suggestion from #1105 was to split out this functionality into
> > > individual decorator
On Dec 15, 10:52 pm, Russell Keith-Magee
wrote:
> On Wed, Dec 15, 2010 at 6:41 PM, Julien Phalip wrote:
> > On Dec 14, 7:34 pm, Christian Hammond wrote:
> >> On Dec 14, 12:02 am, Julien Phalip wrote:
>
> >> > On Dec 13, 10:16 am, Tai Lee wrote:
>
> >
lpha and beta stages, and also help people looking for tickets when,
for example, they're in the mood for fixing bugs. I believe the
Keywords field has been used in an ad hoc way for this before, but it
feels that something more structured would be more helpful.
Cheers,
Julien
--
You re
ccepted" (or in fact may as well leave
it as "Patch ready for review") and writes a comment explaining the
issues with the patch.
- B posts a new updated patch (and re-stages #123 to "Patch ready for
review" if it has been staged back to "Accepted").
- D verifies the pa
On Feb 22, 3:22 am, Russell Keith-Magee
wrote:
> On Tue, Feb 22, 2011 at 3:49 PM, Julien Phalip wrote:
> > I know there already is a "Has patch" flag, but I actually find that
> > one a bit useless since there's no way to distinguish from the mass of
> >
e Trac admin change once its decided.
>
> All the best,
>
> - Gabriel
+1 for a close resolution. As long as the attached comment _politely_
asks the reporter to provide more info and to reopen the ticket if the
bug is genuine, then there should be no hard feelings or intimidation.
nd the vast majority of user
experience related tickets will likely always be related to the admin
anyway.
What do you think?
Cheers,
Julien
[1] Contrib apps component:
http://code.djangoproject.com/query?status=assigned&status=new&status=reopened&component=Contrib+apps&co
> On Mon, Feb 21, 2011 at 3:05 PM, Julien Phalip wrote:
> > Hello,
>
> > I was wondering if others would find it useful to introduce a new
> > field in Trac to characterise the nature of a ticket, allowing to
> > choose from at least: "bug report", "fe
t a Trac expert, but it feels as though the component values are
stored as full strings. So if changes are made it's likely we'll have
to run SQL queries to bulk-update the corresponding database entries.
Julien
--
You received this message because you are subscribed to the Google Groups
stem)", "django.core.mail" to "Core (Mail)", and
"Serialization" to "Core (Serialization)".
Let me know if any of that is total yak shaving or if it's worth
implementing. By the way, the reason why I care about this
specifically is because I think
ure-freeze.
If we do want to give it a try, then it'd be great to implement it
quite soon so we have enough time to trial it properly on our way to
1.4. If not, then no worries ;-)
Cheers,
Julien
--
You received this message because you are subscribed to the Google Groups
"Django
t proved a
> helpful resource; I think it's worth promoting these to full UI
> elements.
>
I think there will rarely be many blockers at any given time, so I'd rather
keep all bugs under "Bug" to keep the dropdown box succinct, and introduce a
new "Release blocker&q
rized" was for when the reporter could not
decide or simply didn't bother (which is still better than picking a
wrong option).
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dj
On Mar 29, 2:01 am, Jacob Kaplan-Moss wrote:
> On Mon, Mar 28, 2011 at 12:56 AM, Julien Phalip wrote:
> > Now that 1.3 has been released (yay!), I'm reviving this thread to see
> > if we can make Trac a little more efficient on our way to 1.4. I'll
> > try to sum
On Mar 29, 8:58 am, Gabriel Hurley wrote:
> I can work on it late tonight (about 6-8 hours from now) if no one else gets
> to it.
>
> All the best,
>
> - Gabriel
Excellent, thank you Gabriel! There's no rush -- whenever it suits
you. Let me know if I can help in an
lease [1]. Maybe we should revisit the use of this field now
again, for example by discontinuing it altogether if it is deemed
useless, or by restricting its write access to core devs, or by
designing a better field filling the (yet to be clarified) purpose.
Any thoughts?
Julien
[1]
htt
e patch is small, then it would be very quick to test it in
all browsers right away, no? :-)
Julien
[1] http://ejohn.org/blog/html5-doctype/
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djang
On Mar 29, 2:29 pm, Julien Phalip wrote:
> On Mar 29, 1:26 pm, Luke Plant wrote:
>
> > The further enhancements I'm thinking of are things like an EmailInput
> > widget (which I'd suggest was the default widget for EmailField, but
> > could be just available
we can't consider it
if we want to support IE6 with javascript turned off.
However, in the case of inputs, the tag definitely is known by IE6 --
it's the 'type' attribute's values that will not be recognised. I'm
not sure if that affects CSS though.
Julien
--
Yo
stale these days, but that's a conversation for another day. ;-)
>
> If you find any problems feel free to let me know.
>
> All the best,
>
> - Gabriel
Wow, fantastic! We owe you a few cold beers :D
Julien
--
You received this message because you are subscribed to the
about this and I tend to think that it's probably just good enough to catch
up with the backlog bit by bit and update the attribute for new tickets and
other tickets that we browse during our routine rounds. If some tickets
never get updated, then it means that nobody cares enough about them, so
t
but I've just made these changes.
>
> Ladies and Gentlemen start your triage!
>
> Russ %-)
Just a quick note, Russell -- The 'Type' isn't showing up in the
ticket summary (yellow frame) at the top. The 'Severity' is showing
though.
Julien
--
You rece
atus=!closed&order=id
Maybe I'm over-engineering this, oh well... ;-)
Happy triaging!
Julien
--
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@googlegro
FYI, I've just stumbled on ticket #7452 and this thread:
http://groups.google.com/group/django-developers/browse_thread/thread/f346813ab89d4155/
One interesting idea that was suggested is to introduce a setting for
controlling the type of HTML.
--
You received this message because you are subscr
t allow_many and (m2m or (not
> direct and not isinstance(getattr(field,'field',None),OneToOneField))"
> instead could work to allow OneToOne reverses through in setup_joins
> when allow_many is False.
>
> Regards,
> Matt
Hi Matt,
Do you think this could be related
and ']' in the last line. So, when wrapping the error
message with '[' and ']', the error message is purely ignored and the
test just passes. This, by the way, means that pretty much all the
tests in 'regressiontests.forms.localflavor' using 'assertFieldOutput'
are curre
t uses
regular expressions at all. I tend to think that assertFieldOutput
shouldn't use assertRaisesRegexp but either use the good old
assertRaises instead.
I think I may have found a fix for this and posted a patch to a new
ticket: http://code.djangoproject.com/ticket/15805
Thank you,
Juli
ered.
I'm also really keen to hear your thoughts on the various sub-features
that ship with that patch, on the suggested API, and on the various
implementation details.
The patch is pretty hefty so I'd really like to take this to a close
ASAP before it grows stale and becomes harder to
ocused on what has been requested in #5833. Again,
feel free to open a specific ticket for that ;)
Julien
--
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 unsubs
On Apr 14, 3:11 am, Jacob Kaplan-Moss wrote:
> Hi Julien --
>
> Thanks for your work on this! I'm working my way through the patch,
> and it's looking good. I'm pretty happy with the internals, though I
> do have some questions about the public API:
>
On Apr 14, 8:46 am, Julien Phalip wrote:
> Thanks a lot for your feedback. I agree with all your points and have
> made the corresponding amendments in a new
> patch:http://code.djangoproject.com/attachment/ticket/5833/5833.custom-filt...
Sorry, just in case you've already started
l start work on #15838.
Many thanks!
Julien
http://code.djangoproject.com/ticket/14262
http://code.djangoproject.com/ticket/15805
http://code.djangoproject.com/ticket/14608
http://code.djangoproject.com/ticket/15838
--
You received this message because you are subscribed to the Google Groups
&qu
es at
stake, but I can vouch for its simplicity of use and for the fact that
it does work in real projects. All in all, django-nonrel appears to me
as a very promising solution.
Cheers,
Julien
[1] http://www.allbuttonspressed.com/projects/djangoappengine#installation
--
You received this messa
On May 4, 10:59 am, Dario Ocles wrote:
> Hello everybody.
>
> Ramiro Morales and me were working on this ticket #15294 [0] and
> Julien linked this one #8001 [1]. We had a little discussion about two
> possible solution for #8001 and Julien suggested that we should hear
> you
in [1] Julien suggests to also allow a callable - which I think
> would be very useful, and provide all the flexibility one would need.
I too think that could be useful but it might be a bit much for a
start. At this stage I'd preferred to wait till we hear from concrete
use cases where this w
need review" in http://code.djangoproject.com/wiki/Reports) except
ordered by descending "modified" date. If you think it's useful, could
someone with write access edit the Reports page with that query?
Cheers!
Julien
--
You received this message because you are subscribed to the
enough about the ORM to predict if that sort of things
could have bad side effects. What do you think?
Julien
--
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.
tainable and
extensible shape and, as a result, that it will facilitate
contributions from the community.
It is a big change so I thought I'd bring it up here in case you have
ideas and suggestions to improve it further or differently. Any
feedback is welcome.
Thanks a lot!
Julien
[1] htt
On May 21, 1:33 am, Waylan Limberg wrote:
> One nitpick thought. I expect that people reporting bugs will go to
> the "bugs-and-features" page, which is fine. However, as is often the
> case, when their ticket is marked "accepted" (or some other triage
> stage) they often get confused about what t
On May 21, 2:15 am, "Jonas H." wrote:
> > "[...] try and duplicate it. If you can duplicate it [...]"
>
> I'd stick with "reproduce" here because "duplicate" may be confused with
> "duplicate tickets".
Yes that's a good point. I fixed that in the latest patch. Thanks!
--
You received this messa
. It is a pretty serious issue that I hope can be resolved by
the 1.4 release.
Many thanks,
Julien
--
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 unsub
re are always places you can override a
> method and attach something to the request object.
I quite like this and will try it in a new patch.
Thanks for the feedback!
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
Many thanks to all for the feedback. I've just posted a new patch,
welcoming any further feedback:
https://code.djangoproject.com/attachment/ticket/14614/14614.exception-reporter-filter.diff
Regards,
Julien
--
You received this message because you are subscribed to the Google Groups
&q
g? Or maybe
something more explicitly targeted to the end goal, like a "Needs
designer's talents" flag?
Julien
--
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@goog
ast the interface should be forgiving and recovery should be quick.
My two cents ;-)
Julien
--
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 unsubscri
On Jun 16, 3:08 am, Alex Kamedov wrote:
> Django documentation page Contributing to Django [1] has the same problem
> too
> [1]https://docs.djangoproject.com/en/1.3/internals/contributing/
I've fixed the link in the wiki page. The doc is already fixed in
trunk.
Thanks,
Julien
--
On Jun 16, 10:32 am, Julien Phalip wrote:
> On Jun 16, 3:08 am, Alex Kamedov wrote:
>
> > Django documentation page Contributing to Django [1] has the same problem
> > too
> > [1]https://docs.djangoproject.com/en/1.3/internals/contributing/
>
> I've fixed th
need to be reconsidered in order to avoid
confusion in the docs and APIs. I'm not sure. Just thought I'd point
it out ;)
(By the way, "production" is a common generic term used for when DEBUG
is False)
Julien
[1]
https://docs.djangoproject.com/en/dev/howto/error-reporting/#fi
On Jun 18, 11:38 am, Stephen Burrows
wrote:
> I would love it if someone could look at 13956 [1]
RFC'd, thanks ;)
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to
ttps://code.djangoproject.com/ticket/16193 -- 'mbraak' posted a patch
with a few simple tests for the admin JS. It'd be great to see how
both your works integrate.
Thanks again, this is awesome!
Julien
--
You received this message because you are subscribed to the Google Group
could be further improved by providing some
concrete code samples -- so if your patch contains some, all the
better ;-)
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to djan
ing similar generic views to core. Perhaps this is
something you would like to contribute to based on your own experience
and use case?
https://code.djangoproject.com/ticket/16256
Regards,
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developer
ll the compared frameworks and who do not appear
biased towards one or another. One should always be cautious with
websites/frameworks/products/whatever boasting that they are so much more
awesome than the others :-)
Julien
--
You received this message because you are subscribed to the Google Grou
On 30 August 2011 17:33, Idan Gazit wrote:
> So, a while back, I announced that Django is dropping support for IE6 in
> the admin. What I _didn't_ specify is what browsers are supported.
>
> I'm currently composing a bit for the 1.4 release notes about admin browser
> support, and wanted to expli
On 30 August 2011 19:08, Julien Phalip wrote:
> ... perhaps the FAQ?
>
That is, assuming we'd consider this a potentially frequently-asked question
:)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
whether the root cause lives in Webkit itself
or in the admin's JS code. Any help investigating this would be appreciated.
Julien
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to dja
at
> adjusts the behavior to use the full staticfiles finders, where the base
> LiveServerTestCase in core just serves from STATIC_ROOT.
I think that's a great idea. This way, all you'd need to do to have the full
static finders is make your TestCase inherit from that subclass, and
On Jul 25, 2013, at 5:29 AM, Aymeric Augustin
wrote:
> Hello,
>
> I'd like to deprecate admindocs. Here are my reasons:
>
> 1) It's called the "documentation generator", but it only operates on
> docstrings. This promotes the idea that docstrings are appropriate
> documentation, while the Py
as we have quite a few raw_id fields and have readonly users as
well.
I have a working patch for this - just need to clean it up & add tests. So
if it's a welcome change, I'll go ahead and do a PR.
Thanks
Julien
--
You received this message because you are subscribed to the
I don't think they're rendered as links, are they?
Indeed, they aren't rendered as links either. I'll apply it to both then.
I've opened a ticket and will continue documenting my progress there :
https://code.djangoproject.com/ticket/31181
On Sat, Jan 18, 2020 at 7:35 PM Ayme
com/vporton/django-composite-fields
- https://bitbucket.org/bikeshedder/django-composite-field
Other relevant links:
- Out-dated Django wiki page:
https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys
- SQL Alchemy's PrimaryKeyConstraint API:
http://docs.sqlalchemy.org/en/latest/
publish your work-in-progress at some point so
we can discuss the approach in more detail.
Thanks,
Julien
On Mon, Feb 27, 2017 at 9:03 PM, Asif Saifuddin wrote:
> Hi Julian,
>
> I have been also reviewing and studying the previous works, deps,
> discussions, codes and tickets. I ha
perhaps some inspiration could be found in how they
specifically handle composite fields, both API-wise and implementation-wise.
Julien
On Mon, Feb 27, 2017 at 12:44 PM, Michal Petrucha <
michal.petru...@konk.org> wrote:
> Hi everyone,
>
> I can't speak for Thomas' imp
oversight and help with documentation, testing and code reviews.
This approach also seems in line with what Asif mentioned earlier about his
own work. Let’s give him a chance to provide some updates on this when he’s
ready, and then we can take it from there.
Thanks all!
Julien
On Mon, Mar 20
ituation (#9404 is another example). So, what is the best way to
go for people interested in having them checked in? Is it simply by
bringing them up on this mailing list from time to time? If so, then I
can try again after 1.1 lands.
Thanks a lot!
Regards,
Julien
http://code.djangoproject.com/t
On Jan 23, 5:14 pm, Russell Keith-Magee
wrote:
> On Fri, Jan 23, 2009 at 2:38 PM, Julien Phalip wrote:
>
> > Now, I know that this is sort of an edge case, and I also know that
> > there are more important and more urgent matters at this moment. But
> > I'd be keen
On Jan 23, 6:42 pm, Karen Tracey wrote:
> On Fri, Jan 23, 2009 at 12:38 AM, Julien Phalip wrote:
>
> > Hi,
>
> > I just wanted to draw your attention to what appears to be a bug in
> > Django: the 'tell()' proxy is missing from the Windows-specific
>
1 - 100 of 147 matches
Mail list logo
