Tim Bell added the comment:
My proposed solution (in https://github.com/python/cpython/pull/2229) is
two-part:
1. change parsedate_to_datetime() to return None rather than raising an
exception; and
2. change headerregistry.DateHeader.parse() to check for None being returned
from
Tim Peters added the comment:
Whatever the iteration, accept that it's necessary it reach every value in
range(2**i) eventually. The current scheme does that, for reasons already
documented. You seem to be overlooking the importance of this part:
"""
Note that because
Tim Peters added the comment:
Yes, any scheme whatsoever that guarantees to visit every int in range(2**i)
meets the "correctness" part.
But I concur with Inada: "head arguments" aren't compelling here, not even if
I understood what they were saying ;-) If you imp
Changes by Tim Bell :
--
pull_requests: +2304
___
Python tracker
<http://bugs.python.org/issue30681>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Bell added the comment:
Thanks for the feedback. I've made a new pull request which addresses the
points raised.
--
___
Python tracker
<http://bugs.python.org/is
Tim Bell added the comment:
I've updated the pull request to incorporate Barry's suggestion of a new defect
for this situation, InvalidDateDefect.
--
___
Python tracker
<http://bugs.python.o
Tim Peters added the comment:
The attached hashsim.py pretty much convinces me there's nothing left to be
gained here. It shows that the current scheme essentially achieves the
performance of theoretical "uniform hashing" for string keys, for both
successful and unsuccessf
Tim Peters added the comment:
I don't see a reason to keep this open, but I haven't been able to follow the
OP's line of argument. My best _guess_ is that they're chasing illusions based
on not understanding (or grossly undervaluing) that the primary point of the
Tim Golden added the comment:
I can't reproduce either on 2.7 or on 3.5 with any of the examples shown.
Closing again as not-a-bug.
--
resolution: -> not a bug
status: open -> closed
versions: -Python 2.7, Python 3.4
___
Python tra
Tim Golden added the comment:
[Housekeeping] Closing this as fixed. The mimetypes fix is in; the 3.4
installer is well out of support. If any other issues arise on current
installers they should be raised as new issues.
--
resolution: -> fixed
stage: -> resolved
status
Tim Peters added the comment:
Dmitry, I suggest you spend more of the time you give to thinking to writing
code instead ;-) But, really, that's the easiest & surest way to discover for
yourself where your analysis is going off in the weeds.
For example, issue 28201 was both simpler
New submission from Tim Bell:
According to RFC 5322, an email address like this isn't valid:
u...@example.com
(The display-name "u...@example.com" contains "@", which isn't in the set of
atext characters used to form an atom.)
How it's handled by
Tim Peters added the comment:
BTW, I should have spelled this out earlier: recall that x and y collide on
the first probe if and only if
x = y (mod 2**k) [1]
The second probe never happens unless they do collide on the first probe, so
when looking at the second probe we can assume
Tim Bell added the comment:
I'm using the email package to ingest a firehose of spam; spammers aren't known
for following norms or standards, so it's not surprising that I'm discovering
lots of edge cases.
I'll supply fixes for what I find whe
Changes by Tim Golden :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue30
Tim Peters added the comment:
Actually, there is something to be gained here, for smaller tables. The simple
formulas for the expected number of probes under uniform hashing are upper
bounds, and are significantly overstated when the load factor is very high (not
a concern for Python) or the
Tim Peters added the comment:
I suggest reading the thread I started here[1] before pursuing this: it looks
very likely that the entire collision resolution scheme should be replaced with
one of the "double hashing" ones given there, a bona fide algorithmic
improvement for small
Tim Peters added the comment:
Oops! I undercounted the shifts in the current scheme: there's an additional
shift for "perturb". That doesn't exist in the "double hashing" alternatives.
--
___
Python tracker
<
Tim Peters added the comment:
I agree closing was appropriate at this time. I quite like PCG, but as Raymond
said it's more a template for creating PRNGs than a specific generator. So
even if a compelling case could be made, there's still a long way to having
specific code in min
Tim Graham added the comment:
Hi, I observed an error while trying to install numpy after
6969eaf4682beb01bc95eeb14f5ce6c01312e297.
gcc: numpy/random/mtrand/mtrand.c
numpy/random/mtrand/mtrand.c: In function ‘__Pyx_PyCFunction_FastCall’:
numpy/random/mtrand/mtrand.c:44374:5: error: too
Tim Graham added the comment:
Thanks, I'm not sure what that means exactly but I added the note to
https://github.com/numpy/numpy/issues/9391. Perhaps a note in the Python
release notes is warranted?
--
___
Python tracker
<http://bugs.py
Tim Peters added the comment:
Just noting that every special code path "at the start" doesn't just speed the
case it's aiming at, it also _slows_ every case that doesn't pass the new
tests. It takes time to fail the new tests. So it usually makes things slower
over
Tim Peters added the comment:
This is an unfortunate consequence of the default "autojunk" feature. You can
turn that off by passing `autojunk=False`, like so:
match = SequenceMatcher(None, string1, string2, auto
Tim Peters added the comment:
Measuring in isolation (like with, e.g., timeit) isn't really interesting.
Then everything is in L1 cache, branches are 100% predictable (because they
take the same branch over & over for the duration of the test), and
second-order effects on _other_
Tim Peters added the comment:
Ya, prior to now ;-) there's generally been some cost-benefit thought given to
these things. Strings and ints are immutable and some values of each are
uniquely interned, so the case of identity is more than just plausible. It
happens often.
I'd gues
Tim Peters added the comment:
Not a bug. For an explanation, I just answered a very similar question on
StackOverflow:
https://stackoverflow.com/questions/45180899/unexpected-result-from-in-operator/45180967#45180899
--
nosy: +tim.peters
Tim Golden added the comment:
For shell objects such as shortcuts you could use os.startfile which invokes
ShellExecute under the covers
--
___
Python tracker
<http://bugs.python.org/issue30
Tim Peters added the comment:
Victor, this part of the docs explains what you're seeing; scroll down to the
"""
In enforcing reflexivity of elements, the comparison of collections assumes
that for a collection element x, x == x is always true ...
"""
part.
New submission from Tim Bell:
Email addresses with a display name starting with a dot ("."), or ending with a
dot without whitespace before the angle bracket trigger exceptions when
accessing the header, after creating the message object with the "default"
policy.
For
Changes by Tim Bell :
--
pull_requests: +2862
___
Python tracker
<http://bugs.python.org/issue30988>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
This isn't a bug. 84 appears twice in the list, the first time at index 9.
The .index() method finds the first (leftmost; smallest index) occurrence.
Since 9 isn't even, the `if` test isn't satisfied, so 84 does not appear in the
result.
Tim Peters added the comment:
Yes, I'm closing as not-a-bug. It's been this way (and documented) forever.
More specifically, as the docs say, a raw string can't end with an _odd_ number
of backslashes:
"""
String quotes can be escaped with a backslash, bu
Tim Peters added the comment:
@Rajath, I suspect Raymond may have been bamboozled because your suggested
`heapfix()` and `heapremove()` didn't appear to take any arguments. If the
index is a required argument, then these are O(log N) operations.
I thought about adding them years ago
Tim Peters added the comment:
[Guido]
> Why was task management ever added?
Raymond published a "joinable" queue class as a recipe here:
http://code.activestate.com/recipes/475160-taskqueue/
and later folded it into the standard Python queue. So the usual answer
applies: &q
New submission from Tim Smith:
$ python -V
Python 3.6.2
This crash appears to be specific to having files with some ill-encoded
filenames. After renaming the offending files to remove the non-ASCII
characters, the process could complete without crashing.
$ beet import /share/Music/Berliner
Tim Smith added the comment:
I forgot to mention, this is Arch Linux python package:
Version : 3.6.2-1
Packager: Felix Yan
Build Date : Wed 19 Jul 2017 01:54:34 PM MDT
I had the files on a vfat filesystem, but copied them to ext4 with the exact
same results
Tim Peters added the comment:
Is there a problem here? I haven't heard of anyone even wondering about this
before. threading.py worries about Threads created _by_ threading.py, plus the
magical (from its point of view) thread that first imports threading.py. Users
mix in `_thread` th
Tim Peters added the comment:
Ya, it's clearly best for `current_thread()` to deliver consistent results.
--
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
To include trailing whitespace on a line in a doctest, _don't_ use raw strings.
Use a regular string, and include add a (one or more) trailing \x20 instead of
a space (for example). For example:
r"""
>>> print("a ")
a
&
Change by Tim Bell :
--
keywords: +patch
pull_requests: +10025
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue30681>
___
___
Python-
Tim Bell added the comment:
I've addressed the points in the last few comments and created a new PR (10783).
--
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
Yup, it can do some redundant comparisons; more on that here:
https://mail.python.org/pipermail/python-dev/2018-August/155020.html
I'm not inclined to make this already-difficult code even harder to understand
for something that's quite likely not
Tim Peters added the comment:
My two cents:
- Spell it comb(n, k).
- TypeError if args aren't ints.
- ValueError if not 0 <= k <= n.
Not concerned about speed. It's possible to do this with no divisions
involving integers bigger than `n` and `k`(*), using O(k) space, but
Tim Peters added the comment:
Just for fun, here's a gonzo implementation (without arg-checking) using ideas
from the sketch. All factors of 2 are shifted out first, and all divisions are
done before any multiplies.
For large arguments, this can run much faster than a dumb loop.
Tim Peters added the comment:
`input()` returns a string, not a list. For input '1010' you're effectively
computing this:
>>> int('1' * 8) + int('1' * 2) # = + 11
1122
which is the correct answer. If you want your input to be a lis
Tim Peters added the comment:
Please read my answer again. Your code does not do what you _think_ it does.
It does what I said it does instead.
>>> a = input()
1010
>>> print(a)
1010
>>> print(type(a))
The input you're working with is NOT A LIST OF INTEGER
Tim Peters added the comment:
Antoine, alas, it's subtler than that. The worker process (process_func())
puts _another_ `StopIteration` on the input queue in its `finally` clause. So
the first worker process to finish adds back a sentinel for the next worker to
see, and so on. At th
Tim Peters added the comment:
I don't know that the language needs to define this, but sticking to __lt__ was
a wholly deliberate design decision for CPython.
--
nosy: +tim.peters
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
Steven, thanks for noticing the docs! I was surprised to hear it wasn't
documented, but not surprised enough to check myself ;-)
This decision was suggested by me, and endorsed by Guido, when designing
timsort looking ahead to Python 3, where __cmp__ was
Tim Peters added the comment:
Please resist pointless feature creep. The original report was about comb(n,
k) for integer n and k with 0 <= k <= n and that's all. Everyone who commented
appeared to agree they'd find that useful.
But nobody has said they'd find gene
Tim Peters added the comment:
For history, note that `bisect` doesn't always work in this context either: a
heap is NOT always in sorted order. For example, this is "a (min) heap" too:
[1, 3, 2].
More, that's "the real" problem. If we could find the element
Tim Peters added the comment:
I'd like to divorce `prod()` from floating-point complications. The `sum()`
builtin has proved extremely handy, even for floats, in large part because it's
type-agnostic and straightforward. While I'd usually use `prod()` on ints and
Fractions
Tim Peters added the comment:
Precisely _how_ are you building it? As noted above, if you're using Visual
Studio, try using build.bat instead for the first time.
--
___
Python tracker
<https://bugs.python.org/is
Tim Peters added the comment:
> As far as I can tell from the discussions here, Steven
> and you stated a preference for the shortened names, and
> that's it.
Plus Mark, plus me - all backed "comb()" specifically.
> I find it hard to imagine anyone needing combinat
Tim Peters added the comment:
As Mark said, the behavior of Python's floating-point math functions (not just
trig, but also log, pow, exp, ...) is inherited almost entirely from the
platform C's math libraries. Python itself guarantees nothing about what
`math.sin(x)` returns
Change by Tim Burgess :
--
pull_requests: +11713, 11714
___
Python tracker
<https://bugs.python.org/issue28411>
___
___
Python-bugs-list mailing list
Unsub
Change by Tim Burgess :
--
pull_requests: +11713
___
Python tracker
<https://bugs.python.org/issue28411>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
Yes, it's quadratic time. If the string being searched has N characters, first
it fails to find "x" in all N of 'em, then `.*` advances by one and it fails to
find "x" in the trailing N-1 characters, then again in the trailing N
Tim Peters added the comment:
Without re.IGNORECASE, the leading
^[_a-z0-9-]+
can't even match the first character (`val` starts with uppercase Z), so it
fails instantly.
With re.IGNORECASE, it's not "stuck", but is taking a verry long time to
try an enormous n
Tim Peters added the comment:
difflib generally synchs on the longest contiguous matching subsequence that
doesn't contain a "junk" element. By default, `ndiff()`'s optional `charjunk`
argument considers blanks and tabs to be junk characters.
In the strings:
"
Tim Peters added the comment:
It's probably OK, but there's no "pure win" to be had here. There's generally
more than one way to convert one string to another, and what "looks right" to
humans depends a whole lot on context.
For example, consi
Tim Peters added the comment:
> It's impressive *and* scary that such 13 years old
> bug only show up today...
Then again, there's probably no other code in the world that compares slice
objects ;-)
--
nosy: +tim.peters -josh.r
__
Tim Peters added the comment:
Josh, I'd say the speed of this code doesn't matter one whit to anything. Like
you, I'd _prefer_ that the issue be fixed by building "real tuples" that own
their own references, which would also (as you showed) allow for briefer,
si
Tim Peters added the comment:
> Oh, Tim Peters succeded somehow to
> remove Josh Rosenberg from the nosy list: I add him again ;-)
Certainly wasn't my intent! That happens too often on the tracker. Thanks for
noticing! :-(
--
___
Pyt
Change by Tim Burgess :
--
nosy: +tjb900
___
Python tracker
<https://bugs.python.org/issue29466>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
"Multiple roundings" in the float code is a red herring - that's just
implementation details trying to cheaply get the same effect as computing with
infinite precision. Here with actual unbounded precision:
>>> from fractions import F
Tim Peters added the comment:
Thanks, Steven! I'll go on to suggest that the best intro to these issues for
Python programmers is in Python's own tutorial:
https://docs.python.org/3/tutorial/floatingpoint.html
Raymond, `divmod(a, b)[0]` IS the mathematical `floor(a/b)`, where
Tim Peters added the comment:
- Some form of this would be most welcome!
- If it's spelled this way, put the modulus argument last? "Everyone expects"
the modulus to come last, whether in code:
x = (a+b) % m
x = a*b % m
x = pow(a, b, m)
or in math:
a^(k
Tim Peters added the comment:
Raymond, I doubt we can do better (faster) than straightforward egcd without
heroic effort anyway. We can't even know whether a modular inverse exists
without checking whether the gcd is 1, and egcd builds on what we have to do
for the latter anyway. Ev
Tim Peters added the comment:
Your last line can't possibly return True, because `somelist.reverse()` returns
None.
So the last line is irrelevant. Your complaint appears to be about the line
before, which shows that the list retains its original order.
That's expected. All th
Tim Peters added the comment:
I haven't tried the example, but at this point I'd be surprised if it failed.
The caching here isn't at level of `__lt__` but at the higher level of
(invisible from Python code) a type's tp_richcompare slot. A heap type -
regardless of wheth
Tim Peters added the comment:
@ppperry, I have no idea what the bulk of the code in typeobect.c is trying to
do.
--
___
Python tracker
<http://bugs.python.org/issue28
Tim Peters added the comment:
Elliot, I don't care if the example behaves differently. Although someone else
may ;-)
The only things `.sort()` has ever tried to guarantee in the presence of
mutations (of either the list or the elements) during sorting are that (a) the
implementation
Tim Peters added the comment:
Elliot, did you run the example in a release build or a debug build? I'm
wondering why this:
assert(v->ob_type == w->ob_type &&
v->ob_type->tp_richcompare != NULL &&
v->ob_type->tp_richcompare == compa
Tim Peters added the comment:
The impact would be small: it would add one (or so) pointer-equality compare
that, in practice, will always say "yup, they're equal". Dirt cheap, and the
branch is 100% predictable.
--
___
Python
Tim Peters added the comment:
Elliot, PyObject_RichCompareBool calls PyObject_RichCompare. That in turn does
some checks, hides a small mountain of tests in the expansions of the
recursion-checking macros, and calls do_richcompare. That in turn does some
useless (in the cases you're a
Tim Peters added the comment:
I think this is expected. Add this as the first line of `simulate()` and the
problem should go away:
q.cancel_join_thread()
As the docs say, a Queue works with a background thread, which feeds incoming
data from an internal buffer to a (interprocess) pipe
Changes by Tim Peters :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29797>
___
___
Tim Peters added the comment:
@ppperry, I believe you're right - good catch! I expect the current patch
would treat the NotImplemented return as meaning "the first argument is less
than the second argument".
I added a comment to the code (on github) suggesting an obvio
Changes by Tim Graham :
--
pull_requests: +542
___
Python tracker
<http://bugs.python.org/issue16932>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Graham :
--
pull_requests: +544
___
Python tracker
<http://bugs.python.org/issue754016>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Tim Graham :
--
pull_requests: +543
___
Python tracker
<http://bugs.python.org/issue27657>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Graham added the comment:
Based on discussion in issue 16932, I agree that reverting the parsing
decisions from issue 754016 (as Martin suggested in msg271719) seems
appropriate. I created a pull request that does that.
--
nosy: +Tim.Graham
Tim Graham added the comment:
I sent a pull request for this issue's dependency (issue 27657) and added a
second commit there with this patch. A test added in the first commit
demonstrates that removing this code no longer results in the behavior change
described in msg2
Tim Peters added the comment:
See also:
https://en.wikipedia.org/wiki/Hamming_weight
As that says, there are a number of languages and processors with first class
support for a popcount function. I've frequently implemented it in Python when
using integers as integer bitsets (`i`
Tim Peters added the comment:
I think we should certainly support asserts regardless of whether Py_DEBUG is
in force (although Py_DEBUG should imply asserts run too).
And I wish you had stuck to just that much ;-) The argument against, e.g.,
'assert(!PyErr_Occurred())', seems e
Tim Peters added the comment:
So there's more than one issue here.
First, should asserts be supported in the absence of Py_DEBUG? It seems, so
far, everyone agrees they should be.
Second, ...? I'm really not following your argument. It _appears_ to be
something along the lines
Tim Peters added the comment:
I'll take a crack at these ancient comments ;-)
"""
daemon
The process’s daemon flag, a Boolean value. This must be set before start()
is called.
The initial value is inherited from the creating process. [1]
When a process e
Tim Peters added the comment:
@Eryk, not me ;-) I find the "daemonic or not?" distinction useless for
processes - it just gets in the way at times (e.g., a Pool worker dies with an
assert(!) error if it tries to create its own Pool for something).
I don't care about orphans ei
Tim Peters added the comment:
Again, I don't care about orphans. In the usual cases people are running code
with no concern about what happens in case of forced termination. The only
thing stopping it now is that the code goes out of its way to prevent it (or,
alternatively, goes out o
Tim Peters added the comment:
Yes, that example takes time exponential in the number of blanks to (fail to)
match - each time you add a blank to `input`, it essentially doubles the time
required.
It's _possible_ for an implementation to deduce that `(\s+)+` is an insanely
inefficient w
Tim Golden added the comment:
I think you're suppressing sys.stderr after the "with". Try a NameError
or anything.
Alternatively, try a "with" which isn't using sys.stderr
Obviously, the next question is why *that's* happe
Tim Peters added the comment:
I already commented on github - +1 for this change.
--
nosy: +tim.peters
___
Python tracker
<http://bugs.python.org/issue30
Tim Graham added the comment:
Does it seems likely that getfullargspec() will be deprecated after Python 2 is
EOL? Django is currently reimplementing getargspec():
https://github.com/django/django/blob/8ab7ce8558792f41637d6f87f2a8a117e169dd18/django/utils/inspect.py#L4-L24
A pull request
Tim Chase added the comment:
As requested by Ben Finney[1], adding my use-case here. I'm attempting to make
a hard-link from "a" to "b", but if "b" exists, os.link() will fail with an
EEXISTS. I don't want to do
os.unlink("b")
# power-o
Tim Chase added the comment:
I do have a workaround thanks to Gregory Ewing
https://mail.python.org/pipermail/python-list/2017-May/721649.html
which suffices for my particular use-case (generating a link to a file with a
unique filename).
As my use-case is predominantly for *nix environments
Tim Peters added the comment:
Generally speaking, trying to shuffle a dict D already blows up, unless D's
keys are the integers range(len(D)). In that case, D is indistinguishable from
a list in the sense that both map range(N) to values via __getitem__.
`shuffle()` does no type c
Tim Peters added the comment:
Users certainly have been fooled by this, although "unpacking" is a red
herring. I've been burned by it, and I've seen StackOverflow puzzles related
to the same thing. I think this is the heart of it: given a finite iterable
I, it usual
Tim Peters added the comment:
If we could roll back the clock, I'd impose a total ordering on floats in
Python and supply some other way to spell 754's comparison operators (which
users would have to ask for explicitly if they wanted to hassle with the
near-useless and too-often-
Tim Peters added the comment:
> *Clearly*, negative NaNs should be sorted to the start
> of the list, while positive NaNs are sorted to the end
> of the list. (Yes, I'm joking, but only a little bit: that's
> the result you'd get if you used IEEE 754's totalOr
901 - 1000 of 2346 matches
Mail list logo
