DjangoBot: #django-dev

phatmonkey: kind of :)

I'm your soc student - just wanted to apologise for not being around

exams getting on top of me

oh, it's ok. I wasn't expecting you to do much until mid June

last exam is on friday 20th, I think i'll give myself the weekend to, er, recover

then I'll get going - I'd like to get started

phatmonkey: sounds good to me

for some reason, it never occurred to me to look for this IRC channel :-/

welcome aboard :)

:)

jdunck: well, it's only a few months old :)

so, i'd like to get a clue about nfa. best to just read wiki/NewformsAdminBranch and browse keywords containing nfa-blocker ?

probably. brosner has a good idea of where things are I think.

the major thing I'd like to happen before merge is to either make the ModelAdmin methods more granular, or to get class based admin views working

yeah the best place is looking at the nfa-blocker tickets. there are some in there that i can going to defer until later.

s/can/am

jkocherhans, what is the status of class based views? you told me that the way of getting a queryset should be modified, any update?

how serious are we about nfa sprint? :)

david`bgk: haven't worked on them. I'm slammed for the next month or so.

jkocherhans: class-based views is a djdev thread?

jkocherhans, ok

jdunck: i am not. there are too many little things that require a bit of internal knowledge of nfa. i am rolling through the last big blocker items today and tomorrow

jdunck: hmmm... I don't remember if there's a thread there or not. I don't remember one. Sprint wise? I plan on participating, but I'm not sure very many people sprinting on it would be useful.

well, i was responding to the pitchforks about 1.0 soonest vs. landing nfa vs. sprint rather than 1.0 w/o nfa

i'd rather code than complain :)

jkocherhans: so class-based views isn't this ?

I think nfa is close enough to wait. James convinced me that we shouldn't do 1.0 w/o it.

yeah it really is close imho

jdunck: that's the generic view portion, at pycon I discussed taking the same approach with the admin

discussed with Adrian that is

so i guess i'm proving your point about sprinting not being terribly productive :)

well, a sprint would mean I actually feel obligated to sit down and code for a day or two ;)

I think it might be more productive if we could merge nfa *before* the sprint

maybe a week or so beforehand

yeah there are a ton of nfa-someday tickets that people could hack on

merging nfa with trunk asap seems a good idea

I never used it because I was using the queryset refactor branch for a while

I want to work out the ModelAdmin interface before we merge. It really bothers me right now, and merging kind of blesses the api in my opinoin.

agreed

is 'Large streaming uploads' really accepted as a 1.0 feature?

i'd be happy to see it, but it somewhat surprises me :)

I think it's on the maybe list

not sure how much work is left, but it seems close

is that axiak_ ticket 2070 you're talking about?

he seemed to indicate that it was done. But hopefully he'll chime in.

seems like the fix to #7366 (on cset [7575]) breaks on python2.3 ...

because sorted() is not present on python2.3

should I reopen the bug or fill another?

file another one

jbronn_: gis question-- is there a reasonable use case for point.distance to *not* throw an exception when the other geom has a different srid?

jdunck: As it is it doesn't throw an exception because if its in a different SRID it'll be implicitly transformed to the SRID of the field via the ST_Transform procedure. Exceptions are only thrown if you're trying to do something the spatial database doesn't support (e.g., geodetic distances on PostGIS that aren't w/PointFields).

jbronn: i mean geos.Point instances

no implicit transform (or exception) occurring there, as far as i can tell.

jdunck: what's the problem you're running into, specifically?

silently wrong distance results.

dpaste in just a ec

sec*

jbronn: http://dpaste.com/55938/

jbronn: i've gotta run, but seems to me either "other" should be transform(clone=True) to match, or an exception should be thrown

jdunck: You're using GEOS `distance` which is only pythageorean 2D distances. Remember GEOS has no knowledge of what the spatial reference system is.

sure, but we wrap distance there, and we *do* know, since we have gis.geos.Point, which has srid

jdunck: right a patch then takes into account the differences in spatial reference systems and can deal with geodetic differences. I'm hesitant to couple GEOSGeometry like that to the model API.

on svn branch?

you prefer implicit transform or exception?

implicit transform is sensible since distance has this docstring: ' Units will be in those of the coordinate system of

the Geometry.'

Yes, in theory implicit transformation will be ideal; but there are wrinkles to this approach and those have to do with the limitations in GEOS' distance implementation cause it thinks everything is 2D and doesn't treat geodetic SRID's any differently than projected ones.

ok, but Point.transform uses GDAL, which is aware, right?

Not aware in the sense I'm saying. By 'aware' I mean you would use a spherical and/or a great circle function for distance calcs on geodetic srids rather and the normal pythogorean GEOS distance (what I mean by 2D) for everything else.

Bottom line making it smarter is not a trivial matter, so I'd rather keep it as dumb as GEOS currently has it.