Tim Peters added the comment:
I'm more puzzled by why `__hash__()` here bothers to call `hex()` at all. It's
faster to hash the underlying int as-is, and collisions in this specific
context would still be rare.
@Josh, note that there's nothing bad about getting sequentia
Tim Peters added the comment:
I would not call this a bug - it's just usually a silly thing to do ;-)
Note, e.g., that p{N} is shorthand for writing p N times. For example, p{4} is
much the same as (but not exactly so in all cases; e.g., if `p` happens to
contain a capturing group
Tim Peters added the comment:
>> (?<=a)(?<=a)(?<=a)(?<=a)
> There are four different points.
> If a1 before a2 and a2 before a3 and a3 before a4 and a4
> before something.
Sorry, that view doesn't make any sense. A successful lookbehind assertion
matches the e
Tim Peters added the comment:
BTW, note that the idea "successful lookaround assertions match an empty
string" isn't just a figure of speech: it's the literal truth, and - indeed -
is key to understanding what happens here. You can see this by adding some
capturi
Tim Peters added the comment:
One more useless ;-) data point, from Macsyma:
? acosh;
-- Function: acosh ()
- Hyperbolic Arc Cosine.
I don't like "area" - while accurate, nobody else uses it. Gratuitous novelty
is no virtue ;-) I like "inverse" better than &
Changes by Tim Tisdall :
--
nosy: +Tim.Tisdall
___
Python tracker
<http://bugs.python.org/issue7687>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Tisdall :
--
nosy: +Tim.Tisdall
___
Python tracker
<http://bugs.python.org/issue7834>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
A note from Guido, from about 2 years ago:
https://mail.python.org/pipermail/python-dev/2012-July/121127.html
"""
TBH, I think that adding nanosecond precision to the datetime type is
not unthinkable. You'll have to come up with some clever ba
Tim Peters added the comment:
Yup, it's definitely more than 8 bytes. In addition to the comments you
quoted, an in-memory datetime object also has a full Python object header, a
member to cache the hash code, and a byte devoted to saying whether or not a
tzinfo member is present.
Gue
Tim Peters added the comment:
Of course pickles come with overheads too - don't be tedious ;-) The point is
that the guts of the datetime pickling is this:
basestate = PyBytes_FromStringAndSize((char *)self->data,
_PyDateTime_DATETIME_DATASIZE
Tim Peters added the comment:
I'm afraid "microoptimizations" aren't worth measuring to begin with, since,
well, they're "micro" ;-) Seriously, switch compilers, compilation flags, or
move to a new release of a single compiler, and a micro-optimization ofte
Tim Peters added the comment:
I have no idea what was done to pickle for Python3, but this line works for me
to unpickle a Python2 protocol 2 datetime pickle under Python3, where P2 is the
Python2 pickle string:
pickle.loads(bytes(P2, encoding='latin1'), encoding='bytes
Tim Peters added the comment:
I'm sympathetic, but I don't see a good solution here without using
incompatible code.
ndiff was built to generate "the highest quality diff possible", for text
written and edited by humans, where "quality" is measured by hu
Tim Peters added the comment:
@eddygeek, I'd still call something so unintuitive "a bug" - it's hard to
believe this is the _intended_ way to get it to work. So I'd keep this open
until someone with better know
Tim Peters added the comment:
Was the title of this meant to be
"datetime.date() should accept a datetime.datetime as init parameter"
instead? That's what the example appears to be getting at.
If so, -1. Datetime objects already have .date(), .time(), and .timetz()
met
Tim Peters added the comment:
Alexander, I don't see a need to make everything a one-liner. Dealing with a
mix of dates and datetimes is easily sorted out with an `if` statement, like
def func(thedate):
if isinstance(thedate, datetime.datetime):
thedate = thedate.date()
Changes by Tim Chase :
--
nosy: +Gumnos
___
Python tracker
<http://bugs.python.org/issue22167>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
+1. I agree it's a bug, that the diagnosis is correct, and that the patch will
fix it :-)
--
___
Python tracker
<http://bugs.python.org/is
Tim Peters added the comment:
I'm OK with -1, but I don't get that or -0.0 on 32-bit Windows Py 3.4.1:
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license()" for more i
Tim Peters added the comment:
To be clear, I agree -0.0 is "the correct" answer, and -1.0 is at best
defensible via a mostly-inappropriate limit argument. But in Py3 floor
division of floats returns an integer, and there is no integer -0. Nor, God
willing, will there ever be ;-)
Tim Peters added the comment:
Sorry, Mark - I took a true thing and careleslly turned it into a false thing
;-)
It's math.floor(a_float) that returns an int in Py3, not floor division of
floats. So, yup, no real problem with returning -0.0 after all; it's just that
it can't
Changes by Tim Smith :
--
nosy: +tdsmith
___
Python tracker
<http://bugs.python.org/issue22269>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
This should remain closed. It's "a feature" that doctest demands exact textual
equality, and that the only way to override this is with one of the `#doctest:`
flags. "What you see is what you get - exactly" is one of doctest's
fun
New submission from Tim Chase:
If a mailbox.MH() object is created by pointing at a path that exists but
doesn't contain a ".mh_sequences" file, it raises an exception upon iteration
over .{iter,}items() rather than gracefully assuming that the file is empty. I
encountered t
Changes by Tim Chase :
--
keywords: +patch
Added file: http://bugs.python.org/file36515/mailbox_mh_sequences.diff
___
Python tracker
<http://bugs.python.org/issue22
Changes by Tim Chase :
Added file: http://bugs.python.org/file36516/mailbox_mh_sequences_lbyl.diff
___
Python tracker
<http://bugs.python.org/issue22319>
___
___
Pytho
Tim Chase added the comment:
I had to tweak the example reproduction code as it seemed to succeed (i.e.,
fail to demonstrate the problem) in some instances. The same exception occurs,
but here's the full original traceback:
$ cd /home/tim/.claws-mail/imapcache/mail.example.
Tim Peters added the comment:
Floor division on floats is an unattractive nuisance and should be removed,
period - so there ;-)
But short of that, I favor leaving it alone. Whose life would be improved by
changing it to return an int? Not mine - and doing so anyway is bound to break
New submission from Tim Smith:
Homebrew, the OS X package manager, distributes python3 as a framework build.
We like to be able to control the shebang that gets written to scripts
installed with pip. [1]
The path we prefer for invoking the python3 interpreter is like
/usr/local/opt/python3
Changes by Tim Golden :
--
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Tim Peters added the comment:
@pitrou, I think usability is a lot more valuable than cross-feature "formal
consistency" here. I've been extracting bit fields for decades, and always
think of them in terms of "least-significant bit and number of bits". Perhaps
the
Tim Peters added the comment:
@anon, sorry, but we can't accept any code from you unless you have a real name
and fill out a contributor agreement:
http://www.python.org/psf/contrib/
This is legal crud, and I'm not a lawyer. But, in particular, lawyers have
told me that - in th
Tim Peters added the comment:
@HCT, see http://bugs.python.org/issue19915#msg205713 for what's "semantically
wrong". Ints are not arrays - slicing is unnatural.
The point about error checking is that if this were supported via slicing
notation, then the _helpful_ exceptions o
Tim Peters added the comment:
@anon, not to worry: someone else will write the code. Maybe even me ;-)
BTW, "public domain" is not a license. It's the absence of a license. Our
lawyers would not accept that even if you
Changes by Tim Golden :
--
versions: -Python 2.6, Python 3.1, Python 3.2
___
Python tracker
<http://bugs.python.org/issue19940>
___
___
Python-bugs-list mailin
Changes by Tim Peters :
--
stage: -> committed/rejected
___
Python tracker
<http://bugs.python.org/issue19964>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
It's working fine. `.search()` always finds the leftmost position at which the
pattern matches. In your example, the pattern '1?' does match at index 0: it
first tries to match `1' at index 0. That's the greedy part. The attempt
f
Changes by Tim Peters :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue19964>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
It will always complete, but may take a very long time - this is one of many
ways to write a regexp that can't match requiring time exponential in the
length of the string. It's not a bug - it's the way Python's kind of regexp
engine
Tim Peters added the comment:
Nice to see you, Jurjen! Been a long time :-)
I'd like to see changes here too. It's unclear what "a lazy version" is
intended to mean, exactly, but I agree the actual behavior is surprising, and
that mpool.py is a lot less surprising in
Tim Peters added the comment:
Just for interest, I'll attach the worm-around I mentioned (imu.py). At this
level it's a very simple implementation, but now that I look at it, it's
actually a lazy implementation of imap() (or of an unimaginative ;-)
imap_unordered()).
--
Tim Peters added the comment:
@vajrasky, I didn't close it just because "the usual suspects" haven't chimed
in yet. That is, it's a pretty common kind of report, and these usually
attract the same kinds of comments pointing to other regexp implementations.
So
Tim Peters added the comment:
Closing this. Since nobody else "wants have a go" over two decades so far, no
point waiting for that ;-)
--
resolution: invalid -> wont fix
stage: -> committed/rejected
status: open -> closed
___
Py
Tim Golden added the comment:
I'll try to look at this soonish. Thanks for bringing it back to the
surface.
--
___
Python tracker
<http://bugs.python.org/i
Changes by Tim Peters :
--
priority: high -> normal
___
Python tracker
<http://bugs.python.org/issue8075>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Peters added the comment:
@Zach, "it would be nice" to know more about this. I tried your little program
on a desktop box, 32-bit Windows Vista, Python 3.3.2, but I boosted the loop
count to 10,000. So it ran well over an hour, with a wide variety of other
loads (from 0
Tim Peters added the comment:
Hmm. One obvious difference on my box:
Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:03:43) [MSC v.1600 32 bit
(Intel)] on win32
>>> time.get_clock_info('monotonic')
namespace(adjustable=False, implementation='GetTickCount64()'
Tim Peters added the comment:
@haypo, I've read the PEP and it has great ideas. What I'm wondering is
whether they've been implemented "correctly" in the relevant cases on Windows
here. That Zach see a resolution of 0.0156001 on Windows isn't plausibly a
ques
Tim Peters added the comment:
FYI, this person seems to have made a career ;-) of making sense of the Windows
time functions:
http://stackoverflow.com/questions/7685762/windows-7-timing-functions-how-to-use-getsystemtimeadjustment-correctly
and their site:
http://www.windowstimestamp.com
Tim Peters added the comment:
@Liam, try using the "decimal" module instead. That follows rules much like
the ones people learn as kids.
>>> from decimal import Decimal as D
>>> D("0.1") * 3 # decimal results are computed exactly
Decimal('
Tim Peters added the comment:
I'm not sanguine about fixing any of this :-( The Microsoft docs are awful,
and the more web searches I do the more I realize that absolutely everyone is
confused, just taking their best guesses.
FYI, here are results from your new program on my 32-bit Vist
Tim Golden added the comment:
I'll have a look at this in a week or so when I'm back on-line.
--
___
Python tracker
<http://bugs.python.org/issue18314>
___
__
Tim Peters added the comment:
1. I'm sync'ing with north-america.pool.ntp.org. But the docs on my box say
"Your clock is typically updated once a week", and I believe it.
2. I just ran Zach's program again, with the same Python, and _this_ time
'time'
Tim Peters added the comment:
They certainly should _not_ be swapped, as explained clearly in the message
following the one you referenced. For the first half:
if self._lock.acquire(0):
succeeds if and only if the lock is not held by _any_ thread at the time. In
that case, the lock
Tim Mooney added the comment:
I just tried Python 2.7.6 on x86_64-pc-openindiana151a9. The core issue is
still present. It's not currently causing a build failure, but only because
OpenIndiana 151a9 and Python are using the exact same version of Expat, so the
headers that python&#x
Tim Golden added the comment:
Larry Hastings would have to rule on whether it could get into 3.4 at
this stage.
Paul: are you in a position to apply / test the patch? I've done no more
than glance at it but it looks, from the comments, as though it doesn't
app
Tim Golden added the comment:
Thanks, Larry. Martin's already nosy this issue, but really we need to
see if we have a viable patch before making decisions about 3.4. I'll
take you off the nosy list.
--
___
Python tracker
<http://bu
Changes by Tim Golden :
--
nosy: -larry
___
Python tracker
<http://bugs.python.org/issue16296>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
I've haven't yet seen anyone complain about the inability to compare None
except in the specific context of sorting. If it is in fact specific to
sorting, then this specific symptom and "the problem" are in fact the same
thing ;-)
Tim Peters added the comment:
This is expected. "global" has only to do with the visibility of a name within
a module; it has nothing to do with visibility of mutations across processes.
On a Linux-y system, executing Pool(3) creates 3 child processes, each of which
sees a read-
Tim Peters added the comment:
Excellent idea! But then we should change bool(0.1) to be False too ;-)
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue20
Tim Peters added the comment:
[Nick]
> - deprecate aware time() entirely (raises the thorny question of what to
> return from .time() on an aware datetime() object)
aware_datetime_object.time() already returns a naive time object. The thorny
question is what .timetz() should return -
Tim Golden added the comment:
I haven't looked at the patch, but +1 to anything which brings
Tcl/Tk/Tix support into a state of default usability. Thanks for picking
this up, Zachary.
--
___
Python tracker
<http://bugs.python.org/is
Tim Gordon added the comment:
__add__ is non-commutative for lists, tuples, strings etc. - perhaps
non-commutative wasn't quite what you were looking for :p.
--
nosy: +QuantumTim
status: pending -> open
___
Python tracker
<http://bugs
Tim Peters added the comment:
+inf == +inf, and -inf == -inf, are required by the 754 standard.
However, +inf - +inf, and -inf - -inf, are required (by the same
standard) to signal invalid operation and, if that signal is masked (as
it is in Python), to return a NaN. Then NaN == x is false
Tim Peters added the comment:
I wasn't keen to add the 2-argument log() extension either. However, I
bet it would help if the docs for that were changed to explain that
log(x, base) is just a convenient shorthand for computing
log(x)/log(base), and therefore may be a little less accurate
Tim Hatch added the comment:
More discussion has gone on in issue #4573 on this topic. Can this bug
be marked as a duplicate?
--
nosy: +thatch
___
Python tracker
<http://bugs.python.org/issue2
Tim Peters added the comment:
Yup, it's a good idea. In fact, storing info in the debug malloc blocks
to identify the API family used was part of "the plan", but got dropped
when time ran out.
serialno should not be abused for this purpose, though. On a 32-bit
box, a 24-bit r
Tim Peters added the comment:
Right, I /was/ hallucinating about serialno -- good catch.
Mysterious little integers still suck, though ;-) If you're going to
store it in a byte, then you can #define semi-meaningful letter codes
instead; e.g.,
#define _PYMALLOC_OBJECT_ID '
Tim Golden added the comment:
Don't know what exact release OS X ships with, but it
looks like you're being bitten by this:
http://bugs.python.org/issue5261
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.
Tim Peters added the comment:
I understand you're annoyed, but the bug tracker is not the place to
rehash arguments that were settled a decade ago. If you need to pursue
this, please take it to the newsgroup comp.lang.python. Before you do,
you might want to scour the newsgroup's ar
Tim Flechtner added the comment:
Hi. I think I'm running into the problem discussed in this ticket. I'm
trying to build pycairo-1.8.8 on Solaris 10 (x86) against python-2.6.2
using gcc-4.4.1. I'm afraid I'm out of my depth in understanding really
what's going on,
Changes by Tim Lesher :
--
nosy: +tlesher
___
Python tracker
<http://bugs.python.org/issue3329>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
FYI, mysterious numeric differences on PPC are often due to the C
compiler generated code to use the "fused multiply-add" HW instruction.
In which case, find a way to turn that off :-)
--
nosy: +tim_one
Tim Peters added the comment:
Adding
-mno-fused-madd
would be worth trying. It usually fixes PPC bugs ;-)
--
___
Python tracker
<http://bugs.python.org/issue3
Tim Peters added the comment:
Mark, you needn't bother: you found the smoking gun already! From your
description, I agree it would be very surprising if FMA made a
significant difference in the absence of catastrophic cancellation.
--
___
P
Tim Hatch added the comment:
I'm running the exact same version as Gabriel (on Windows 7, 32 bit)
from the python.org installer, and have the same behavior as Michał.
Checking FixTk.py it appears that on Vista and above, it calls the Win32
API GetFinalPathNameByHandleW to expand symbolic
Tim Peters added the comment:
This behavior is intentional and is documented in the
datetime.isoformat() docs:
"""
Return a string representing the date and time in ISO 8601 format,
-MM-DDTHH:MM:SS.mm or, if microsecond is 0, -MM-DDTHH:MM:SS
...
"""
Changes by Tim Golden :
--
nosy: +tim.golden
___
Python tracker
<http://bugs.python.org/issue7344>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
Ezio, it was Guido's design decision, it was intentional, and it's been
documented from the start(*). So you can disagree with it, but you
won't get anywhere claiming it's "a bug": intentional, documented
behaviors are never "
Tim Peters added the comment:
Terry, the language reference also says:
"""
For the purpose of shift and mask operations, a binary representation is
assumed, and negative numbers are represented in a variant of 2's
complement which gives the illusion of an infinite string of
Tim Peters added the comment:
Note that round() is implemented much more carefully in Python 3.x than in
Python 2.x, and 120 is actually the correct result under nearest/even rounding
(125 is exactly halfway between representable values when rounded to the
closest 10, and nearest/even
Tim Mooney added the comment:
This still happens in 2.6.3 and 2.6.4 so I spent some time looking at it.
It's happening because of a combination of issues, but ultimately it's because
python's build isn't making certain that it's including its private copy of
exp
Tim Peters added the comment:
Showing once again that a proof of FP code correctness is about as compelling
as a proof of God's ontological status ;-)
Still, have to express surprised admiration for
4487665465554760717039532578546e-47! That one's not even close
Tim Peters added the comment:
You can use the comparison, provided you understand what it does, and that it
does NOT do what you hoped it would do. Here:
>>> 1.6 - 1.0
0.60009
That shows quite clearly that subtracting 1 from the binary approximation to
1.6 does
Tim Peters added the comment:
Mark, I agree that last one should be a release blocker -- it's truly dreadful.
BTW, did you guess in advance just how many bugs there could be in this kind of
code? I did ;-)
--
___
Python tracker
Tim Golden added the comment:
>From me, yes of course, but I assume you want another
core dev for a 2nd opinion.
___
Python tracker
<http://bugs.python.org/iss
Tim Golden added the comment:
Hirokazu Yamamoto wrote:
> Hirokazu Yamamoto added the comment:
>
> I reconsidered this issue. When mmap is anonymous,
> self->file_handle == INVALID_HANDLE_VALUE (-1), so we should not call
> SetFilePointer and SetEndOfFile for this handle
Tim Peters added the comment:
The GNU library's float<->string routines are based on David Gay's.
Therefore you can compare those to Gay's originals to see how much
effort was required to make them "mostly" portable, and can look at the
history of those to ge
Tim Gordon added the comment:
Try escaping the '%prog' in your usage string (i.e. use '%%prog'
instead) so you don't get the error when you substitute values in.
--
nosy: +QuantumTim
___
Python tracker
<http
Tim Peters added the comment:
Mark, "extreme complexity" is relative to what's possible if you don't
care about speed; e.g., if you use only bigint operations very
straightforwardly, correct rounding amounts to a dozen lines of
obviously
Tim Peters added the comment:
Is it worth it? To whom ;-) ? It was discussed several times before on
various Python mailing lists, and nobody was willing to sign up for the
considerable effort required (both to update Gay's code and to fight
with shifting platform quirks ever after).
If
Tim Peters added the comment:
Huh. I didn't see Preston volunteer to do anything here ;-)
One bit of software engineering for whoever does sign on: nothing kills
porting a language to a new platform faster than needing to get an
obscure but core subsystem working. So whatever is done
Tim Golden added the comment:
Effectively a duplicate of http://bugs.python.org/issue2421
(which has been sitting around unapplied for a few months)
I certainly don't mind which one goes in, but I think
one should be closed in favour of the other. (And that
one should be ap
Changes by Tim Lesher :
--
nosy: +tlesher
nosy_count: 2.0 -> 3.0
___
Python tracker
<http://bugs.python.org/issue4510>
___
___
Python-bugs-list mailing list
Un
New submission from Tim Golden :
tools\msi\merge.py attempts to import config and fails with an
ImportError if it doesn't exist (which it doesn't by default). msi.py
catches this exception and ignores it.
The attached patch carries the same behaviour over to merge.py
--
New submission from Tim Golden :
The msi.py determines which files to carry over into the installer for
the lib\test directory. zipdir.zip was added recently for test_zipfile
and this isn't picked up. The attached patch adds it in.
--
components: Installation
files: msi-zipdir.
New submission from Tim Golden :
lib\distutils\tests\test_util.py, run as part of the full testsuite,
creates a stub os.uname on an OS which doesn't support it natively.
However, it fails to restore it correctly -- ie fails to delete the
attribute. As a result, test_platform and test_p
Tim Golden added the comment:
Adding Tarek to nosy list as he added the code earlier this month
--
nosy: +tarek
title: distutils.test_util fails to restore os.uname -> distutils.test_util
fails to restore os.uname; causes test_platform to f
New submission from Tim Michelsen :
There is no documentation for the function
in
http://docs.python.org/search.html?q=getproxies&check_keywords=yes&area=default
But the docstring shows:
ul.getproxies?
Type: function
Base Class:
String Form:
Namespace: Int
1801 - 1900 of 2346 matches
Mail list logo
