>
> 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
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
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:
>
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
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
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
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:
>
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
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
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,
10 matches
Mail list logo