On Fri, Feb 27, 2026 at 08:12:06AM -0600, D'Arcy Cain <[email protected]> wrote:
> I made a mistake. It was a long time ago when I first created PyGreSQL > (PyGres95 back then). When I wanted a method to get one entry from a table > using the primary key I called it "get". That was pretty stupid in > retrospect. That name conflicts with dict methods. I don't know about > others but I like to combine the DB class with dict and that makes it hard. > > I think that we should get rid of that and find a better name. I like > "select" as it is closer to the SQL statement that get is based on. > > Obviously we can't just change something like this overnight but what do > others think about this in theory? If it makes sense we could add the new > name as an alias for get now and deprecate get over a long period of time. > > Of course, this is easily worked around with a sub-class but I really feel > that get is a wart that needs to be excised. > > Cheers. > > -- > D'Arcy J.M. Cain > PyGreSQL Development Group > http://www.PyGreSQL.org IM:[email protected] Here's an opinion. Backwards compatibility is important. Live with the mistake (if it was one). Please don't knowingly break an unknown number of programs. Naming is famously hard. But that's OK. Changing a name, and breaking other people's code (when they might be dead and unable to "update" it) is not OK. By all means, add a better name, but don't take away the longstanding existing name. It will cause problems that do not need to exist. And that can generate expense that doesn't need to exist in order to identify the problem and fix it when some software that's been working for years suddenly breaks. Of course, there are reasons that might require backwards-incompatibility, such as a security vulnerability, or maybe performance, but mere regret over a naming choice shouldn't count as one. Personally, I think get is a better name than select if all it does is select a single record by its primary key. Calling it select might seem to imply a lot more functionality than that. Would a subclass be so bad? Also, you could maybe make get do dict stuff when passed a string, and the original stuff when passed an primary key integer. Just a thought. Though I don't really understand why there would be a clash between a get method on a db connection object that selects, and a get/dict method (presumably) on a result set object, so maybe this isn't a helpful suggestion. cheers, raf _______________________________________________ PyGreSQL mailing list [email protected] https://mail.vex.net/mailman/listinfo/pygresql
