Re: [Python-ideas] Importing public symbols and simultainiously privatizing them, is too noisy

2016-12-28 Thread Abe Dillon
> > I avoid __all__ like the plague. Too easy for it to get out of sync with > the API when i forget to add a new symbol. Your API should be one of the most stable parts of your code, no? On Fri, Mar 18, 2016 at 4:29 PM, Chris Barker wrote: > On Wed, Mar 16, 2016 at

Re: [Python-ideas] VT100 style escape codes in Windows

2016-12-28 Thread Random832
On Wed, Dec 28, 2016, at 18:33, Joseph Hackman wrote: > The quick answer is that the MSDN doc indicates support from windows 2000 > onward, with no notes for partial compatability: > https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx That's the function itself (and

Re: [Python-ideas] VT100 style escape codes in Windows

2016-12-28 Thread Joseph Hackman
Welp! You're definitely correct. Ah well. On 28 December 2016 at 18:33, Joseph Hackman wrote: > The quick answer is that the MSDN doc indicates support from windows 2000 > onward, with no notes for partial compatability: >

Re: [Python-ideas] VT100 style escape codes in Windows

2016-12-28 Thread Joseph Hackman
The quick answer is that the MSDN doc indicates support from windows 2000 onward, with no notes for partial compatability: https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx I'll build a Windows 7 VM to test. I believe Python 3.6 is only supported on Vista+ and 3.7

Re: [Python-ideas] VT100 style escape codes in Windows

2016-12-28 Thread Paul Moore
Would this only apply to recent versions of Windows? (IIRC, the VT100 support is Win10 only). If so, I'd be concerned about scripts that worked on *some* Windows versions but not others. And in particular, about scripts written on Unix using raw VT codes rather than using a portable solution like

Re: [Python-ideas] Function arguments in tracebacks

2016-12-28 Thread Nathaniel Smith
On Dec 28, 2016 12:44, "Brett Cannon" wrote: My quick on-vacation response is that attaching more objects to exceptions is typically viewed as dangerous as it can lead to those objects being kept alive longer than expected (see the discussions about richer error messages to see

Re: [Python-ideas] incremental hashing in __hash__

2016-12-28 Thread Ned Batchelder
On 12/28/16 12:27 PM, j...@math.brown.edu wrote: > On Wed, Dec 28, 2016 at 11:48 AM, Ned Batchelder > > wrote: > > You can write a simple function to use hash iteratively to hash > the entire stream in constant space and linear time: >

Re: [Python-ideas] Function arguments in tracebacks

2016-12-28 Thread Emanuel Landeholm
I think an argument could be made for including the str() of parameters of primitive types and with small values (for some value of "primitive" and "small", can of worms here...). I'm thinking numbers and short strings. Maybe a flag to control this behaviour? My gut feeling is that this would be a

Re: [Python-ideas] incremental hashing in __hash__

2016-12-28 Thread jab
On Wed, Dec 28, 2016 at 12:10 PM, Ethan Furman wrote: > In other words, objects that do not compare equal can also have the same > hash value (although too much of that will reduce the efficiency of > Python's containers). > Yes, I realize that unequal objects can return the

Re: [Python-ideas] incremental hashing in __hash__

2016-12-28 Thread jab
I actually have been poking around that code already. I also found https://github.com/vperron/python-superfasthash/blob/master/superfasthash.py in case of interest. But it still seems like library authors with this use case should keep their library code free of implementation details like this,