STINNER Victor added the comment:
With PEP 475 now implemented (see Issue 23648), perhaps this could be closed?
Or is there something else to be done?
Yes, this issue was fully fixed by the implementation of the PEP 475 in Python
3.5.
--
resolution: - fixed
status: open - closed
Amaury Forgeot d'Arc added the comment:
The Python program itself has no UI and cannot be marked as DPI aware.
Instead, applications should call the win32 function SetProcessDPIAwareness:
https://msdn.microsoft.com/en-us/library/windows/desktop/dn302122
--
nosy: +amaury.forgeotdarc
Antoine Pitrou added the comment:
It's not a problem, since str *is* unicode in Python 3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13566
___
Ivan Bykov added the comment:
Python 3.5.0b2 (v3.5.0b2:7a088af5615b, May 31 2015, 06:22:19) [MSC v.1900 64
bit (AMD64)] on win32
Type copyright, credits or license() for more information.
import ctypes
ctypes.windll.user32.GetSystemMetrics(1)
1067
#must be 1600
#Python 3.5 also affected
Serhiy Storchaka added the comment:
Such libraries already have a problem. Both str and unicode pickled in Python 2
are unpickled as str in Python 3.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13566
Ivan Bykov added the comment:
SetProcessDpiAwareness not available for Windows 7. For Windows 7 available
SetProcessDPIAware, but:
Note SetProcessDPIAware is subject to a possible *race* *condition* if a DLL
caches dpi settings during initialization. For this reason, it is recommended
that
Serhiy Storchaka added the comment:
Started topic on Python-Dev:
http://comments.gmane.org/gmane.comp.python.devel/153655 .
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19176
___
Serhiy Storchaka added the comment:
Alexandre, Antoine, what are your thoughts?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13566
___
___
Serhiy Storchaka added the comment:
Does such API even exist?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13566
___
___
Python-bugs-list
Antoine Pitrou added the comment:
I wouldn't be very surprised if third-party libraries enforce such typing, yes.
If your library has a clear text/bytes separation, it makes sense to enforce it
at the API level, to avoid mistakes by users.
--
___
Andrew Svetlov added the comment:
Raymond, is there known custom third-party queue class derived from
queue.Queue? I believe all those are in stdlib only.
Also locking guarantee is promised by comment in source code only,
documentation says nothing about it.
I believe proposed change will
Antoine Pitrou added the comment:
Won't that fail if a Python 2 API accepts only unicode strings?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13566
___
Serhiy Storchaka added the comment:
Yes, there are.
https://code.openhub.net/search?s=%22def%20_qsize%22%20%22import%20Queue%22pp=0ff=1mp=1ml=1me=1md=1filterChecked=true
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
Raymond Hettinger added the comment:
One other thought: Returning NotImplemented may be an easy change but it isn't
clear that it would provide a sensible capability for mapping views. The
non-iterable *other* argument would need to have a __ror__() method than could
do something useful
Changes by Piotr Dobrogost p...@bugs.python.dobrogost.net:
--
nosy: +piotr.dobrogost
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9427
___
___
Antoine Pitrou added the comment:
He accepted it already:
A small last-minute optimization is not a release-blocker.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18003
___
Roundup Robot added the comment:
New changeset bb51d486a899 by Tal Einat in branch '3.4':
#23891: correctly refer to PyPI as Python Package Index
https://hg.python.org/cpython/rev/bb51d486a899
--
___
Python tracker rep...@bugs.python.org
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
resolution: - not a bug
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24411
___
Changes by Tim Pierce twpie...@gmail.com:
--
nosy: +Tim Pierce
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22983
___
___
Python-bugs-list
Skip Montanaro added the comment:
Small nit... The venv.patch file refers to Python Packaging Index. It's the
Python Package Index.
--
nosy: +skip.montanaro
Added file: http://bugs.python.org/file39663/ppi.diff
___
Python tracker
doz added the comment:
The problem is only present with gcc optimization -Os . Not present with -O0
,O1, O2, O3.
Do you have an idea of the gcc pass responsible to that ?
(I have also a similar problem with openssl)
regards
--
resolution: - third party
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24417
___
___
Python-bugs-list
Serhiy Storchaka added the comment:
Larry, do you accept the patch for 3.5?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18003
___
___
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +berker.peksag
stage: - needs patch
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24416
___
Tal Einat added the comment:
(This should probably be discussed on the Python Ideas mailing list...)
I definitely like the idea of being able to construct slices etc. using []
syntax. I think this should be considered even if it is decided not to change
the repr() of slices.
An important
Stefan Behnel added the comment:
See issue 24400 regarding a split of yield-based generators and async-def
coroutines at a type level.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24017
Changes by Yury Selivanov yseliva...@gmail.com:
--
hgrepos: +312
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24400
___
___
Python-bugs-list
Changes by Barry A. Warsaw ba...@python.org:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24351
___
Yury Selivanov added the comment:
Cleaned up the patch a little bit.
--
Added file: http://bugs.python.org/file39665/corotype.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24400
___
New submission from Antoine Pitrou:
This is what happens when building Python with conda-build (which implies doing
make install with a custom prefix):
[...]
if test xupgrade != xno ; then \
case upgrade in \
upgrade) ensurepip=--upgrade ;; \
Changes by Andrew Svetlov andrew.svet...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24400
___
___
Roundup Robot added the comment:
New changeset 20bf84cd38bc by Barry Warsaw in branch '3.4':
- Issue #24351: Clarify what is meant by identifier in the context of
https://hg.python.org/cpython/rev/20bf84cd38bc
New changeset 0fa48f581fe3 by Barry Warsaw in branch '3.5':
- Issue #24351: Clarify
Changes by Aaron Meurer asmeu...@gmail.com:
--
nosy: +Aaron.Meurer
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24418
___
___
Python-bugs-list
Yury Selivanov added the comment:
One more patch fixing minor bug in types.coroutine + a unittest for that. The
patch should be ready for reviews.
--
Added file: http://bugs.python.org/file39666/corotype.patch
___
Python tracker
Donald Stufft added the comment:
We should probably pass ``-s`` to the ensurepip call.
Adding 2.7 here as well because I think this will probably affect more than
just the Makefile, probably the Windows installers and OSX installers too.
--
versions: +Python 2.7
Antoine Pitrou added the comment:
Do we need to add Steve and Ned for the installers?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24418
___
Stefan Behnel added the comment:
I added some review comments. The main thing is that the coroutine type should
be awaitable.
For reference, here's my current implementation for Cython. It's a bit more
involved as it needs to support Python 2.6+. I may also add some special casing
for
Tal Einat added the comment:
First, if pickle a namedtuple, it can't be unpickled in previous versions.
True, but I don't think Python goes as far as to promise that objects pickled
in one version can be unpickled in previous versions.
Second, namedtuple is slower and larger than tuple, so
Carl Kleffner added the comment:
The most robust way to support a specific mingw-w64 distribution is to copy a
python import library generated by this specific toolchain and the provided
import library for the corresponding msvcrXX.dll runtime into the libs folder.
This has to be performed by
Tal Einat added the comment:
(see https://mail.python.org/mailman/listinfo/python-ideas)
But for x = [1,2,3,4], how will x[y] work for all of the following values of y?
y = slice.literal[0]
y = slice.literal[1:2]
y = slice.literal[0:1, ..., 3]
NumPy's s_ magic object is a factory, returning
Tal Einat added the comment:
Is there any way that this could break existing code?
--
nosy: +taleinat
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24416
___
Serhiy Storchaka added the comment:
No, it is not fully backwards-compatible. First, if pickle a namedtuple, it
can't be unpickled in previous versions. Second, namedtuple is slower and
larger than tuple, so it shouldn't be used in memory or performance critical
code.
--
nosy:
Baptiste Mispelon added the comment:
I didn't know about issues with pickling. As for the performance issue, is
date.isocalendar() really performance critical?
I found a precedent for replacing a tuple by a namedtuple:
https://hg.python.org/cpython/rev/ef72142eb8a2
I'm trying my hand at
Serhiy Storchaka added the comment:
The patch is not so harmless. First, my change in BZ2File is not correct,
because reading every line should be guarded with a lock (BZ2File is
threading-safe). Second, for now all three compressing files are not only
iterables, but iterators. iter(f)
Baptiste Mispelon added the comment:
As far as I know, using a namedtuple in place of a tuple is fully
backwards-compatible.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24416
___
Tal Einat added the comment:
You can take a look at lru_cache_cache_info in Modules/_functoolsmodule.c for
an example of namedtuple instantiation in C code. But that code gets the
namedtuple class as a parameter.
This is not my area of expertise, but you could try using PyObject_CallFunction
Baptiste Mispelon added the comment:
Here's a second attempt at a patch which seems to work.
I don't know C at all but I used _decimal.c to try and figure out how to use
namedtuple in C.
The code compiles and the datetime test suite runs.
I've added a test for the new feature and a note in
Changes by Ned Deily n...@acm.org:
--
nosy: +ned.deily
stage: - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24418
___
___
Nick Coghlan added the comment:
A quick scan of which files have been modified suggests the new opcode
still needs docs (although I think the PEP 492 docs in general are still
pending, in which case, this could just be rolled into that)
I'll review the full patch later today (too big to review
New submission from py.user:
Action append_const works for options:
import argparse
parser = argparse.ArgumentParser()
_ = parser.add_argument('--foo', dest='x', action='append_const', const=42)
_ = parser.add_argument('--bar', dest='x', action='append_const', const=43)
Yury Selivanov added the comment:
Nick Coghlan added the comment:
A quick scan of which files have been modified suggests the new opcode
still needs docs (although I think the PEP 492 docs in general are still
pending, in which case, this could just be rolled into that)
Sure. If the patch
Yury Selivanov added the comment:
(although I think the PEP 492 docs in general are still pending, in which
case, this could just be rolled into that)
Actually most of pep 492 docs are merged already (including new opcodes) via
issue24180. They can be definitely improved though (I'll try to
Baptiste Mispelon added the comment:
For the name, I took (un)inspiration from ParseResult:
https://docs.python.org/3/library/urllib.parse.html?highlight=urlparse#urllib.parse.ParseResult
Any better suggestion is welcome of course.
--
___
Python
Baptiste Mispelon added the comment:
Some C code cleanups suggested by haypo.
--
Added file: http://bugs.python.org/file39668/issue24416_3.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24416
Larry Hastings added the comment:
Sounds good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18003
___
___
Python-bugs-list mailing list
Yury Selivanov added the comment:
Please find attached a new patch.
Stefan, while working on the patch, I (re-)discovered that __await__ for
coroutines should return an iterator that also implements '.send', '.throw',
and '.close', to comply with PEP 380 yield from implementation:
Yury Selivanov added the comment:
Nick, Guido, I think we should commit this. While working on this I'm getting
more and more confident that it's the right thing to do. I like that
coroutines implement __await__ in the latest patch -- PEP 492 just now clicks
with PEP 380.
--
Tal Einat added the comment:
Now for the color of the bike-shed: What should the namedtuple returned by
date.isocalendar() be named? Perhaps CalendarDate or DateTuple?
Baptiste's patches use ISOCalendarResult. In my opinion that is a poor name
since it does not tell you anything about what it
Changes by R. David Murray rdmur...@bitdance.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24415
___
___
Python-bugs-list
New submission from Baptiste Mispelon:
Currently, `date.isocalendar()` returns a plain tuple of (year, week, weekday).
It would be a bit more useful if this tuple could be made into a namedtuple
(with fields year, week and weekday).
--
components: Library (Lib)
messages: 245061
nosy:
New submission from ABalmosan:
We use the Python lib as part of a larger process. This process sets its own
signal handlers to achieve the expected behavior of the process.
We use Py_InitializeEx(0) to prevent Python to install its own signal handlers.
On process reconfigure we shutdown
Ben Darnell added the comment:
4. While this patch addresses initial request from Ben only partially
(generator-based coroutines still require __instancecheck__),
A partial solution doesn't mean much to me: as long as the __instancecheck__ is
sometimes necessary, I'll have to use
Martin Panter added the comment:
Updated the patch to address an oversight in the new test cases.
I think Issue 6294 is probably the same underlying issue. The patch there could
be used as the basis for a Python 2 patch. My patches here are for Python 3,
and I suspect the code is
Yury Selivanov added the comment:
All this checking for coroutine-ness feels very strange to me. It's
anti-duck-typing: [..]
Why is it anti-duck-typing? Awaitable is an object that implements
__await__. With this patch coroutines are a separate type with __await__
(although, ceval
Tal Einat added the comment:
See also the recent addition of a section on venv to the Tutorial section of
the docs (Doc/tutorial/venv.rst, issue23891). The wording there and in the
module docs should at least be consistent with each other.
--
nosy: +taleinat
New submission from Skip Montanaro:
I am only now just prying my fingers off printf-style string
formatting. The new syntax always seemed Perl-like to me, so I ignored
it. Finally, yesterday, I got some cheat sheet pointers from
comp.lang.python and dove in.
I hit a minor roadblock when I
Martin Panter added the comment:
This patch adds an entry to the What’s New for 3.5 (though maybe it will have
to be 3.6), and adds three tests to check that next() raises ValueError when
the files have been closed.
--
Added file: http://bugs.python.org/file39662/decomp-optim.v4.patch
Benjamin Gilbert added the comment:
Is there any reason an import library generated by a particular MinGW version
shouldn't be usable by any other MinGW version?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24385
Yury Selivanov added the comment:
On June 9, 2015 at 11:11:11 PM, Ben Darnell (rep...@bugs.python.org) wrote:
[..]
The type of the callable matters for the types.coroutine decorator. In
order to get a coroutine object instead of a generator object, I must apply
types.coroutine to the actual
Changes by koobs koobs.free...@gmail.com:
--
nosy: +koobs
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22359
___
___
Python-bugs-list mailing
koobs added the comment:
We've (FreeBSD) seen and received several random and intermittent reports of
failures during this stage of the build for all versions of Python, resulting
in errors such as, among others:
Parser/pgen.o: file not recognized: File truncated
*** [Parser/pgen] Error code
New submission from Martin Panter:
After the documentation was rearranged by Issue 23342 (revision f0a00ee094ff),
the “older high-level APIs” lost the paragraphs that said “The arguments shown
above are merely the most common ones”. Given the limited signatures of call(),
check_call() and
Martin Panter added the comment:
FWIW two times recently I saw strange intermittent build errors. I use “make
-j2” on Linux. The one time that I investigated was a Python module (math or
cmath perhaps?) failing to build because some dependency was zero bytes, and
looking through the build
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: +berker.peksag
stage: - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24420
___
Ben Darnell added the comment:
GeneratorWrapper helps, but it fails when applied to non-generator functions
that return a value (while both tornado.gen.coroutine and asyncio.coroutine
take pains to support such usage). The raise TypeError should be removed;
just return the result without
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24413
___
___
Martin Panter added the comment:
The BufferedReader class is documented as being thread safe:
https://docs.python.org/dev/library/io.html#multi-threading. Some
experimentation suggests that checking the “raw.closed” property is not
actually serialized, but that raw.readinto() calls are
Ben Darnell added the comment:
On Tue, Jun 9, 2015 at 10:12 PM, Yury Selivanov rep...@bugs.python.org
wrote:
Yury Selivanov added the comment:
All this checking for coroutine-ness feels very strange to me. It's
anti-duck-typing: [..]
Why is it anti-duck-typing? Awaitable is an object
Yury Selivanov added the comment:
GeneratorWrapper helps, but it fails when applied to non-generator functions
that return a value (while both tornado.gen.coroutine and asyncio.coroutine
take pains to support such usage). The raise TypeError should be removed;
just return the result
79 matches
Mail list logo
