Barry A. Warsaw added the comment:
If you need a test case, try https://gitlab.com/warsaw/flufl.lock
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24168
___
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +paul.moore
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24385
___
___
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: docs@python - barry
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24351
___
Nathaniel Smith added the comment:
For whatever it's worth as a non-core-developer, the patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24294
___
Changes by Zachary Ware zachary.w...@gmail.com:
--
assignee: - steve.dower
resolution: - fixed
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24376
Zachary Ware added the comment:
Am I missing something here?
Python 3.6.0a0 (default:c2c3b79ba992, Jun 4 2015, 10:24:23)
from configparser import ConfigParser
cp = ConfigParser()
cp.read_string(\
... [remember]
... eth2.6 = True
... eth5 = True
... )
cp['remember']['eth2.6']
'True'
Changes by Zachary Ware zachary.w...@gmail.com:
--
nosy: +zach.ware
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24352
___
___
Python-bugs-list
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
nosy: +tim.peters
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24384
___
___
Larry Hastings added the comment:
Go ahead for beta 3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8232
___
___
Python-bugs-list mailing list
Matthew Barnett added the comment:
Here's how I can build the regex module on Windows 8.1, 64-bit, using only
MinGW64.
For Python 3.5, I can link against python35.dll, but for earlier versions,
including Python 2.7, I need libpython??.a.
I have built regex module for all of the 16 supported
Changes by Zachary Ware zachary.w...@gmail.com:
--
assignee: - steve.dower
components: +Build, Installation, Windows -Library (Lib)
nosy: +steve.dower, tim.golden, zach.ware
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24385
New submission from Graham Oliver:
I noticed that when I created an issue in this Bug Tracjer all of the
associated emails were ending up in my gmail spam. '...in violation of Google's
recommended email sender guidelines.' An explanatory link sends me to
R. David Murray added the comment:
There are already open issues about this in the meta tracker. (See the 'report
tracker problem' link at the bottom of the left column.)
--
resolution: - duplicate
stage: - resolved
status: open - closed
___
New submission from Jan Harkes:
mingw32 fails to link with libpython27.a fails with the following error
/cygdrive/C/Python27/libs/libpython27.a: error adding symbols: File format not
recognized
extracting all the objects from libpython27.a and checking them with objdump
shows that two
Ryan Gonzalez added the comment:
#1 and #2 are fixed. I hand-edited the patch file (!!), so here's to hoping
it'll work...
Working on #3. You probably should try the tests now (which is obviously the
scary part ;).
--
Added file: http://bugs.python.org/file39628/kbox_fix.patch
Brandon Milam added the comment:
Here's a patch addressing all of the comments in the review. Changing the
browsers from a set to a list though resulted in duplicates in the _tryorder
list that were not present before because the set had filtered the duplicates
before the partial string
Brandon Milam added the comment:
They are correct. 'cum' is not one of the available keywords and so here is the
fix changing it to say 'cumulative' for consistency as ramiro suggested.
--
keywords: +patch
nosy: +jbmilam
Added file:
Changes by Yury Selivanov yseliva...@gmail.com:
--
versions: -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Changes by Barry A. Warsaw ba...@python.org:
--
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24168
___
___
Python-bugs-list mailing
Ryan Gonzalez added the comment:
Fixes for readline and _crypt done.
--
Added file: http://bugs.python.org/file39629/lib_fixes.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23496
___
Changes by Benjamin Gilbert bgilb...@backtick.net:
--
nosy: +bgilbert
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24385
___
___
Python-bugs-list
Steve Dower added the comment:
Given I can't generate the file any other way that will be compatible for
everyone, unless someone contributes a fix I'm going to stop shipping these
files and let people generate them using whatever tools they have.
If anyone wants to suggest instructions then
Changes by Yury Selivanov yseliva...@gmail.com:
Added file: http://bugs.python.org/file39622/concurrent.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Mark Lawrence added the comment:
Now compiles, thanks guys :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24376
___
___
Python-bugs-list
Yury Selivanov added the comment:
Yuri, is that possible?
Please see my previous comment and the attached patch :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Changes by Yury Selivanov yseliva...@gmail.com:
--
assignee: yselivanov
components: Library (Lib), asyncio
nosy: gvanrossum, haypo, scoder, yselivanov
priority: normal
severity: normal
status: open
title: consider implementing __await__ on concurrent.futures.Future
type: enhancement
New submission from Yury Selivanov:
Maybe it's possible to give an interpretation to awaiting on a threaded
Future? __await__ could return a new asyncio Future, and add a completion
callback to the original Future that makes the asyncio Future ready and
transfers the result/exception. This
Yury Selivanov added the comment:
Added a unittest for cancellation
--
Added file: http://bugs.python.org/file39621/concurrent.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Ned Deily added the comment:
Yes, try make distclean. I am unable to reproduce the problem and don't see
why your proposed patch would make a difference.
--
resolution: - works for me
stage: - resolved
status: pending - closed
___
Python tracker
Yury Selivanov added the comment:
Guido, Stefen, please see issue24383.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
___
___
Guido van Rossum added the comment:
So in issue24017 I wrote:
Maybe it's possible to give an interpretation to awaiting on a threaded
Future? __await__ could return a new asyncio Future, and add a completion
callback to the original Future that makes the asyncio Future ready and
transfers the
Changes by Guido van Rossum gu...@python.org:
--
Removed message: http://bugs.python.org/msg244833
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Zachary Ware added the comment:
See discussion on #24244, I think this is an issue with your checkout rather
than the code.
--
nosy: +zach.ware
status: open - pending
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24382
Changes by Yury Selivanov yseliva...@gmail.com:
--
Removed message: http://bugs.python.org/msg244834
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
R. David Murray added the comment:
If you override __getattribute__ it is your responsibility to fulfill its
contract, so your method is the one that needs to catch the KeyError and return
the expected AttributeError.
--
nosy: +r.david.murray
resolution: - not a bug
stage: -
Vajrasky Kok added the comment:
Here is the error message:
building 'time' extension
gcc -Wno-unused-result -Wsign-compare -g -O0 -Wall -Wstrict-prototypes
-Werror=declaration-after-statement -I./Include -I. -IInclude
-I/usr/local/include -I/Users/sky/Code/python/cpython/Include
Changes by Yury Selivanov yseliva...@gmail.com:
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24374
Roundup Robot added the comment:
New changeset 3f2bf0ff262c by Yury Selivanov in branch '3.5':
Issue 24374: Plug refleak in set_coroutine_wrapper
https://hg.python.org/cpython/rev/3f2bf0ff262c
New changeset 68f40b6448b9 by Yury Selivanov in branch 'default':
Issue 24374: Plug refleak in
New submission from Vajrasky Kok:
On my OSX Yosemite 10 with GCC 4.2.1 Compatible Apple LLVM 6.1.0
(clang-602.0.53), I fail to build time module.
Failed to build these modules:
time
Here is the patch to fix the compile error.
--
components: Macintosh
files:
Raymond Hettinger added the comment:
FWIW, I like this idea.
--
nosy: +rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24379
___
___
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24379
___
Martin Panter added the comment:
Hi Michiel, if you are looking for the source of
https://docs.python.org/dev/c-api/veryhigh.html#c.PyOS_InputHook, that
corresponds to Doc/c-api/veryhigh.rst in the repository.
This bug would be fairly easy to solve for “tkinter” if we could drop the
Serhiy Storchaka added the comment:
Why not index the slice type itself? slice[1:2]
Another feature of the new `literal` object is that it is not limited to just
the creation of `slice` instances; instead, it is designed to mix slices and
other types together.
This looks as disadvantage.
Yury Selivanov added the comment:
Alternative patch with monkeypatching instead of Future subclassing.
--
Added file: http://bugs.python.org/file39623/concurrent_alt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
Guido van Rossum added the comment:
Sorry, I don't like that either. See my review.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
___
Changes by Yury Selivanov yseliva...@gmail.com:
Added file: http://bugs.python.org/file39624/concurrent.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
Nick Coghlan added the comment:
Would it also be worth making at docs update to tp_dealloc, suggesting the use
of tp_traverse/finalize?:
https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_dealloc
And perhaps from PyType_FromSpec?
Nick Coghlan added the comment:
Ah, I'd missed that the previous code wouldn't clean up properly in the failure
case.
+1 for inlining the check and using the existing error label.
--
___
Python tracker rep...@bugs.python.org
Petr Viktorin added the comment:
tp_traverse is completely orthogonal to tp_dealloc, it's needed to detect (and
then break) reference cycles like:
obj = xxlimited.Xxo()
obj.foo = obj
As for tp_finalize: yes, mentioning it in tp_dealloc docs would be good, but
I'll need a bit more
Roundup Robot added the comment:
New changeset 265eeb60443a by Nick Coghlan in branch '3.5':
Issue #24373: Eliminate PEP 489 test refleaks
https://hg.python.org/cpython/rev/265eeb60443a
New changeset f24cd8bc5250 by Nick Coghlan in branch 'default':
Merge fix for issue #24373 from 3.5
Roundup Robot added the comment:
New changeset 265eeb60443a by Nick Coghlan in branch '3.5':
Issue #24373: Eliminate PEP 489 test refleaks
https://hg.python.org/cpython/rev/265eeb60443a
--
nosy: +python-dev
___
Python tracker rep...@bugs.python.org
Martin Panter added the comment:
I guess this would involve:
* Making a new API called Py_Finalize2() or something that returns the status
* Redefine the existing Py_Finalize() to call Py_Finalize2() and ignore the
return value
--
___
Python
floyd added the comment:
Now that I gave it another thought, I think it would be better if we simply add
threshold as a named parameter of quick_ratio
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24384
Guido van Rossum added the comment:
Thinking about this more I think we should pass on this for now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24383
___
New submission from floyd:
I guess a lot of users of difflib call the SequenceMatcher in the following way
(where a and b often have different lengths):
if difflib.SequenceMatcher.quick_ratio(None, a, b) = threshold:
However, for this use case the current quick_ratio is quite a performance
Antoine Pitrou added the comment:
We would probably call it Py_FinalizeEx(), but yes.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5319
___
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: - fixed
stage: - resolved
status: open - closed
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24373
___
Yury Selivanov added the comment:
Hmm, but IMHO a) the new syntax isn't just for asyncio and b) awaiting a
Future seems like a *very* reasonable thing to do. I think opening a new
ticket for this is a good idea.
Stefan, I honestly have bo idea what concurrent.Future.__await__ would do.
Mark Dickinson added the comment:
For prior art, it's worth taking a look at NumPy, and in particular its `s_`
and `index_exp` functions:
import numpy as np
np.s_[1:2]
slice(1, 2, None)
np.s_[0]
0
np.s_[1:2, 3]
(slice(1, 2, None), 3)
--
nosy: +mark.dickinson
Joe Jevnik added the comment:
Why not index the slice type itself? slice[1:2]
I originally considered this and I personally really like this syntax, but I
was concerned with ambiguity with the typing module
The only question in my mind is what slice should do when given just a single
60 matches
Mail list logo
