On Wed, Apr 28, 2010 at 10:00 AM, Rob Hudson wrote:
> On Tue, Apr 27, 2010 at 6:38 PM, Leo wrote:
> > Digging deep into Python's innards reveals that this is a somewhat
> > esoteric protection in case you're writing out Unix mailbox files. The
> > specific issue is here:
> http://docs.python.org
.db.models.Model):
...
objects = ControlledUpdateManager()
You can apply that manager to any models that need the same pre- and post-
update code, or subclass from it, or use it as a mixin as necessary.
--
Regards,
Ian Clelland
--
You received this message because you ar
a patch that fixes the core
field handling, and makes FileFields deletable.
http://code.djangoproject.com/ticket/2534
Regards,
Ian Clelland
<[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&
On 4/12/06, Gael Chardon <[EMAIL PROTECTED]> wrote:
> After this update, none of my models is "loaded".
>
> Is there any major change in the db "model" ?
Is the problem fixed in 2684? The relevant import line was extended to
include the relations as well as the
parameters down to the cursor
object. (I may be missing the point of the debug object entirely,
though)
--
Regards,
Ian Clelland
<[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django
ich returns "Hello world"
Is this patch worth submitting an enhancement ticket? Or have I
managed to miss a simpler way of doing this?
Regards,
Ian Clelland
<[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
You received this message because you are subsc
because I threw in a couple
of unit tests and a line of documentation.)
Ian Clelland
<[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this grou
re seriously, though, I've been seeing more Python 2.4-isms showing
up in the documentation (and occasionally into code) recently -- are
there plans to make the next release dependent on anything greater
than 2.3?
Ian Clelland
<[EMAIL PROTECTED]>
--~--~-~--~~--
7;Kääriäinen')
u.firstname='Matti'
u.save(force_update=True)
(specifically, with the force_update parameter being required for a PK
change). Then, as long as we store the original PK values, the object can
be updated in place. A bare save() would work just as currently changing
the
7;s all in code anyway, and you
should know which fields are PK fields before you go messing with them." :)
)
Solving all these problems before 1.4 seems hard.
>
Agreed.
>
> - Anssi
>
> --
> You received this message because you are subscribed to the Google Groups
&g
On Wed, Nov 30, 2011 at 1:15 PM, Ian Clelland wrote:
> On Wed, Nov 30, 2011 at 12:40 PM, Kääriäinen Anssi <
> anssi.kaariai...@thl.fi> wrote:
>
>> """
>> Is this referring exclusively to natural, or user-specified primary key
>> columns? Despit
ifference between the payload of a POST request and that
of a PUT request, but that's what it is.
Ian
* RFC-2616 prohibits a body on certain kinds of requests, so in practice,
you won't see "POST data" on a GET or DELETE request, but you could see
"GET data" on
, unless you have very large
fields for primary keys in your database, in which case you are already
suffering from them, certainly :)
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this g
and manually copied the tests directory into build/)
then the pre-compiler would work, and the test suite would run.
Did I miss a step here, or not see an error which should have been
corrected earlier? Nobody else has commented about Python3 syntax errors,
so I'm thinking it's my proces
On Mon, Dec 5, 2011 at 5:08 PM, Vinay Sajip wrote:
> On Dec 6, 12:45 am, Ian Clelland wrote:
> > After a lot of troubleshooting, and fun installing Python3.2 under
> > virtualenv (Vinay, I think I ran into the same issue as you here:
> https://github.com/pypa/virtualenv/iss
t security patches have changed that.
[2]
http://stackoverflow.com/questions/8343942/what-is-the-effect-of-starting-a-url-with-and-leaving-out-http
(also referenced:
http://stackoverflow.com/questions/4978235/absolute-urls-omitting-the-protocol-scheme-in-order-to-preserve-the-one-of-the
and
four or five
On Tue, Dec 6, 2011 at 2:33 AM, Vinay Sajip wrote:
>
> On Dec 6, 4:18 am, Ian Clelland wrote:
>
> > If I replace line 25 with this block:
> >
> > resource_name = resource_string(app, pkg_name)
> > if hasattr(resource_name, 'decode'):
&
On Tue, Dec 6, 2011 at 5:05 PM, Vinay Sajip wrote:
>
> On Dec 6, 11:29 pm, Ian Clelland wrote:
> >
> > Without doing anything else, I installed pymysql, and made a few minimal
> > modifications to use that module in the mysql backend, and fixed one
> > Pytho
e.com/group/django-developers?hl=en.
>
>
--
Regards,
Ian Clelland
--
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, se
nyway, but the tests are
still just as slow. They've been going for almost 4 hours again now; I'll
be able to report back once they're done.
> I have had to fix a couple of bugs in pymysql, but I think I am
eliminating most of the errors. Once I can plug my laptop in to run a full
t
On Tuesday, December 6, 2011, Ian Kelly wrote:
> itertools.izip_longest was added in Python 2.6, though, so a
> compatibility function is needed for Python 2.5.
Ahh, that's a good catch. I'll have to make use of your solution, then.
Ian
--
Regards,
Ian Clelland
--
You recei
On Wed, Dec 7, 2011 at 4:14 AM, Vinay Sajip wrote:
> On Dec 7, 5:53 am, Ian Clelland wrote:
> > On Tuesday, December 6, 2011, Ian Kelly wrote:
> > > itertools.izip_longest was added in Python 2.6, though, so a
> > > compatibility function is needed for Python 2.5.
On Wed, Dec 7, 2011 at 7:55 AM, Vinay Sajip wrote:
>
> On Dec 7, 3:50 pm, Ian Clelland wrote:
> > I'm using PyMySQL (https://github.com/petehunt/PyMySQL) -- it's almost a
> > drop-in replacement for MySQLdb. The biggest change is in the data
> > converters
ository somewhere, or just open a ticket and attach patches?
Thoughts? Flames?
Regards,
Ian Clelland
[1] Original at https://github.com/petehunt/PyMySQL, my patches for better
Python 3 support at https://github.com/clelland/PyMySQL
--
You received this message because you are subscribed to the
> that way someone can write an external driver that uses, say, the
> postgresql spcific stuff but make it run on the 500 other postgresql
> drivers.
>
> Alex
>
>
Ian
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Goog
patches?
>
> I asked Martin von Löwis who maintains the Py3K branch in Django official
> SVN repo to review Vinay's changes and merge them, as long as you manage to
> get patches in line with their work I think we're fine.
>
Jannis
>
> --
> You received this mess
#x27; anywhere in the
summary/keywords/description, but I will allow that my trac-fu may be weak)
I'm looking into what it would take to separate these concerns.
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google Groups
"Django developers&qu
Just finished a full suite test, with the PyMySQL adapter, and I'm down to
5 failures and 2 errors:
Gory details:
http://dpaste.com/hold/667992/
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
On Wed, Dec 7, 2011 at 9:59 PM, Vinay Sajip wrote:
> On Dec 7, 8:38 pm, Ian Clelland wrote:
>
> > Thoughts?
>
> A further update: of my 24 failures, 17 are in multiple_database, as
> are 3 failures. But I get the same errors with unpatched Django 2.x
> running with
On Wed, Dec 7, 2011 at 11:40 PM, Vinay Sajip wrote:
>
> On Dec 8, 6:46 am, Ian Clelland wrote:
> >
> > There also seem to be a number of unicode-related errors there (mixed
> > collations; unrecognized characters) -- Could that be related to the
> lines
>
> I&#x
On Thursday, December 8, 2011, Jens Diemer
wrote:
> Am 07.12.2011 21:38, schrieb Ian Clelland:
>>
>> PyMySQL is a pure python implementation of PEP 249 for MySQL, and
supports
>> Python 2.4 - 3.2, and MySQL 4.1 and higher.
>
> Another goal of PyMySQL would be to u
sions, but it's
looking pretty good.
I also managed to compile Vinay's clone of the MySQLdb driver for python 3,
and with just one extra patch, it looks like all tests are passing with
that code as well!
On Wednesday, December 7, 2011, Ian Clelland wrote:
> Just finished a fu
ped=91, expected failures=3)
Python 3, MySQL:
Ran 4432 tests in 446.825s
OK (skipped=96, expected failures=2, unexpected successes=1)
Thanks a lot to Vinay for his amazing work pulling this all together!
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google
On Thu, Dec 8, 2011 at 5:56 PM, Vinay Sajip wrote:
>
> On Dec 8, 11:39 pm, Ian Clelland wrote:
> > I now have Django passing its entire unit test suite with the MySQL and
> > SQLite backends, on Python 2.6.7 and Python 3.2.2
>
> Ian,
>
> Thanks for the compreh
On Fri, Dec 9, 2011 at 8:36 AM, Tom Evans wrote:
> On Fri, Dec 9, 2011 at 4:17 PM, Ian Clelland wrote:
> > Unscientifically, trunk without the Python 3 patches runs 1.5% faster w/
> > SQLite, 0.6% faster w/ MySQL. (based on a sample size of 1 :) )
> >
>
&
'm sticking with three places all around)
All times are in seconds. This was tested on Python 2.6.7, and SQLite,
against Django trunk from this morning (a), and Vinay's 3k-compatible
branch from yesterday (b).
--
Regards,
Ian Clelland
--
You received this message because you are subs
finished a run of tests overnight --
The branch passes the complete test suite now for me, under Python 2.5.6,
2.6.7, 2.7.2, and 3.2.2, with the sqlite, MySQLdb, and psycopg2 backends.
(Sorry, no Oracle here.)
--
Regards,
Ian Clelland
--
You received this message because you are subscribe
On Thu, Dec 8, 2011 at 7:46 AM, Ian Clelland wrote:
>
>
> On Thursday, December 8, 2011, Jens Diemer
> wrote:
> > Am 07.12.2011 21:38, schrieb Ian Clelland:
> >>
> >> PyMySQL is a pure python implementation of PEP 249 for MySQL, and
> supports
> >
Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-
e) to match the handling of null / blank / undefined values to what
a browser would do.
Not having the ability to get past a Django-mandated ValidationError would
certainly impact the user experience in this case ;)
--
Regards,
Ian Clelland
--
You received this message because you are subscribed
code is incorrect, and should be using a
different method to check the state of the database, but a test like this
could continue to pass even in the event of an actual regression, and the
developers wouldn't even know that their test was wrong. At least with a
mention in the release notes, [
On Thursday, March 8, 2012, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> PEP 414 was accepted a few days ago. It's designed to make it easier to
support 2.6, 2.7, 3.3+ on the same codebase.
(finishes reading)
Ugh. I'm starting to expect "PEP 499: In a last-ditch effort to encour
On Thu, Mar 8, 2012 at 8:48 AM, Carl Meyer wrote:
> Hi Ian,
>
> On 03/08/2012 08:40 AM, Ian Clelland wrote:
> > On Thursday, March 8, 2012, Aymeric Augustin
> > > <mailto:aymeric.augus...@polytechnique.org>> wrote:
> >> PEP 414 was accepted a few days a
ttps://github.com/django/django/pull/1044
>
> Any objections?
>
> --
> Aymeric.
>
>
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and sto
it by going to a longer key at that point, but you
don't have to. Perhaps the best thing for Django to do would be to issue a
warning in that case that the key is shorter than it could be.
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google Gr
a foreign key join like
select * from A join B on (A.fk = B.pk)
will not join rows where A.fk and B.pk are both NULL. I would expect
to be able to safely perform a query like
delete from A where A.fk = NULL
knowing that no rows would be deleted, and I expected (before I
discovered this behaviou
se the pattern I outlined above?
> 2) Use a different pattern (e.g. always use TestCase assert methods
> where it is possible)?
> 3) Simply not care about any of this?
I'm +1 for #1, for consistency and clarity, but not for any technical reasons.
--
Regards,
Ian Clelland
--
You receiv
t:
assert (res.status_code == 200), "The status code returned was incorrect"
or even
assert (res.status_code == 200), ("%s != 200" % res.status_code)
At least some of the examples that Luke pointed to are using that
style, and it definitely makes more sense than just asser
ill be necessary.
http://docs.python.org/library/collections.html#collections.namedtuple
--
Regards,
Ian Clelland
--
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.co
d timezone, when I can know it for sure (e.g., {{
timestamp|date:"c" }}+00:00 ). I would absolutely support adding a "real"
ISO-8601 formatter to the standard filter library.
--
Regards,
Ian Clelland
--
You received this message because you are subscribed to the Google Groups
&
f you normalize to a common TZ, eg.
> UTC, and only apply a local TZ offset when rendering the output to the
> user.
>
Absolutely -- UTC is the only way to go in that situation, but it might be
that the UTC timestamps are just a cache, generated from the local-time/TZ
combination when neede
On Thu, Jun 30, 2011 at 2:10 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> On 30 juin 2011, at 19:06, Daniel Swarbrick wrote:
>
> > On Jun 30, 6:31 pm, Ian Clelland wrote:
> >
> >> As a counterexample, I have needed to store wall-clock time
ly see the object committed by Process 2.
I expect to open up a ticket for this, unless someone can tell me "you're
doing it wrong", or point me to another ticket (I've scanned the trac
database, but didn't see anything identical. 15507 touches this, but won't
a
And, of course, immediately after posting this, I find
http://code.djangoproject.com/ticket/13906, which seems to cover much of the
same area.
Ian
On Fri, Sep 2, 2011 at 11:04 AM, Ian Clelland wrote:
> I'm seeing errors which I believe are due to a race cond
On Fri, Sep 2, 2011 at 11:22 AM, Jeremy Dunck wrote:
> On Fri, Sep 2, 2011 at 11:04 AM, Ian Clelland wrote:
> > I'm seeing errors which I believe are due to a race condition in
> > django.db.models.query.get_or_create, on a fairly high traffic site. Our
> > production
If we can hold off until that is a dependency of Django, then the code will
be quite pleasant to implement. Before then, it will likely end up as an
ugly hack, probably involving building and compiliing regexes at run-time to
match whatever is in DATE_FORM
_INPUT_FORMAT setting, which defaults if unset to DATE_FORMAT,
would be more appropriate.
--
Regards,
Ian Clelland
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this
57 matches
Mail list logo
