Change by Paul Ganssle :
--
pull_requests: +11794, 11795
___
Python tracker
<https://bugs.python.org/issue35364>
___
___
Python-bugs-list mailing list
Unsub
Change by Paul Ganssle :
--
pull_requests: +11790, 11791, 11792, 11793
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailin
Paul Ganssle added the comment:
Hm, when I made the "What's new" issue, it added the same PR to the "Pull
requests" 4 times instead of once, and in the history it seems like it *tried*
to actually add PR 11790, 11791, 11792 and 11793 (only the first one exists at
Paul Ganssle added the comment:
Ah, sorry for the noise, this is a known issue:
https://github.com/python/bugs.python.org/issues/12
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35943>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Monson :
libffi needs to be updated to the current version for Windows builds to make it
easier to add ARM support
--
components: Windows, ctypes
messages: 335115
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity
New submission from Paul Monson :
libffi needs to be updated to the current version for Windows builds to make it
easier to add ARM support
--
components: Windows, ctypes
messages: 335116
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity
Change by Paul Monson :
--
keywords: +patch
pull_requests: +11803
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35947>
___
___
Py
Change by Paul Monson :
--
keywords: +patch, patch, patch
pull_requests: +11803, 11804, 11806
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Monson :
--
keywords: +patch, patch, patch, patch
pull_requests: +11803, 11804, 11805, 11806
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Monson :
--
keywords: +patch, patch
pull_requests: +11803, 11804
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
This issue and bpo-32417 can be closed now, as they are fixed on master.
--
versions: +Python 3.8 -Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35
New submission from Paul Ganssle :
Just noticed this (tested on Python 3.7 and 3.8):
mkdir /tmp/demo
cd /tmp/demo
cat << EOF > abc.py
raise Exception("Hi")
EOF
PYTHONPATH=: python -c ""
This will crash the interpreter with:
Fatal P
Paul Ganssle added the comment:
Tested with 3.6 and 2.7 - core dump on 3.6, no core dump on 2.7. The crash on
2.7 goes through a different path, it goes site.py > os.py >= UserDict.py >
_abcoll.py > abc.py. That may account for why it's not crashing the in
Paul Ganssle added the comment:
@Karthikeyan I would certainly consider this a duplicate of the encodings
bug/behavior that you demonstrate. I don't see an existing bug on the tracker
for it, though.
I think it's pretty clear that the interpreter needs to fail, but it seems
Change by Paul Monson :
--
components: Build, Windows
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PCBuild file changes for arm32 should be separated from code changes for
review
type: enhancement
versions
Change by Paul Monson :
--
keywords: +patch
pull_requests: +11855
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35976>
___
___
Py
Paul Ganssle added the comment:
> One enhancement of this new API is that it now reports the name of the C
> function which causes the error. The initial bug report says "Fatal Python
> error: init_sys_streams: can't initialize sys standard
streams": init_sys_strea
Paul Ganssle added the comment:
> @Guido, I recall a while back you explained the value of adding CWD to
> sys.path. Would you mind providing some insight here
I think bpo-35971 or bpo-13475 are better places to discuss that, because this
issue doesn't require CWD to be in th
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Paul Ganssle :
Datetime has many methods that "serializes" an instance to some other format -
toordinal, timestamp, isoformat, etc. Most methods that "serialize" a datetime
have a corresponding method that "deserializes" that method,
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +11918
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36004>
___
___
Py
Paul Ganssle added the comment:
I have a first-pass PR, a few questions to address:
1. Should it take three arguments or a single 3-tuple? (I've gone with 3
arguments)
2. Since all three arguments are required, should we make them positional-only?
3. Should we allow time components i
Paul Moore added the comment:
> The whole point of a venv is to give you a separate directory with a "stand
> alone" Python. As that's what you just installed with nuget, there's no point
> in creating a venv
However, shipping a copy of Python with a non-o
Paul Moore added the comment:
On Sun, 17 Feb 2019 at 14:12, jt wrote:
> subprocess.CalledProcessError: Command
> '['C:\\myproject\\tools\\windows\\.python-win\\spen-venv\\Scripts\\pip',
> 'install', '--upgrade', 'pip']' returned
Paul Ganssle added the comment:
The attached PR is more or less fully ready, I think the correct answers to 1,
3 and 4 are that we should go with 3 separate arguments and we should not allow
either time components or tz components, at least in this version.
In the future, I don't thi
New submission from Paul Ganssle :
The PyO3 test suite has been breaking since the alpha release of Python 3.8
because PyDateTimeAPI->Date_FromTimeStamp has had a breaking change in its API:
https://github.com/PyO3/pyo3/issues/352
I believe this happened when `datetime.date.fromtimest
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +11947
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36025>
___
___
Py
Paul Ganssle added the comment:
I've put *a* fix in there by introducing a new wrapper function. Ideally we
would just point the C API at the argument clinic-generated function, but
because it takes a single positional argument the argument clinic outputs a
METH_O function inste
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue36014>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue35186>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Paul Ganssle :
--
versions: -Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35186>
___
___
Python-bugs-list mailing list
Unsub
Change by Paul Ganssle :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue35186>
___
___
Pyth
Paul Ganssle added the comment:
I think I'm -1 on a general project or policy to replace all for-append loops
with list comprehensions, but I'm generally positive about individual
improvements to the code base, on a case-by-case basis.
I can't speak for anyone but myself, but
Change by Paul Monson :
--
components: Windows, ctypes
nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Add support for Windows ARM32 in ctypes/libffi
versions: Python 3.8
paul j3 added the comment:
Defaults are handled into two stages.
At the start of parsing defaults are added to the Namespace.
At the end of parsing intact defaults are evaluated with 'type'.
But a nargs='?' positional gets special handling. It matches an empty stri
paul j3 added the comment:
By defining a custom 'type' function:
def foo(astr):
if astr is argparse.SUPPRESS:
raise KeyError
return astr
I get the full traceback
1831 def take_action(action, argument_strings, option_string=None
paul j3 added the comment:
What issue might have changed this behavior? I'm not aware of any that were
trying to change either the `seen_actions` and the 'required' tests, not any
dealing with pre-existing values in Namespace.
The current handling of defaults complicates
paul j3 added the comment:
One refactoring that I'd like to see is to move all the tests at the end of
_parse_know_known_args to its caller, parse_known_args. It would have to
return more values than the current namespace and extras, in particular the
see_actions and seen_non_default_ac
Paul Moore added the comment:
Confirmed that 3.6.1rc1 fixes the issue in my original use case.
--
___
Python tracker
<http://bugs.python.org/issue29319>
___
___
New submission from Paul Moore:
The 3.6.1rc1 build seems to have a spurious "^0" at the end of the version,
before the VCS ID - 3.6.1rc1^0):
>py -3.6
Python 3.6.1rc1 (v3.6.1rc1^0:e0fbe5feee4f9c00f09eb9659c2182183036261a, Mar 4
2017, 20:00:12) [MSC v.1900 64 bit (AMD
Paul Moore added the comment:
Nick (or Steve) can you explain how I'd do that?
I have a git checkout of the 3.6 branch that I can build. But, how do I merge
in the changes from https://github.com/python/cpython/pull/575? The PR seems to
be against master, so I'm not sure how to a
Paul Moore added the comment:
OK, cool, thanks. I was sort of hoping for a way to just pull&merge direct from
the PR (patches on Windows tend to be fiddly due to EOL issues), but I can go
with old-style :-)
Yes, with that patch applied it still works fine (I copied python3.dll and
pyth
Paul Moore added the comment:
Thanks for that Steve. I had a recollection that there's a way of referencing
the PR itself as a branch within the main repo (I guess it must *be* a branch,
as how otherwise would github be able to do things like get Travis to build
it?) but I don't
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue29777>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
allow_abbrev as added with http://bugs.python.org/issue14910
I contributed to the patch, but my memory isn't fresh. The fact that this
works across the subparser boundary is, in a sense, accidental. We didn't
think about how abbreviations are handled a
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue29715>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
I think that this string falls through to the last case in
'parser._parse_optional' (the first parsing loop)
# it was meant to be an optional but there is no such option
# in this parser (though it might be a valid option in a
paul j3 added the comment:
http://bugs.python.org/issue9334, 'argparse does not accept options taking
arguments beginning with dash (regression from optparse)'
is an old discussion about strings that begin with a dash and don't
match defined flags.
One propos
paul j3 added the comment:
The change to `_parse_optional` that did go through is the ability to turn off
abbreviations
http://bugs.python.org/issue14910
Even that has had a few complaints, http://bugs.python.org/issue29777
--
___
Python tracker
Paul Moore added the comment:
Also, this is a Python 2 only issue. The problem doesn't happen in Python 3.6
(at least in my quick experiment). I'm not 100% sure if this is because the
internal implementation of IO changed in 3.x, or if it's just because we're now
using a
Changes by Paul Moore :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29817>
___
___
Python-bugs-list
Paul Moore added the comment:
Please provide a script reproducing this issue, and precise details of your
Python version. It's extremely unlikely that the problem is as broad as you
describe, as otherwise we'd have lots of reports of issues. But we'll need a
more specific
Paul Moore added the comment:
As you see from the banner, your Python 3.6 is 32-bit but your Python 2.7 is
64-bit.
I'd suggest you try 64-bit Python 3.6. This definitely looks like the SysWOW64
issue Eryk described.
--
___
Python tracker
paul j3 added the comment:
How would you rank this issue relative to other `argparse` ones? Currently I'm
following 123 open issues.
--
___
Python tracker
<http://bugs.python.org/is
Paul Moore added the comment:
Also, you need to:
1. Ensure you are using characters that are available in the encoding that
sys.stdout uses - in Python prior to 3.6, this would be your Windows *console*
code page, and in 3.6+ would be UTF-8.
2. Declare the encoding of your source code if you
Changes by paul j3 :
--
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by paul j3 :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24251>
___
paul j3 added the comment:
I'm going to close this. At most it calls for a documentation change. But
saying something like
It must be compatible with argparse._SubParsersAction.
will just confuse the average user. Any customization of this action class is
an advanced topic,
Paul Moore added the comment:
The behaviour you're describing for IE sounds like a bug to me. If you specify
a host that should bypass the proxy, then that's what should happen - it
shouldn't matter if you specify the host by IP address or by name.
I'm -1 on Python try
New submission from Paul Pinterits:
%z is listed as a supported directive in the python 3 documentation
(https://docs.python.org/3.5/library/time.html#time.strftime), but it doesn't
actually do anything:
>>> from time import strptime
>>> strptime('+',
Paul Pinterits added the comment:
I see. You're right, it does make a difference.
However, this behaviour is quite unexpected. Perhaps I just didn't read the
docs carefully enough, but it wasn't clear to me that the time module had such
half-baked support for time zones.
An un
Paul Pinterits added the comment:
No no, the docs are correct. This was definitely my mistake. I'm just trying to
say that it's rather confusing how there's only partial support for time zones.
When I saw that there is support for parsing the time zone offset, I assumed
tha
Paul Durack added the comment:
I have attempted to quieten these using:
In [2]: import warnings
...: warnings.filterwarnings('ignore', category=DeprecationWarning)
In [3]: import vcs
/home/user/anaconda2/envs/cdatcmornclnco/lib/python2.7/json/encoder.py:207:
DeprecationWarning: In
New submission from Paul Durack:
I have started receiving the following warnings which are starting to prevent
an ipython session from functioning:
/home/user/anaconda2/envs/cdatcmornclnco/lib/python2.7/json/encoder.py:207:
DeprecationWarning: Interpreting naive datetime as local 2017-04-12
Paul Durack added the comment:
@r.david.murray, rather than just closing this issue (which appears to be
occurring intermittently for other users), is there a doc that you can point to
that describes why there is a DeprecationWarning being printed - and what
change has occurred (and when
Paul Durack added the comment:
I also wonder whether the fact that the warnings library doesn't seems to be
catching these errors when
In [2]: import warnings
...: warnings.filterwarnings('ignore', category=DeprecationWarning)
In [3]: import vcs
/home/user/anaconda2/envs/cda
Paul Durack added the comment:
@r.david.murray, is this not the stdlib?
https://github.com/python/cpython/blob/master/Lib/json/encoder.py#L182-L202
The error message appears to be pointing back to this, how (and why) it gets
there (and what has changed recently so that this DeprecationWarning
Paul Durack added the comment:
@r.david.murray fair enough, so it's an external lib that is the problem..
It does appear that similar issues have been appearing fairly recently across
the github-o-sphere, some of these instances are listed at
https://github.com/jupyter/jupyter/issue
Paul Durack added the comment:
@r.david.murray, yep one step ahead of your last comment
https://github.com/UV-CDAT/vcs/issues/170#issuecomment-294219991
feel free to chime in if you think something else would be useful to highlight
--
___
Python
paul j3 added the comment:
And only for integers smaller than 257!
The problem is with this test in `take_action` function
# error if this argument is not allowed with other previously
# seen arguments, assuming that actions that use the default
# value
Changes by paul j3 :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue30163>
___
___
Python-bugs-list
paul j3 added the comment:
This issue was raised in 2013. The proposed patch is still pending
http://bugs.python.org/issue18943
I'm going to close this new one, though it is a good reminder of a rare, but
persistent bug.
--
___
Python tr
paul j3 added the comment:
This came up again, http://bugs.python.org/issue30163
An optional with int type and small integer default.
--
priority: normal -> high
___
Python tracker
<http://bugs.python.org/issu
Changes by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<http://bugs.python.org/issue30152>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
paul j3 added the comment:
In http://bugs.python.org/issue9353 Steven Bethard includes 'ArgumentTypeError'
in a list of values that "look like they should be public but aren't in
__all__::".
I take that `__all__` list to be the ultimate authority on what's pu
New submission from saumitra paul:
saumitra paul choudhury has invited you to view the following document:
Open in Docs
<https://accounts.google.com/o/oauth2/auth?client_id=187102321219-1cb4b2gdr0bqv5u5n35vi1hecjcp1sjg.apps.googleusercontent.com&scope=https%3A%2F%2Fmail.google.com%2F+h
paul j3 added the comment:
I didn't mean to question the use of value tests in the 'type' callable. The
ArgumentTypeError example in the documentation does that kind of test.
Argparse is using the term 'type' loosely. It just means any kind of
conversion and/or test
Paul Moore added the comment:
> Since we don't AFAIK have any possibility of mixed virtual environments
> ignoring SheBangs should meet the basic requirements of operating inside of a
> venv.
If you want a script to use the current environment, then #!/usr/bin/env python
does
Paul Moore added the comment:
The reasons for not adding Python to PATH by default are complex. We've tried
both ways and neither is 100% satisfactory.
The default install is a per-user install. If we added Python to PATH, then as
a user setting it would come *after* the system part of
paul j3 added the comment:
I haven't downloaded the development distribution to this computer, so can't
write formal patches at this time.
--
___
Python tracker
<http://bugs.python.o
Paul Moore added the comment:
I'd be wary of leaving out of date registry entries around. Maybe make it a
separate script (or part of build.bat but requiring a command line flag to
request it)?
Alternatively (or as well) we could have a cleanup command that removes
registry entrie
Paul Moore added the comment:
Hmm, thinking a bit further, are you just suggesting registering the build as
-3.7? What if I were to build the 3.6 branch? Would that overwrite my "real"
3.6 registry entries?
As things stand, the launcher can only register two copies of Python for
New submission from Paul Moore:
The documentation for the encoding of sys.stdin/out/err (see
https://docs.python.org/3.6/library/sys.html#sys.stdout) does not reflect the
change in Python 3.6 on Windows to use the console Unicode APIs, and hence
UTF-8 for the encoding.
--
assignee
Paul Moore added the comment:
I'm also not a fan of the -0 option. I'm OK with the ability to list available
interpreters, but there's nothing about -0 as an option that says to me that's
what it's for.
I'm not a huge fan of including the list in the standard hel
paul j3 added the comment:
Any changes here including the latest pull request might conflict with
http://bugs.python.org/issue29553
Argparser does not display closing parentheses in nested mutex groups
If someone uses nested mutually exclusive groups (which I don't think they
should
paul j3 added the comment:
I don't anticipate any backward compatibility issues with the proposed patch.
But at the same time it feels almost too trivial of an issue to merit a patch.
A short metavar such as `metavar="ID"' or even `metavar="_"' would be
paul j3 added the comment:
http://bugs.python.org/issue26394
Have argparse provide ability to require a fallback value be present
is a related issue - getting 'required' values from a config file.
--
___
Python tracker
<http://bu
paul j3 added the comment:
http://bugs.python.org/issue29670
argparse: does not respect required args pre-populated into namespace
wants to put 'required' values in the Namespace. That's a similar issue.
An idea that I tried for that (but didn't submit as a patch) is to mo
paul j3 added the comment:
http://bugs.python.org/issue27859
argparse - subparsers does not retain namespace
may complicate this issue. Due to changes in http://bugs.python.org/issue9351,
a user defined namespace is not passed to the subparsers. They get a fresh
namespace, which is then
Paul Kehrer added the comment:
As someone who built an idna aware API for pyca/cryptography and deeply regrets
it I'd like to weigh in on the side of saying that IDNA is a presentation issue
and that supporting it in lower level APIs is the cause of many bugs, some of
which can potential
Changes by Paul Kehrer :
--
nosy: -reaperhulk
___
Python tracker
<http://bugs.python.org/issue11783>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I'm a bit confused what you're asking for here.
Certainly if you embed Python, you can get crashes, just as with any other C
program. Pass an invalid pointer to a Python API, build your application and
the Python DLL with incompatible C runtimes, free
Paul Moore added the comment:
Worked fine for me:
>cl .\pyc.c /I $env:LOCALAPPDATA\Programs\Python\Python36\include
>$env:LOCALAPPDATA\Programs\Python\Python36\libs\python36.lib
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24213.1 for x64
Copyright (C) Microsoft Corporation
Paul Moore added the comment:
My bet is still on something like you compiling your code 32-bit and linking to
64-bit Python, or something like that.
--
___
Python tracker
<http://bugs.python.org/issue30
Changes by Paul Moore :
--
nosy: -paul.moore
___
Python tracker
<http://bugs.python.org/issue30574>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue24643>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
Because what's being printed is a tuple, I think it's not exactly the same as
issue35417, because in fact this is the correct behavior for 2to3, note that in
Python 2:
Python 2.7.15 (default, Jul 21 2018, 11:13:03)
>>> print 1, 2
1 2
&g
Change by Paul Monson :
--
keywords: +patch
pull_requests: +12084
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36071>
___
___
Py
1201 - 1300 of 3008 matches
Mail list logo
