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 co
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", "copy
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 use
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:
sorte
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 e
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
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
> certai
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
> defini
[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.
&g
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 2
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
http://mail.python
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
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.
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()
>>> files = os.listdir(somedir)
Instead of a codecs error handler name, how about a callback for
converting bytes to str?
os.listd
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 discuss
> 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? F
Andrew McNamara wrote:
>
> I'm not altogether sure there. The parsing state machine is all
> written in C, and deals with signed chars - I expect we'll need two
> versions of that (or one version that's compiled twice using
> pre-processor macros). Quite a large job. Suggestions gratefully
> recei
>From Tony Meyer [mailto:[EMAIL PROTECTED]:
> Can anyone here suggest a way to get around this? As a specific
> example: the SpamBayes distribution includes a py2exe binary, and it
> would be nice (although not essential) to build this with 2.4.
> However, at the moment my name goes down as the r
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
f
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()
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.
> 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
> accelera
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:
>
Nick Coghlan wrote:
>Anders J. Munch wrote:
>
>>Note that __with__ and __enter__ could be combined into one with no
>>loss of functionality:
>>
>>abc,VAR = (EXPR).__with__()
>>
>
>They can't be combined, because they're i
25 matches
Mail list logo