Paul Moore:
> Finding out whether users/projects typically write such a helper
> function for themselves would be a better way of getting this
> information. Personally, I suspect they don't, but facts beat
> speculation.
Well, I did. It was necessary to get 2to3 conversion to work(*). I turned
Chris Angelico wrote:
This is off-topic for this thread, but still...
The trouble is that your arguably just as wrong is an
indistinguishable case. If you don't want two different calculations'
NaNs to *ever* compare equal, the only solution is to have all NaNs
compare unequal
For two NaNs
Larry Hastings wrote:
inspect.signature gets this right:
import inspect
str(inspect.signature(c.foo))
'(a)'
Not always.
: Python 3.4.0b2+ (default:32f9e0ae23f7, Jan 18 2014, 13:56:31)
: [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin
: Type help, copyright,
Larry Hastings wrote:
I look forward to an alternate suggestion. This is the least-bad
thing I could come up with.
How about a naming convention instead, where using a leading
underscore in a parameter name is a hint that it is positional-only.
For example, the docstring of sorted:
Hi, offering my DKK 0.50 on the subject. I've used an in-house enum
type for the better part of a decade - put up at
http://unicollect.dk/download/oss/dc_enum.zip for inspiration.
I'm partial to an int subclass, or at least something very int-like,
because wrapping C libraries is such a major
On 1/1/2012 12:28 PM, Christian Heimes wrote:
I understood Alexander Klink and Julian Wälde, hash...@alech.de, as
saying that they consider that using a random non-zero start value is
sufficient to make the hash non-vulnerable.
Sufficient against their current attack. But will it last? For
s...@pobox.com wrote:
I guess I have my work cut out for me. It appears my preferred mail reader,
VM, is not supported out-of-the-box by GNU Emacs (they still use Rmail and
Babyl for some reason), and I'm not sure the investment trying to get XEmacs
built with MULE is worth the effort.
Use a
Terry Reedy wrote:
Localized messages should be in addition to rather than a replacement
for the English version. I thought we had this discussion somewhere --
here? ideas? maybe a tracker issue?
This could be done as a free-standing library, there's no reason to
involve core CPython. Just do
On Sun, Dec 7, 2008 at 3:53 PM, Terry Reedy [EMAIL PROTECTED] wrote:
try:
files = os.listdir(somedir, errors = strict)
except OSError as e:
log(verbose error message that includes somedir and e)
files = os.listdir(somedir)
Instead of a codecs error handler name, how about a callback for
M.-A. Lemburg wrote:
Well, this is not too far away from just putting the whole decoding
logic into the application directly:
files = [filename.decode(filesystemencoding, errors='warnreplace')
for filename in os.listdir(dir)]
(or os.listdirb() if that's where the discussion is
Gregory P. Smith wrote:
The documentation for the struct module says:
http://docs.python.org/dev/library/struct.html#module-struct
short is 2 bytes; int and long are 4 bytes; long long ( __int64 on
Windows) is 8 bytes
and lists 'l' and 'L' as the pack code for a C long.
As its
Scott Dial wrote:
In general, this is not true. FAT16 can address a 2GB device and I can
think of at least one embedded system I am working with that does not
support FAT32. If anything, at least .pyzip reduces to .pyz in 8dot3
(whereas .py.z reduces to .z *yikes!*). However, I think it is
Andy C wrote:
So does everyone agree that there should be a new extension called
.pyz?
How about .pyzip instead? To make it more obvious, and not mistakable for
.py.z.
- Anders
___
Python-Dev mailing list
Python-Dev@python.org
Tim Peters wrote:
Do note that this discussion is only about Python 3. Under the view
that it was a (minor, but real) design error to /try/ extending
Python's integer mod definition to floats, if __mod__, and __divmod__
and __floordiv__ go away for binary floats in P3K they should
certainly
Tim Peters wrote:
Please read the whole thread. Maybe you did, but you said nothing
here that indicated you had. The issues aren't about tiny integers
that happen to be in float format, where the result is exactly
representable as a float too. Those don't create problems for any
definition
[Tim Peters]
[Anders J. Munch]
I did read the whole thread, and I saw your -1%1e100 example. Mixing
floating-point numbers of very different magnitude can get you in
trouble - e.g. -1+1e100==1e100. I don't think -1%1e100 is all that
worse.
Except that it's very easy to return
Nick Coghlan did a +1 job to write:
1. Amend the statement specification such that:
with EXPR as VAR:
BLOCK
is translated as:
abc = (EXPR).__with__()
exc = (None, None, None)
VAR = abc.__enter__()
try:
try:
Walter Dörwald wrote:
We should have one uniform way of representing time in Python. IMHO
datetime objects are the natural choice.
Alas datetime objects do not unambiguously identify a point in time.
datetime objects are not timestamps: They represent the related but
different concept of
I wrote:
Alas datetime objects do not unambiguously identify a point in time.
datetime objects are not timestamps: They represent the related but
different concept of _local time_, which can be good for
presentation,
but shouldn't be allowed anywhere near a persistent store.
GvR
From: Guido van Rossum [mailto:[EMAIL PROTECTED]
datetime.datetime.utcfromtimestamp(time.time()) -
datetime.datetime.utcnow()
datetime.timedelta(0)
I overlooked the utcfromtimestamp method, sorry.
Your bug is similar to comparing centimeters to inches, or speed to
acceleration, or any
Shane Hathaway wrote:
Guido van Rossum wrote:
Consider an application where you have to acquire *two* locks regularly:
You really have to write it like this:
Shane, you've already solved this one more elegantly:
def lockBoth():
return combining(lock1.locking(), lock2.locking())
GvR wrote:
[Nick Coghlan]
Option 2: mimic if semantics
An 'else' clause on a block statement behaves vaguely like the else
clause on
an if statement - the clause is executed only if the first suite is
never
entered, but no exception occurs (i.e. StopIteration is raised by the
first
22 matches
Mail list logo
