New submission from Michael Shuffett:
According to the documentation
https://docs.python.org/3/library/pathlib.html#pathlib.Path.resolve
If strict is False, the path is resolved as far as possible and any remainder
is appended without checking whether it exists.
The current behavior is not
Michael Foord added the comment:
I agree it's not *very* useful, but I don't see any benefit in getting rid of
it either.
--
___
Python tracker
<http://bugs.python.o
Michael Cuthbert added the comment:
Poking to see if there's still interest in getting this into 3.7. Thanks!
--
versions: +Python 3.7 -Python 3.6
___
Python tracker
<http://bugs.python.org/is
Michael Cuthbert added the comment:
just poking to see if this patch is worth trying to get into 3.7
--
versions: +Python 3.7 -Python 2.7, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue17
New submission from Michael Seifert:
In a question on StackOverflow
(https://stackoverflow.com/questions/44302946/itertools-does-not-recognize-numpy-ints-as-valid-inputs-on-python-3-6)
it was mentioned that numpys scalars cannot be used as index for
`itertools.islice`.
The reason for this
Change by Michael Sullivan :
--
nosy: +msullivan
___
Python tracker
<https://bugs.python.org/issue35975>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Felt added the comment:
I see I already asked howto better utilize this info:
ConnectionRefusedError: [Errno 79] Connection refused
Warning -- files was modified by test_multiprocessing_fork
Before: []
After: ['core']
-- so, more specific -- which module, or file, is
New submission from Michael Felt :
Only marking Python3.8, but this is a historical issue I have ignored as long
as possible.
There are many - ancient and recent issues open around the extension module
_curses - and over the years it appears many assumptions have come into the
code (such as
Change by Michael Felt :
--
keywords: +patch
pull_requests: +12197
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36210>
___
___
Py
Michael Felt added the comment:
Could this also be backported to 3.7 and 3.6 please?
--
versions: +Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35
Michael Felt added the comment:
Could this also be backported to 3.6 and 3.7 please?
--
versions: +Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34
Michael Felt added the comment:
could this be backported to versions 3.7, and if applicable, to version 3.6
--
___
Python tracker
<https://bugs.python.org/issue34
Michael Felt added the comment:
Could this also be backported to version 3.6?
--
versions: +Python 3.6
___
Python tracker
<https://bugs.python.org/issue35
Michael Felt added the comment:
Could this also be backported to Version 3.6?
--
versions: +Python 3.6
___
Python tracker
<https://bugs.python.org/issue34
Michael Felt added the comment:
Could this also be backported to Version 3.7 and 3.6?
--
versions: +Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34
Michael Felt added the comment:
Could this also be backported to Version 3.7 and 3.6 (I do not expect it to be
backported to 2.7, but I had mistakenly removed it 2.7 when I changed it to 3.8
- and should have added 3.6 and 3.7 then).
--
versions: +Python 2.7, Python 3.6, Python 3.7
Michael Felt added the comment:
Could this alos be backported to Version 3.7 and 3.6 - thx!
--
versions: +Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34
Michael Felt added the comment:
Could this be backported to version 3.7?
--
___
Python tracker
<https://bugs.python.org/issue34347>
___
___
Python-bugs-list m
Michael Felt added the comment:
On 11/03/2019 09:42, Stéphane Wirtel wrote:
> Stéphane Wirtel added the comment:
>
> Hi Michael,
>
> I think no, because 3.6 is in security mode.
Clear reason. Maybe makes the baclport to 3.7 more opportune. Thx for
the reply!
>
>
Michael Felt added the comment:
On 10/03/2019 19:43, Michael Felt wrote:
> Michael Felt added the comment:
>
> Could this alos be backported to Version 3.7 and 3.6 - thx!
As 3.6 is in security mode - I guess only 3.7 then.
> --
> versions: +Python
Michael Felt added the comment:
On 10/03/2019 19:40, Michael Felt wrote:
> Michael Felt added the comment:
>
> Could this also be backported to Version 3.7 and 3.6 (I do not expect it to
> be backported to 2.7, but I had mistakenly removed it 2.7 when I changed it
> to 3.8 -
Michael Felt added the comment:
On 10/03/2019 19:37, Michael Felt wrote:
> Michael Felt added the comment:
>
> Could this also be backported to Version 3.6?
Ignore this since 3.6 is in security mode.
>
> --
> versions: +Python 3.6
>
>
Michael Felt added the comment:
On 10/03/2019 19:31, Michael Felt wrote:
> Michael Felt added the comment:
>
> could this be backported to versions 3.7, and if applicable, to version 3.6
Only 3.7 - As 3.6 is in security mode.
>
> --
>
> ___
Michael Felt added the comment:
On 10/03/2019 19:34, Michael Felt wrote:
> Michael Felt added the comment:
>
> Could this also be backported to version 3.6?
>
> --
> versions: +Python 3.6
Not to worry: As 3.6 is in security mode.
>
>
Michael Felt added the comment:
On 10/03/2019 19:25, Michael Felt wrote:
> Michael Felt added the comment:
>
> Could this also be backported to 3.7 and 3.6 please?
Only 3.7 I guess - As 3.6 is in security mode.
>
> --
> versions: +Pyth
Change by Michael Felt :
--
versions: -Python 3.6
___
Python tracker
<https://bugs.python.org/issue35704>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Michael Felt :
--
versions: -Python 3.6
___
Python tracker
<https://bugs.python.org/issue34373>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Michael Felt :
--
versions: -Python 3.6
___
Python tracker
<https://bugs.python.org/issue11192>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Michael Felt :
--
versions: -Python 3.6
___
Python tracker
<https://bugs.python.org/issue34720>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Saah added the comment:
While I agree with Victor that reworking time.strftime to be more portable
is a great idea, this issue was never about that; it was about making
exception throwing behavior consistent across datetime's two strftime
implementations (python and C), and
Michael Foord added the comment:
It's almost certainly an oversight rather than a design decision. I'd be happy
with the change you suggest Karthikeyan.
--
___
Python tracker
<https://bugs.python.o
Michael Felt added the comment:
>From memory I do not believe this is still a problem, at least on Python3.
There was recently a different issue (do not recall the #) where there was an
issue with CXX regardless of compiler.
In any case, the apporach I would recommend would be to export
Michael Felt added the comment:
I have looked at this briefly.
I would consider it a regression, or a spurious incident as the bot run before
(https://buildbot.python.org/all/#/builders/10/builds/2223) and after
(https://buildbot.python.org/all/#/builders/10/builds/2225) do not show this
Michael Selik added the comment:
+1 for this use case. Until it's resolved, perhaps there should be a note in
the singledispatch docs that types from the ``typing`` module should not be
used?
--
nosy: +selik
___
Python tracker
&
Michael Foord added the comment:
An auto-magic cache clearing mechanism is really tempting. I tend to agree with
Raymond though, if code needs and progress a cache clearing mechanism it should
be treated and accessible.
They're are probably some problematic caches still within uni
Michael Foord added the comment:
> On 30 Mar 2019, at 23:48, Michael Foord wrote:
>
>
> Michael Foord added the comment:
>
> An auto-magic cache clearing mechanism is really tempting. I tend to agree
> with Raymond though, if code needs and progress a cache
Michael Foord added the comment:
Tests codify knowledge about the system under test, so it doesn't matter that
the test suite has to know how to clear caches. It's specifically a good thing
that the test writer knows which caches exist and need clearing, and how to do
it. The ha
Michael Foord added the comment:
Spec objects are currently dumb. It would be a new feature to add signature
validation to them.
I think it would be a useful feature though as currently autospec sort of
obsoletes spec objects whilst being more heavyweight and harder to use.
I think it
Michael Felt added the comment:
Updating this to not only correct the failure of 3rd-party library ncurses
(while IBM curses builds with no issue) to also stop announcing that the
optional modules osaudiodev and spwd have not been built.
Neither are supported on AIX - so they will never be
Change by Michael Felt :
--
versions: +Python 3.7
___
Python tracker
<https://bugs.python.org/issue36210>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Michael Felt :
--
title: correct AIX logic in setup.py for non-existant optional extensions ->
correct AIX logic in setup.py for (non-existant) optional extensions
___
Python tracker
<https://bugs.python.org/issu
New submission from Michael Felt :
sys.platform returns "aix[3|4|4|5|6|7"
AIX 3 and AIX 4 are no longer around, in any supported form, so references to
these specific releases is pointless.
This will remove the (two) places where they are still referenced.
--
compone
Change by Michael Felt :
--
keywords: +patch
pull_requests: +12587
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36503>
___
___
Py
New submission from Michael Felt :
This is something that probably shouts - boring - but back in 2012 it was a hot
topic for linux2 and linux3.
Maybe - as far back as 1996 (when AIX4 was new) "aix3" and "aix4" made sense.
Whether that is true, or not - is pointless thes
Michael Felt added the comment:
On 10/04/2019 17:05, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> I like the idea. Would you like to propose a patch? I suggest to only make
> such change in Python 3.8 and properly document it.
>
> --
Michael Felt added the comment:
On 09/04/2019 18:51, STINNER Victor wrote:
> New submission from STINNER Victor :
>
> https://buildbot.python.org/all/#/builders/10/builds/2389
>
> 0:45:36 [412/420/1] test_venv crashed (Exit code 1)
> Timeout (0:15:00)!
> Thread 0x0
Change by Michael Felt :
--
pull_requests: +12704
___
Python tracker
<https://bugs.python.org/issue28009>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Felt added the comment:
Was:
root@x064:[/data/prj/python/python3-3.8]./python
Python 3.8.0a3+ (heads/bpo-28009-2-dirty:2fb2bc81c3, Apr 11 2019, 07:09:55) [C]
on aix6
Type "help", "copyright", "credits" or "license" for more informatio
Change by Michael Felt :
--
keywords: +patch
pull_requests: +12714
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36588>
___
___
Py
Michael Felt added the comment:
On 10/04/2019 18:49, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> "I am looking into this - but as it seems to have gone away again - is
> there a simple way to get that code back, and/or see what the diff is,
> before/badr
Michael Felt added the comment:
On 12/04/2019 10:28, Michael Felt wrote:
> Michael Felt added the comment:
>
> On 10/04/2019 18:49, STINNER Victor wrote:
>> STINNER Victor added the comment:
>>
>> "I am looking into this - but as it seems to have gone away aga
Michael Felt added the comment:
On 12/04/2019 16:16, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> Do you want to work on a change to replace sys.platform.startswith("aix") to
> cleanup the stdlib and tests? Not sure if it'
Michael Felt added the comment:
On 12/04/2019 17:34, STINNER Victor wrote:
> STINNER Victor added the comment:
>
>> But, should I just continue standard practice (sys.platform), or would
>> this be a moment to move towards platform.system() (i.e., set the
>> exampl
New submission from Michael Felt :
Back in 2012 (issue12326 and issue12795), and just recently (issue36588)
sys.platform has been modified (and documented) to not return the platform
version.
Additionally, the recommendation is to use the form
sys.platform.startswith() - to continue to be
Michael Felt added the comment:
On 12/04/2019 23:16, Michael Felt wrote:
> Agreed, in case of doubt - leave alone (never change a winning team).
>
> And, to make it a short reply - I'll get started, and we see where it
> leads us.
I opened issue36624 (https://bugs.pyth
Michael Felt added the comment:
I took a peak at test.support.
a) I see that while many tests import test.support, or from test.support import
- not all tests use this.
b) I see that only 35 .py files in Lib/test have the string
sys.platform.startswith, and there are 76 files that have
Michael Felt added the comment:
On 14/04/2019 18:04, Michael Felt wrote:
> Is this a good way to get started?
So, as an example - seems to be many attributes in test/support/__init__.py
diff --git a/Lib/test/support/__init__.py b/Lib/test/support/__init__.py
index 5bd15a2..e20567f 100
Michael Felt added the comment:
On 15/04/2019 11:50, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> support.is_android has two flaws:
>
> * it's a constant: it must be spelled as UPPER CASE
> * I dislike "is_" prefix: "MS_WINDOWS" c
Change by Michael Felt :
--
keywords: +patch
pull_requests: +12768
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36624>
___
___
Py
Michael Felt added the comment:
OK. I have been chewing my bone. I hope not too much indigestion.
Who has a pointer for the antacid?
Getting base branch for PR ... origin/master
Getting the list of files that have been added/changed ... 72 files
Fixing Python file whitespace ... Traceback
Michael Felt added the comment:
Never mind - typos in the files I did work on. iow, I found a way to get the
filename, and am cleaning up the errors.
--
___
Python tracker
<https://bugs.python.org/issue36
Michael Felt added the comment:
On 17/04/2019 14:02, STINNER Victor wrote:
> STINNER Victor added the comment:
>
> The same bug is back:
> https://buildbot.python.org/all/#/builders/10/builds/2443
>
> Warning -- files was modified by test_threading
> Before:
New submission from Michael Felt :
My AIX bot has been very consistent - only the multiprocessing tests failing
when run by bot, but 4 or 5 days ago 3 to 5 additional tests - that, afaik, had
never failed before, are now failing.
These may also be compiler related specifics, or the presence
Michael Felt added the comment:
On 22/04/2019 14:15, Inada Naoki wrote:
> Inada Naoki added the comment:
>
> Maybe, XLC doesn't support -D name. -Dname should be used instead.
Excellent hint: the diff between bot run 1013 and run 1014 reveals:
diff --git a/setup.py b/
Michael Felt added the comment:
On 22/04/2019 21:14, Steve Dower wrote:
> Steve Dower added the comment:
>
> I like this, though I don't like using the platform module here and would
> prefer sys.platform to be canonical (until there's a need to differentiate -
> e
Michael Felt added the comment:
On 23/04/2019 17:53, Steve Dower wrote:
> Steve Dower added the comment:
>
>> Being 'runtime' rather than 'buildtime' seemed more precise - tests that
>> are not meant to be build-time dependent use run-time status whil
Michael Osipov <1983-01...@gmx.net> added the comment:
Please close because there is actually no /usr/local on HP-UX, System V does
use /opt, not /usr/local.
--
___
Python tracker
<https://bugs.python.org/i
New submission from Michael Osipov <1983-01...@gmx.net>:
> /opt/aCC/bin/aCC -Ae -O -I./Include/internal -I. -I./Include
> -I/opt/ports/include -I/opt/ports/include -DPy_BUILD_CORE_BUILTIN -c
> ./Modules/faulthandler.c -o Modules/faulthandler.o
> "./Modules/fau
Michael Osipov <1983-01...@gmx.net> added the comment:
The memset() works as expected and compiles for me.
--
___
Python tracker
<https://bugs.python.org/i
Michael Osipov <1983-01...@gmx.net> added the comment:
I do not know because I haven't really tested that branch. My HP-UX PRs
(https://github.com/python/cpython/pulls/michael-o) are still open and apply to
master currently. We (you and me) agreed some time ago, that we go m
New submission from Michael Osipov <1983-01...@gmx.net>:
I do compile Python from master on HP-UX with aCC:
# echo $LDFLAGS $CPPFLAGS
-L/opt/ports/lib/hpux32 -I/opt/ports/include
UNIX_STD=1998 LDFLAGS="$LDFLAGS -lreadline" CPPFLAGS="-I$PREFIX/include/ncurses
$CPPFLAGS&
MICHAEL BLAHAY added the comment:
I would like to drive this to conclusion since it appears this issue has not
had any real activity in a while. First thing that needs to be determined is
whether this enhancement is still desirable. Who can answer this?
--
nosy: +MICHAEL BLAHAY
MICHAEL BLAHAY added the comment:
Ah ha, so there is. I'm glad this one will get closed out. Sorry for noob
mistake.
--
___
Python tracker
<https://bugs.python.org/is
MICHAEL BLAHAY added the comment:
I will work on this
--
nosy: +MICHAEL BLAHAY
___
Python tracker
<https://bugs.python.org/issue11698>
___
___
Python-bugs-list m
MICHAEL BLAHAY added the comment:
I will pick this on up
--
nosy: +MICHAEL BLAHAY
___
Python tracker
<https://bugs.python.org/issue36582>
___
___
Python-bug
MICHAEL BLAHAY added the comment:
My mistake, dfortunov is already working on this one.
--
___
Python tracker
<https://bugs.python.org/issue36582>
___
___
Pytho
MICHAEL BLAHAY added the comment:
I have been advised to avoid enhancements like this one, so I am setting this
back down. Also, this should be relabeled as easy(c).
--
___
Python tracker
<https://bugs.python.org/issue11
Michael Blahay added the comment:
Here is a test that more explicitly shows the problem.
>>> from collections import UserList
>>> UserList([0,1,2,3,4,5])[0:2].__class__
>>>
It can clearly be seen here that the return type of the slicing operator is
list when
Michael Blahay added the comment:
The root cause of this issue seems to be the failure to implement type usage in
__getitem__ when the deprecated __getslice__ was removed. This is why slicing
worked correctly in 2.7, but not the 3.x versions.
In 3.8, the __getitem__ method is used to create
Michael Blahay added the comment:
It is also worth noting that the definition of UserList moved from
Lib/UserList.py in 2.7 to Lib/collections/__init__.py in 3.x
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
Results from a quick unit test on the proposed changes were positive:
>>> from collections import UserList
>>> UserList([0,1,2,3,4,5])[0:2].__class__
If you compare this result with the one a couple comments above, you can see
that the r
Michael Blahay added the comment:
Thank you for bringing up that PR. My team will review and try to find out why
it was closed without a merge.
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
Please note that I am working with Erick Cervantes at PyCon2019 on this issue.
--
___
Python tracker
<https://bugs.python.org/issue27
Michael Blahay added the comment:
Let it be known that the author of PR 4981 is known as vaultah. He/she
personally closed the pull request this morning stating a lack of need to be
recognized for the work. Per his/her instructions I am reviewing the changes
and incorporating in our
Michael Blahay added the comment:
Ryan, what are the exact steps to reproduce the problem? This is what I get
when I run the code you included:
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('things', nargs=
New submission from Michael Osipov <1983-01...@gmx.net>:
The module _curses fails to build because curses cannot be found on HP-UX. In
this case, it has an unorthodox location:
> $ ll /usr/lib/hpux32/libcurses.so
lr-xr-xr-x 1 bin bin 17 2018-09-07 15:29 /usr/lib/hpux32/lib
Change by Michael Osipov <1983-01...@gmx.net>:
--
keywords: +patch
pull_requests: +13099
stage: -> patch review
___
Python tracker
<https://bugs.python.or
Change by Michael Blahay :
--
pull_requests: +13114
___
Python tracker
<https://bugs.python.org/issue27639>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Blahay added the comment:
PR 13150, the recreation of PR 4981, was noticed just after I created PR 13169.
It was decided to continue forward with PR 13169 since PR 13150 contained
changes that were out of scope for BPO-27639 for which it was suspected might
have been the cause of
Michael Blahay added the comment:
Okay, so the expected output after running parse.parse_args([]) is
Namespace(['nothing'])
--
___
Python tracker
<https://bugs.python.o
Michael Blahay added the comment:
Ryan, I have reviewed the documentation at
https://docs.python.org/3/library/argparse.html#nargs and must admit that there
is not a definitive answer that I can see regarding the defined behavior should
there be no command line arguments that are in fact
Michael Blahay added the comment:
For those that are wondering what is going on with PR 13181 and PR 13203, those
are both for back porting the change to 3.7. The auto generated PR 13181 failed
for an unknown reason and then the bot deleted the branch so the PR could not
be taken any
Michael Blahay added the comment:
For the purpose of facilitating continuing conversation, here are two tests
that contrast the use of * versus REMAINDER
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('foo', nargs=1,default=['none'])
parser.add_a
Michael Blahay added the comment:
Here is another take on the issue, this time illustrated through the lens of
optional arguments.
import argparse
parser = argparse.ArgumentParser()
parser.add_argument('--foo', nargs=1,default=['none'])
parser.add_argument('--baz&#x
Michael Blahay added the comment:
With the optional arguments, the determination about whether to use the default
value is made based on whether the flag is present or not. When positional
arguments are involved, the need for the defaults seems to in part be
determined based on whether the
Michael Blahay added the comment:
Much detail has been provided regarding why the default is ignored when user
the REMAINDER option. The desire to add an exception has not. Is there anyone
that can provide guidance on whether the combination of:
1. Positional Argument
2. nargs=REMAINDER
3
New submission from Michael Sullivan :
Per discussion during the typing summit at PyCon, it would be a good idea to
allow extra information to be included in `# type: ignore` comments, in order
to allow behavior such as suppressing individual errors (for example, with
syntax like `# type
Michael Blahay added the comment:
PR 13203 has finally made it through all checks successfully and is now
awaiting merging. Please someone pick it up and merge it. Thank you
--
___
Python tracker
<https://bugs.python.org/issue27
Change by Michael Sullivan :
--
keywords: +patch
pull_requests: +13148
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36878>
___
_
Michael Blahay added the comment:
Ryan, What say you? Will you be satisfied with the addition of a note in the
documentation?
--
___
Python tracker
<https://bugs.python.org/issue35
1401 - 1500 of 3024 matches
Mail list logo
