On 22/08/2009 6:52 PM, Stephen J. Turnbull wrote: > Mark Hammond writes: > > On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote: > > > Possibly - although I would expect the existing section names be reused > > when applied to a versioned file, I'd be more than happy for the hg guys > > to declare new names are appropriate for this. > > If there's already an [Encode] section, that's different. (I don't > details, I'm not that big a Mercurial fan.) But you'd still need a > way to differentiate win32text rules from other encoding rules. As mentioned in my previous post, I'm trying to avoid bike-shedding what the hg guys are better placed to decree. How they choose to spell these options is something for hg to decide, and I doubt my opinion matters enough to bother sharing, let alone advocating. > > > > > This way you aren't *enabling* extensions in this versioned file, > > > > > > True, but how many people will just download the extension and enable > > > it? > > > > In the ideal world, exactly as many people who would read the Python > > developer guide, then download and install the extension based purely on > > that. IOW, it is Python itself setting the policy, so people need to > > make their own decisions based on that, regardless of whether the tool > > enforces it or not. > > You're missing the point. I'm not talking about whether it will work > for Python, I'm talking about the worry that somebody will post a way > cool Python branch and require a private extension, which everybody > will just automatically install and enable, which extension then > proceeds to phone home to Spammer Haven, Inc. with the contents of > your email contact list. That's what I mean by "social engineering," > and why I worry about policy pushback from Mercurial HQ. No, you are missing the point - social engineering doesn't require tool support - tools simply make certain things easier. > Maybe that's more paranoid than they are.... But it can't hurt your > cause to be ready for that kind of worry. If this becomes seen as 'my' cause, I suspect it will run out of steam very quickly. I truly hope python-dev, as a community, takes some ownership of this issue or I predict the effort will fizzle out without a workable solution. There seem to be a number of people who agree the status-quo isn't acceptable, so I'm not sure what would happen in that case... Cheers, Mark
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4