Hi Carlton,
Le mardi 13 septembre 2022 à 07:17:31 UTC-4, carlton...@gmail.com a écrit :
> Hi Julien.
>
> I didn't get a canonical answer from the security team yet, but it may be
> that we can make the idna an optional dependency quite easily. I already
> have it
com/ would be
https://fuss.standcore.com/ with IDNA 2003 and
https://xn--fu-hia.standcore.com/ with IDNA 2008.
This is only a very brief insight, for further quick readings,
https://www.unicode.org/faq/idn.html is quite informative too.
Best regards,
Julien
Le mardi 6 septembre 2022 à 14:39:49 UTC-4, carlton.
ation.
Best regards,
Julien
Le dimanche 4 septembre 2022 à 05:16:19 UTC-4, carlton...@gmail.com a
écrit :
> Hi Julian.
>
> We've had several tickets and discussions surrounding how far e.g.
> URLValidator needs to match all valid URLs. The conclusion we've come to
> (
circle, IDNs and especially EAIs are not widely used
because of the poor support in software and the lack of compliance with the
latest version.
Regards,
Julien
Le jeudi 1 septembre 2022 à 13:33:29 UTC-4, Adam Johnson a écrit :
> Some data...
>
> The idna package has ~9M downloads a day (
pendency is problematic, however,
in most case, someone using Django will end up with this dependency anyway
as it is widely used. Django GeoIP2 contrib uses it for instance.
Best regards,
Julien
--
You received this message because you are subscribed to the Google Groups
"Django develope
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
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
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
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
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
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/
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
--
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
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
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-
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
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
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
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
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
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
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
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
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
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 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
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
--
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
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
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
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.
. 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
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
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
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
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.
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
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
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
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
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
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
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:
>
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> 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
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
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.
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
> >
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
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
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:
>
> >
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
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
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
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
&
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
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
in class to benefit
from all the admin machinery. It worked fine except that the default
hardcoded redirection didn't allow for it, so I had to overwrite some
bits in the views. Not a huge deal, but it's one of those little
customisation hooks that make life easier ;)
Cheers,
Julien
-
for a GSoC proposal you'd need to suggest a
coherent approach rather than a list of minor fixes/feature
extensions. As for including jQuery (or any other javascript library),
I doubt this will be received favourably. Going for plain javascript -
even if it's a bit more challenging to d
On Mar 12, 11:10 pm, Russell Keith-Magee
wrote:
> On Thu, Mar 12, 2009 at 8:31 PM, Julien Phalip wrote:
>
> > On Mar 12, 9:30 pm, Russell Keith-Magee
> > wrote:
> >> On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip wrote:
>
> >> > Hi,
>
> >
On Mar 12, 9:30 pm, Russell Keith-Magee
wrote:
> On Thu, Mar 12, 2009 at 7:20 PM, Julien Phalip wrote:
>
> > Hi,
>
> > A few months ago James raised the issue on this list:
> >http://groups.google.com/group/django-developers/browse_thread/thread...
>
> &
of dictionaries, depending on whether or not the tested page was built
with a hierarchy of templates.
I don't think this has been fixed yet. Could someone confirm? If it
hasn't, then does it have a chance to make it into 1.1? I haven't been
able to find any ticket for it, should on
ng the chance to remind about 2 relevant tickets:
- #9344 [1]: The tell() proxy is missing in the specific
implementation of TemporaryFile for Windows. That causes PIL to crash.
- #9404 [2]: Some proxies are missing in InMemoryUploadedFile.
In [3] Karen explained that one reason why those tickets h
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
>
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
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
1 - 100 of 147 matches
Mail list logo
