On Wed, Jan 2, 2019 at 11:26 AM Nikita Popov <nikita....@gmail.com> wrote:
> On Wed, Jan 2, 2019 at 12:30 AM Stanislav Malyshev <smalys...@gmail.com> > wrote: > > We have a rather hard policy against ini options that influence language > behavior. Locale-dependent language behavior is essentially the same issue, > just worse due to the mentioned issues, in particularly lack of > thread-safety and the possibility that the locale is changed by third-party > libraries at runtime. > > We have removed existing ini flags controlling language behavior in the > past. I would say these removals were much more significant than what is > proposed here, but we did them anyway, and I think we are now in a better > place for it. > Unless I'm missing something, changing this behavior would require a full, line-by-line audit of the code - with no Search & Replace patterns that can find these instances in any reasonable level of reliability. Every place where a floating number (which could come from anywhere, so not very easy to track) is used in a string context (which too can happen in countless different contexts, virtually impossible to track) would be affected. Sounds pretty nightmarish to me. I for one fail to recall a behavioral change that was quite as significant as this one in terms of the complexity of finding instances that must be updated. Like Stas, I'm not disputing that this is not an ideal behavior or that we'd do it differently if we were starting from scratch - but I also agree with him that it's pretty much out of the question to simply change it at this point. Can you point out a change you believe is as or more significant than this one that we did? I think the only one that comes close is magic_quotes_runtime, and even that was significantly easier to handle in terms of the cost of auditing the code (again, unless I'm missing something, which is of course very much a possibility). The solution for this *might* be a very unholy one - actually going against our practices adding a new INI entry to would disable the locale-awareness for float->string conversions; But for upgrade considerations, I don't think we can even consider simply changing this behavior and forcing virtually everyone using a non-dot decimal separator to undergo a full code audit. My 2c. Zeev
