Tim Graham added the comment:
Cookie pickling issue should be fixed in #22775.
--
nosy: +Tim.Graham
___
Python tracker
<http://bugs.python.org/issue826
Tim Graham added the comment:
Georg, how do want to proceed with this issue? Should we backport #16611
(support for parsing secure/httponly flag) to 3.2 to fix this regression and
then create a separate issue to fix the lax parsing issue on all versions
Tim Graham added the comment:
The patch from #16611 applies cleanly to 3.2. I added a mention in Misc/NEWS
and confirmed that all tests pass.
--
Added file: http://bugs.python.org/file37127/secure-httponly-3.2-backport.diff
___
Python tracker
<h
New submission from Tim Graham:
As noted in the comments of #22758 by Georg Brandle:
* Django uses __init__(str()) roundtripping, which is not explicitly supported
by the library, and worked by accident with previous versions. That it works
again with 3.3+ is another accident, and a bug
Tim Graham added the comment:
I also created #22796 for the lax parsing issue.
--
___
Python tracker
<http://bugs.python.org/issue22758>
___
___
Python-bugs-list m
Tim Graham added the comment:
Django's test suite passes with the proposed patch after some updates:
https://github.com/django/django/pull/3455
--
___
Python tracker
<http://bugs.python.org/is
Changes by Tim Graham :
--
nosy: +Tim.Graham
___
Python tracker
<http://bugs.python.org/issue7559>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Graham added the comment:
Security-wise? I don't know, I haven't really been in the loop on the original
issue.
--
___
Python tracker
<http://bugs.python.o
Tim Graham added the comment:
Django's test suite doesn't reveal any regressions. All the changes there are
expected as far as I can see.
--
___
Python tracker
<http://bugs.python.o
Tim Smith added the comment:
Ping! Any chance for feedback here? This behavior took me by surprise again
today. :)
--
___
Python tracker
<http://bugs.python.org/issue22
New submission from Tim Hatch:
There's a reproducible bug in textio.c that causes a double DECREF on codecs.
The conditions to trigger are probably rare in real life, so not remotely
exploitable (sandbox escape is the worst I can think of on its own, and I'm not
aware of any on 3.
Tim Golden added the comment:
Agree with RDM: we're just passing the path through to the Windows API (on
Windows). We don't generally carry out this kind of pre-emptive check.
--
resolution: -> not a bug
stage: -> resolved
status
Tim Golden added the comment:
Likewise.
--
___
Python tracker
<http://bugs.python.org/issue22733>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Golden added the comment:
I agree that this is a fragile assertion; it's too far removed from the
CreateFileMapping call which can generate it and almost impossible to
work around (in calling code) if it should fail in the way we're seeing
in the buildbot.
I think we're bet
Changes by Tim Golden :
--
components: +Windows
nosy: +steve.dower, tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue23120>
___
___
Python-bug
Tim Peters added the comment:
This is easy: Cowlishaw is wrong on this one, but nothing can be done about it
;-)
Confusion arises because most people think of 0**0 as a value (where it
certainly must be 1) while others seem to view it as some kind of shorthand for
expressing a limit (as the
Changes by Tim Golden :
--
assignee: -> tim.golden
___
Python tracker
<http://bugs.python.org/issue22028>
___
___
Python-bugs-list mailing list
Unsubscrib
Tim Golden added the comment:
This has just come up again over on python-list:
https://mail.python.org/pipermail/python-list/2015-January/696660.html
I'm the nearest thing we have to a mimetypes maintainer at least for Windows so
I'll try to pick Steve&
Tim Golden added the comment:
Steve, could you outline the need / impact for this, please? (ie can you inform
my ignorance?).
--
___
Python tracker
<http://bugs.python.org/issue23
Tim Golden added the comment:
+1 from me, then.
--
title: Add version info to python[w].exe -> Add version info to python
___
Python tracker
<http://bugs.python.org/issu
Tim Golden added the comment:
I'm +0.75. I think the idea's fine in principle and the patch (by
inspection) seems to do the right things.
My only concerns are: that posixmodule.c becomes even longer and more
involved; and that the benefit might not quite be great enough to
justify
Tim Smith added the comment:
Homebrew's interest in this ticket was resolved by the release of pip 6, which
includes Vinay's change to distlib to use sys.executable instead of
__PYVENV_LAUNCHER__. Many thanks!
I'm not marking this fixed in case it is useful to leave this
Tim Golden added the comment:
It's right there on my to-do list which is, unfortunately, not getting
any shorter.
TJG
On 01/02/2015 19:10, Steve Dower wrote:
>
> Steve Dower added the comment:
>
> Definitely a dup, though I don't have the number handy. There's a
Tim Golden added the comment:
I think we should simply take out the example, ie the part in brackets. The
statement remains true but I don't think we need to cast around for whichever
OS / filesystem happens to implement this particular setup.
--
nosy: +tim.g
Tim Golden added the comment:
Fine by me
--
___
Python tracker
<http://bugs.python.org/issue20709>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Golden added the comment:
Under the covers, subprocess is calling CreateProcess so there's really not
very much we can do here, short of writing our own PATH-handling.
As a matter of fact, passing shell=True will produce the desired effect. Since
the only thing this does is to ru
Changes by Tim Golden :
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue17023>
___
Tim Smith added the comment:
On Darwin, it would be nice if LINKFORMODULE used "-undefined dynamic_lookup"
instead of explicitly linking to a framework binary. Modules with explicit
links to a framework cause segfaults when they are imported from a different,
but compatible,
Changes by Tim Golden :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23463>
___
___
Tim Golden added the comment:
Colons are valid in filenames to introduce Alternate Data Stream:
https://msdn.microsoft.com/en-us/library/cc422524.aspx
--
___
Python tracker
<http://bugs.python.org/issue23
Changes by Tim Golden :
--
components: +Windows
nosy: +tim.golden, zach.ware
___
Python tracker
<http://bugs.python.org/issue23465>
___
___
Python-bugs-list mailin
Tim Golden added the comment:
And, just to be clear to Serhiy who I know doesn't use Windows,
os.access really is a worthless function in its present form: worse,
even, because it can be misleading. I have a long-standing patch to
convert it to use AccessCheck but I've never quite ha
Changes by Tim Graham :
Added file: http://bugs.python.org/file39512/secure-httponly-3.2-backport.diff
___
Python tracker
<http://bugs.python.org/issue22758>
___
___
Pytho
Tim Graham added the comment:
Patch rebased again after cookie fix from #22931.
--
___
Python tracker
<http://bugs.python.org/issue22758>
___
___
Python-bug
Tim Graham added the comment:
Unfortunately, the revert wasn't merged to the 2.7 branch until after the
release of 2.7.10. I guess this regression wouldn't be considered serious
enough to warrant a 2.7.11 soon, correct?
--
___
Python trac
Changes by Tim Pierce :
--
nosy: +Tim Pierce
___
Python tracker
<http://bugs.python.org/issue22931>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Graham added the comment:
This changed caused a problem in Django's test suite (bisected to
0d0989359bbb0).
File "/home/tim/code/django/django/db/models/options.py", line 709, in
_populate_directed_relation_graph
all_models = self.apps.get_models(include_auto_created=
Tim Graham added the comment:
Thanks, that does resolve the issue.
--
___
Python tracker
<http://bugs.python.org/issue14373>
___
___
Python-bugs-list mailin
Changes by Tim Pierce :
--
nosy: +Tim Pierce
___
Python tracker
<http://bugs.python.org/issue22983>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Smith added the comment:
In Homebrew we occasionally use .pth files to call site.addsitedir. This is
useful when we want to add a directory to sys.path that contains .pth files
that also need to be processed (for example, when adding a directory to
sys.path that contains namespace
Tim Peters added the comment:
> random() may return 1.0 exactly
That shouldn't be possible. Although the code does assume C doubles have at
least 53 bits of mantissa precision (in which case it does arithmetic that's
exact in at least 53 bits - cannot round up to 1.0; but _could
Tim Peters added the comment:
FYI, where x = 1.0 - 2.**-53, I believe it's easy to show this under IEEE
double precision arithmetic:
For every finite, normal, double y > 0.0,
IEEE_multiply(x, y) < y
under the default (nearest/even) rounding mode. That implies
int(x*
Tim Golden added the comment:
I'm not sure why you expect this to work: the Python C API relies on the
presence of a Python installation to work. It's not, in itself, a means of
bundling Python. I assume you must have at least had the python .dll present or
the program wouldn'
Tim Peters added the comment:
Steven, there's something wrong with the arithmetic on your machine, but I
can't guess what from here (perhaps you have a non-standard rounding mode
enabled, perhaps your CPU is broken, ...).
In binary, (2**53-1)/2**53
Tim Peters added the comment:
Thanks for the legwork, Steven!
So far it looks like a gcc bug when using -m32 (whether ints, longs and/or
pointers are 4 or 8 bytes _should_ make no difference to anything in Jason
Swails's C example).
But it may be a red herring anyway: there'
Tim Peters added the comment:
I'm guessing this is a "double rounding" problem due to gcc not restricting an
Intel FPU to using 53 bits of precison:
> In binary, (2**53-1)/2**53 * 2049 is:
>
> 0.1
> times
> 1
Tim Peters added the comment:
Should also note that double rounding cannot account for the _original_ symptom
here. Double rounding surprises on Intel chips require an exact product at
least 65 bits wide, but the OP's sequence is far too short to create such a
product. (Steven's
Tim Golden added the comment:
Zach, is there a write-up in the devguide for how to do this? And/or
could you send me the same email, please?
--
___
Python tracker
<http://bugs.python.org/issue24
Tim Peters added the comment:
Mark, note that the sequence in the OP's original report only contains 35
elements. That, alas, makes "double rounding" irrelevant to this bug report.
That is, while random.choice() can suffer double-rounding surprises in _some_
cases, it can
Tim Peters added the comment:
Raymond, there are (at least) two bugs here:
1. The original bug report. Nobody yet has any plausible theory for what went
wrong there. So "won't fix" wouldn't be appropriate. If the OP can't provide
more information, neither a rep
Tim Peters added the comment:
Thanks, Mark! That's convincing. Just as a sanity check, I tried all ints in
1 through 4 billion (inclusive) against 1. - 2.**-52, with no failures.
Although that was with ad hoc Python code simulating various rounding methods
using scaled integers, s
Tim Peters added the comment:
I suppose the simplest "fix" would be to replace relevant instances of
int(random() * N)
with
min(int(random() * N), N-1)
That would be robust against many kinds of arithmetic quirks, and ensure that
platforms with and without such quirks would, if
Tim Peters added the comment:
Mark, closest I could find to a substantive SSE-vs-fsum report is here, but it
was closed (because the fsum tests were changed to ignore the problem ;-) ):
http://bugs.python.org/issue5593
--
___
Python tracker
<h
Tim Peters added the comment:
> It skews the distribution a tiny little bit, ...
But it doesn't - that's the point ;-)
If double-rounding doesn't occur at all (which appears to be the case on most
platforms), absolutely nothing changes (because min(int(random() * N), N-1) ==
Tim Peters added the comment:
Victor, if people want to use getrandbits(), we should backport the Python3
code, not reinvent it from scratch.
Note too Mark's comment: "There are several places in the source where
something of the form `int(i * random.random())` is used". Th
Tim Peters added the comment:
Victor, don't ask me, look at the code: the random.choice() implementations in
Python 2 and Python 3 have approximately nothing in common, and "the bug" here
should already be impossible in Python 3 (but I can't check that, because I
don&#x
Tim Peters added the comment:
> Anyway, if we modify random.py, the generated
> numbers should be different, no?
Not in a bugfix release. The `min()` trick changes no results whatsoever on a
box that doesn't do double-rounding.
On a box that does do double-rounding, the only di
Changes by Tim Graham :
--
nosy: -Tim.Graham
___
Python tracker
<http://bugs.python.org/issue14373>
___
___
Python-bugs-list mailing list
Unsubscribe:
Tim Peters added the comment:
[Raymond]
> I can't say that I feel good about making everyone pay
> a price for a problem that almost no one ever has.
As far as I know, nobody has ever had the problem. But if we know a bug
exists, I think it's at best highly dubious to wait fo
Tim Peters added the comment:
I have a question about this new snippet in choice():
+if i == n and n > 0:
+i = n - 1
What's the purpose of the "and n > 0" clause? Without it, if i == n == 0 then
i will be set to -1, which is just as good as 0 for t
Tim Peters added the comment:
Hmm. Looks like the answer to my question came before, via "Custom collection
can has non-standard behavior with negative indices." Really? We're worried
about a custom collection that assigns some crazy-ass meaning to a negative
index appl
Tim Peters added the comment:
[Serhiy Storchaka]
> ... I want to say that double rounding causes not
> only bias from ideal distribution, but a difference
> between platforms
That's so, but not too surprising. On those platforms users will see
differences between "primitive
Tim Smith added the comment:
Hi; I'm a Homebrew maintainer. Please open an issue at
https://github.com/Homebrew/homebrew.
--
nosy: +tdsmith
___
Python tracker
<http://bugs.python.org/is
Tim Golden added the comment:
Can you confirm whether it also fails if you pass in a unicode string? eg
shutil.rmtree(u"filename.txt")
--
___
Python tracker
<http://bugs.python.o
Tim Peters added the comment:
> The only reason for the restriction that
> I can think of is that some text representation
> of datetime only provide 4 digits for timezone.
There never was a compelling reason. It was simply intended to help catch
programming errors for a (at the ti
Tim Peters added the comment:
It is really bad that roundtripping current microsecond datetimes doesn't work.
About half of all microsecond-resolution datetimes fail to roundtrip correctly
now. While the limited precision of a C double guarantees roundtripping of
microsecond datetimes
Tim Peters added the comment:
> I wish we could use the same algorithm in
> datetime.utcfromtimestamp as we use in float
> to string conversion. This may allow the
> following chain of conversions to round trip in most cases:
>
> float literal -> float -> datetime ->
Tim Peters added the comment:
> Does your algorithm guarantee that any float that
> is displayed with 6 decimal places or less will
> convert to a datetime or timedelta with microseconds
> matching the fractional part?
No algorithm can, for datetimes far enough in the future (C
Tim Peters added the comment:
> >>> x = float.fromhex('0x1.38f312b1b36bdp-1')
> >>> x
> 0.6112295
> >>> round(x, 6)
> 0.611229
> >>> timedelta(0, x).microseconds
> 611230
>
> but I no longer remember whether we concluded th
Tim Peters added the comment:
> IMHO we should only modify the rounding method used by
> datetime.datetime.fromtimestamp() and
> datetime.datetime.utcfromtimestamp(), other functions
> use the "right" rounding method.
Fine by me. How about today? ;-)
The regression
New submission from Tim Tisdall:
Currently https://docs.python.org/3.6/library/socket.html#socket-families only
says "Certain other address families (AF_BLUETOOTH, AF_PACKET, AF_CAN) support
specific representations." and there's a comment in the docs saying "document
Tim Tisdall added the comment:
I'm not sure the proper way to update the patch... I can't seem to edit the
existing one or replace it. I'm uploading an updated one, but should I simply
"unlink" (aka delete) the old one?
--
Added file: http://
Tim Tisdall added the comment:
Martin, the odd thing with the SCO protocol is it's expecting an bluetooth
address as a byte string (ex b'12:23:34:45:56:67' [note the `b`]) where the
other 3 are expecting a regular string (ex '12:23:34:45:56:67'). I think it
may ha
Tim Tisdall added the comment:
I'm not really sure how to add a `versionadded` tag to specify that only the
BSD-specific support was added in 3.2 (as general support was there prior to
that). If I just add the plain tag below that bullet point it would imply that
the whole protocol was
Tim Tisdall added the comment:
I added a note to BTPROTO_SCO that it doesn't work in FreeBSD (I forgot to
mention that).
--
Added file: http://bugs.python.org/file40341/bluetooth_socket_docs_3.patch
___
Python tracker
<http://bugs.py
Tim Tisdall added the comment:
changed "This protocol does not work under FreeBSD." to the more accurate "This
protocol is not supported under FreeBSD."
--
Added file: http://bugs.python.org/file40343/bluetooth_socket_docs_4.patch
__
Tim Peters added the comment:
Larry, I appreciate the vote of confidence, but I'm ill-equipped to help at the
patch level: I'm solely on Windows, and (long story) don't even have a C
compiler at the moment. The patch(es) are too broad and delicate to be sure of
without ki
Tim Peters added the comment:
That's great, Victor! Another person trying the code with their own critical
eyes would still be prudent. Two days ago you wrote:
> This part of Python (handling timestamps, especially
> the rounding mode) is complex, I prefer to check for
> all
Tim Peters added the comment:
FYI, that invariant failed for me just now under the released 3.4.3 too:
Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for mo
Tim Peters added the comment:
Alex, if you like, I'll take the blame for the rounding method - I did express
a preference for it here:
http://bugs.python.org/issue23517#msg249309
When I looked at the code earlier, the round-half-up implementation looked good
to me (floor(x+0.5) if x
Tim Peters added the comment:
Yes, it would be good to hear from Mark. When I first saw this report, I
checked to see whether he was on the nosy list. He is, but is apparently busy
elsewhere.
My opinions haven't changed: nearest/even is unnatural for rounding times
("so
Tim Peters added the comment:
Victor, there are good "theoretical" reasons for using half/even rounding in
_general_ use. But this bug report isn't the place to get into them. Here it
just should be enough to note that the IEEE 754 floating point standard
_requires_ half
Tim Peters added the comment:
Goodness. It's the properties of "randomly chosen decimals" that have nothing
to do with timestamps ;-) timestamps aren't random, so "statistical bias" is
roughly meaningless in this context. I gave a specific example before
Tim Peters added the comment:
Bah. It doesn't matter who's consuming the rounding of a binary float to
decimal microseconds: there are only 32 possible fractional parts where
nearest/even and half-up deliver different results. half-up preserves
properties of these specific i
Tim Peters added the comment:
> Half-up leaves them all 5 microseconds apart,
When only looking at the decimal digit in the 6th place after rounding.
Which is all I did look at ;-)
--
___
Python tracker
<http://bugs.python.org/issu
Tim Peters added the comment:
Victor, sorry if I muddied the waters here: Alex & I do agree nearest/even
must be used. It's documented for timedelta already, and the
seconds-from-the-epoch invariant Alex showed is at least as important to
preserve as round-tripping.
Alex, agreed
Tim Peters added the comment:
The longobject.c warnings are almost certainly unrelated to the test_re crash.
If shifting right twice (adding parens for clarity):
(LONG_MAX >> PyLong_SHIFT) >> PyLong_SHIFT.
squashes the warnings, that would be a substantially clearer way to
Tim Peters added the comment:
Universal consensus on ROUND_HALF_EVEN, yes.
I would like to see it repaired for 3.5.0, but that's just me saying so without
offering to do a single damned thing to make it happen ;-)
--
___
Python tracker
Tim Tisdall added the comment:
Martin, looks good. Thanks for pointing out how to properly tag the version
change, and thanks for adding me to the ACKS file.
--
___
Python tracker
<http://bugs.python.org/issue24
Tim Peters added the comment:
Guido, you're clearly talking with someone who knows too much ;-) If we're
using the Twister for _anything_ related to crypto-level randomness, then I'd
appalled - it was utterly unsuitable for any such purpose from day 1. But as a
general-purpos
New submission from Tim Tisdall:
As mentioned in #24984, I'm making another issue to document the address format
for AF_PACKET. In this case there's already documentation in
Modules/socketmodule.c that says:
- an AF_PACKET socket address is a tuple containing a string
spec
Tim Tisdall added the comment:
Right now the docs say "Certain other address families (:const:`AF_PACKET`,
:const:`AF_CAN`) support specific representations.".
I was going to create a separate issue for AF_CAN, but it seems that it's
already documented... When documentati
Tim Tisdall added the comment:
I created #25041 to handle AF_PACKET. It seems AF_CAN is already in the docs,
so the person making the change for AF_PACKET can just remove that mention of
AF_CAN farther down.
--
___
Python tracker
<h
New submission from Tim Tisdall:
further to #24984, I noticed there are constants that aren't mentioned in the
docs. Also BDADDR_ALL is missing (which is defined in Bluez's bluetooth.h) so
I added it.
Now, I'm not totally clear on supplying multi-version patches... I know 3.5
New submission from Tim Tisdall:
All of the BTPROTO_ protocols accept tuples with Bluetooth addresses as regular
strings. SCO accepts a byte-string which represents a Bluetooth address. The
change was made at 23ab586c427a
With the current implementation we get this error:
>>&g
Changes by Tim Tisdall :
--
components: +Extension Modules
___
Python tracker
<http://bugs.python.org/issue25044>
___
___
Python-bugs-list mailing list
Unsub
Tim Tisdall added the comment:
I'm not sure how to unit test a constant... it's just a string. If you're
asking for a unit test for when you'd actually make use of the constant, I
haven't been able to figure out that situation yet. It seems like in Bluez
4.101 it&
Changes by Tim Tisdall :
--
keywords: +patch
Added file: http://bugs.python.org/file40424/bdaddr_36_1.patch
___
Python tracker
<http://bugs.python.org/issue25
Changes by Tim Tisdall :
Added file: http://bugs.python.org/file40425/bdaddr_34_1.patch
___
Python tracker
<http://bugs.python.org/issue25043>
___
___
Python-bugs-list m
Changes by Tim Tisdall :
Added file: http://bugs.python.org/file40426/bdaddr_35_1.patch
___
Python tracker
<http://bugs.python.org/issue25043>
___
___
Python-bugs-list m
2101 - 2200 of 2346 matches
Mail list logo
