Opened 14 years ago

Closed 5 years ago

#3592 closed defect (wontfix)

Python bindings: allow chaining method calls while preserving C++ objects alive

Reported by: Even Rouault Owned by: Even Rouault
Priority: normal Milestone: closed_because_of_github_migration
Component: PythonBindings Version: unspecified
Severity: normal Keywords:
Cc: hobu, warmerdam, antonio


Currently, a line like ogr.Open('data/poly.shp').GetLayer(0).GetNextFeature().GetGeometryRef().ExportToWkt() causes a crash

Attachments (2)

proposal_for_ticket_3592_but_do_not_apply.patch (15.1 KB ) - added by Even Rouault 14 years ago.
test_for_ticket_3592.patch (3.7 KB ) - added by Even Rouault 14 years ago.

Download all attachments as: .zip

Change History (9)

comment:1 by Even Rouault, 14 years ago

Milestone: 1.8.0

I've found a solution for the above issue, but unfortunately it breaks existing code (many tests in autotest suite).

For example :

ds = gdal.Open('foo.tif')
msk = ds.GetRasterBand(1).GetMaskBand()
ds = None

With the proposed patch, after ds = None, the C++ object is still alive (until msk goes out of scope), so the Delete() can fail on Windows for example because the underlying file handle isn't yet closed...

by Even Rouault, 14 years ago

Attachment: test_for_ticket_3592.patch added

comment:2 by hobu, 14 years ago

Cc: warmerdam added

As I was saying on IRC, the problem that happens is when people were improperly destroying stuff.

I think the above behavior that the autotests has is wrong and broken and should be fixed, but I realize it is a lot of work to do so.

To make this even more ridiculous, what if we made a gdal.ManageObjects() and gdal.DontManageObjects() global method set, similar to the gdal.UseExceptions() stuff we have to allow people to turn this behavior off. I would propose that the new, correct behavior be on by default for GDAL 1.8+, however, with a note in the release notes.

comment:3 by antonio, 13 years ago

Cc: antonio added

comment:4 by Jukka Rahkonen, 9 years ago

Is the new, correct behavior now implemented and on by default?

comment:5 by BrenBarn, 8 years ago

Sorry, but this is completely crazy. The excuse that you can't make GetLayer(0).NextFeature() work because it will break code that explicitly sets something to None and then tries to delete it is feeble at best. The idea that it's "difficult to correct" is even feebler. It's like telling someone their car might explode when they turn the ignition key, but you can't fix it because it would disappoint people who like pouring strawberry jam into their radiator.

Calling methods on objects is basic behavior and should work. Messing around with setting things to None and then trying to pull the rug out from under those objects is not something that needs to be supported. It's not even that method chaining doesn't work; it actually crashes the entire interpreter.

I am curious what other issues could possibly be considered more important than this.

comment:6 by Jukka Rahkonen, 8 years ago

"I am curious what other issues could possibly be considered more important than this."

Not trying to say that this issue is not important but it has never bothered me. However, I am just an end user, not programmer. Still, last comment on issue being from 5 years ago I believe that I am not alone.

I am curious to know if you can't find any more important issues from this list

comment:7 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: newclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to if it is not already reported there.

Note: See TracTickets for help on using tickets.