Paul Ganssle added the comment:
I also think it would be ideal to avoid getting into too much detail about the
definitions of UTC and GMT in a general sense. Instead, we should probably
refer to some better source on the matter and maybe focus on how UTC and GMT
are used *in this document
Change by paul j3 :
--
priority: normal -> high
___
Python tracker
<https://bugs.python.org/issue36078>
___
___
Python-bugs-list mailing list
Unsubscrib
Paul Moore added the comment:
As someone whose work environment is still Windows 7, I'd prefer it if it were
a soft desupport (i.e., we require users to manually ensure that the KB fix is
installed, but we don't do anything specific to refuse to install Python on
Win7).
I'd rather not drop
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue36145>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
Oh actually that's my mistake. I can't reproduce the failure in the constructor
in the Python version of the module, and also it seems to be fixed in the pure
Python version as of at least 3.6:
Python 3.6.7 (default, Oct 25 2018, 16:11:17)
[GCC 8.2.1
Paul Ganssle added the comment:
I'm not sure if either of these patches got merged, but at some point this was
fixed:
Python 3.7.2 (default, Feb 9 2019, 13:18:43)
[GCC 8.2.1 20181127] on linux
Type "help", "copyright", "credits" or "license&
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue15237>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue22194>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Ganssle :
In a recent python-dev thread, there was some confusion about how to get
something like `timedelta.total_microseconds()`. There is already an existing,
supported idiom for this, which is that `timedelta` implements division:
td = timedelta(hours=1
Paul Ganssle added the comment:
> 2to3 is designed as a tool to convert a Python 2 code base to Python 3 at
> once. I understand that once the code base is converted, you may want to
> revert some unwanted "useless" changes.
While this problem is likely to show up beca
Change by Paul Monson :
--
keywords: +patch
pull_requests: +12084
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36071>
___
___
Py
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
>>>
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue24643>
___
___
Python-bugs-list mailing list
Unsubscribe:
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):
1832
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 string,
so it is always
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 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 I imagine
Change by Paul Ganssle :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue35186>
___
___
Pyth
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 :
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue35186>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue36014>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 instead
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +11947
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36025>
___
___
Py
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
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 think
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 non-zero exit status 1.
> C:\myproject>
>
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-optional el
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
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +11918
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36004>
___
___
Py
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 meth
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
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 the pat
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_stream
Change by Paul Monson :
--
keywords: +patch
pull_requests: +11855
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35976>
___
___
Py
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
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 to
*crash
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 interpr
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:
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
Change by Paul Monson :
--
keywords: +patch, patch
pull_requests: +11803, 11804
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, patch
pull_requests: +11803, 11804, 11806
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Monson :
--
keywords: +patch
pull_requests: +11803
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35947>
___
___
Py
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
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
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35943>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
the m
Change by Paul Ganssle :
--
pull_requests: +11790, 11791, 11792, 11793
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailin
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
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailing list
Unsub
Change by Paul Ganssle :
--
pull_requests: +11790, 11791, 11792
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailin
Change by Paul Ganssle :
--
pull_requests: +11794
___
Python tracker
<https://bugs.python.org/issue35364>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +11790
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
I'm OK that the basic glossary item is now covered. I don't know about any of
the other issues Martin mentioned.
I've closed the issue as my original comment is addressed, but if Martin wants
to reopen it to address his concerns, I'm OK with him doing
paul j3 added the comment:
The proposed PR does not address this issue. It just adds comments to the
method code, which aren't really needed. The method is short and obvious. We
don't need, at this time, to get into questions of whether comments in
argparse.py conform to one of the PEPs
New submission from Paul Monson :
Need code and test changes to match https://bugs.python.org/issue35740
--
assignee: christian.heimes
components: SSL, Windows
messages: 334998
nosy: Paul Monson, christian.heimes, paul.moore, steve.dower, tim.golden,
zach.ware
priority: normal
Change by Paul Monson :
--
nosy: +Paul Monson
___
Python tracker
<https://bugs.python.org/issue35705>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Monson :
--
nosy: +Paul Monson
___
Python tracker
<https://bugs.python.org/issue35740>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Monson :
--
nosy: +Paul Monson
___
Python tracker
<https://bugs.python.org/issue35920>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
Well, there's some tentative plan for `setuptools` to completely adopt
distutils, so in some sense all distutils bugs are setuptools bugs as well.
That said, the reason to report it in setuptools as well is that setuptools
still supports Python 2.7, 3.5
Paul Ganssle added the comment:
@Ronald Ah, interesting, I missed that.
In my experience, distutils is pretty static and it's not particularly common
to merge changes into it. Whether or not this is in scope for distutils, it's
definitely in scope for setuptools - do you mind opening
Paul Ganssle added the comment:
@Ronald The module you've linked to seems to be using flit and doesn't have any
C extensions. Did you change over the build process, or am I missing something?
--
___
Python tracker
<https://bugs.python.
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35893>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Moore added the comment:
Is this relevant? https://bugs.python.org/issue33416 It's a backward
incompatible change to the AST in 3.8 (according to the 3.8 changelog).
--
nosy: +paul.moore
___
Python tracker
<https://bugs.python.org/issue35
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue35533>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I think this is not a bug. bpo-35535 is probably also intended behavior, but
that is less certain.
The misunderstanding here is that %W does not give you the ISO week number,
from the documentation:
%W: Week number of the year (Monday as the first day
Paul Ganssle added the comment:
Possibly related to 35535.
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35841>
___
___
Python-bugs-list m
Paul Ganssle added the comment:
> It seems a little odd to need to pull in a third-party library for this; it
> seems far more tempting for me to just do
> "datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I know my
> dates are produced by a JSON A
Paul Ganssle added the comment:
> I can see your point in not causing confusion about what this method is
> meant to be used for.
In this case, making it easy to explain what it does is less important than
making the scope and contract of the function clear so that we don't have to
Paul Ganssle added the comment:
You can see the discussion in bpo-15873 for the full rationale of why "Z" was
omitted - to quote from https://bugs.python.org/issue15873#msg307607 :
> We can have further discussion later about what exactly should be supported
> in Python
Paul Moore added the comment:
> The script executable redirects to run `"path\to\python.exe"
> "path\to\.exe"`.
But if I understood what Steve said, only if path\to\python.exe is a *relative*
pathname?
--
Paul Moore added the comment:
Steve - thanks for the clarification. If it's only affecting launching with
relative paths, then agreed it's minor (although I do recall recent discussions
somewhere about using launchers with relative paths - that use case may need
checking, but we can deal
Paul Moore added the comment:
I'm not particularly happy with the statement that "However, the latter is out
of scope here since the entry-point launchers are in distlib."
If Python is changing the semantics of __PYVENV_LAUNCHER__ in such a way that
it breaks 3rd party code, it s
New submission from Paul Watson :
The documentation for venv in Python 3.7 references using `python3` to run
venv. I do not find a `python3` executable in the kit.
https://docs.python.org/3.7/library/venv.html#module-venv
--
assignee: docs@python
components: Documentation
messages
Paul Ganssle added the comment:
> I dislike adding a public API for an optimization. Would it be possible to
> make it private? Would it make sense? tzidx => _tzidx.
This also would have been my preference, but it is unfortunately not possible
because of the way tzinfo work
Paul Ganssle added the comment:
One other thing I might mention here is that I did explore the idea of storing
this cache on the tzinfo implementation itself, but it is problematic for a
number of reasons:
1. It would either need to use some sort of expiring cache (lru, ttl) or
require
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +11122
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35723>
___
___
Py
New submission from Paul Ganssle :
When examining the performance characteristics of pytz, I realized that pytz's
eager calculation of tzname, offset and DST gives it an implicit cache that
makes it much faster for repeated queries to .utcoffset(), .dst() and/or
.tzname() though the eager
Paul Ganssle added the comment:
I agree with Victor on this. In the future, I'd really like to see us do our
best to add cross-platform uniformity to Python's strftime and strptime
support. If there really is a platform out there that doesn't support a
trailing `%`, I like the idea
paul j3 added the comment:
Let me highlight something about
https://stackoverflow.com/a/15008806/169947
The original question was how to implement an Action that accepts 'True' or
'False' as an argument. Users often try `type=bool`, which doesn't work
because of the normal behavior
paul j3 added the comment:
argparse.REMAINDER matches an empty list of arguments, just like '?' and '*'.
So they are always 'filled', even by `parse_args([])`.
'?' and '*' have some special handling of defaults in this case, see in
argparse.ArgumentParser._get_values
the two
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue35442>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I don't really know what Python was doing in version 2.3, and I don't have
immediate access to a Python 2.3 interpreter, but at least for %U and %W,
datetime is calling the platform's `strftime` under the hood, so presumably if
this is a bug it's a bug
New submission from Paul Keating :
This was originally reported on StackOverflow (53829118) and I believe the
poster has found a genuine issue. He reported a problem converting from Python
2.3 to Python 2.7 in which strptime() produced a different result for %U in the
two versions. For lack
Paul Wilkinson added the comment:
This issue does appear to be related to the FTP server (or presumably the SSL
library on the FTP server).
A test against `test.rebex.net` works with OpenSSL 1.0.1t (on Debian) and
LibreSSL 2.2.7 (macOS 10.14.2) while a test against my web host fails on both
Paul Moore added the comment:
> Yeah, and these are all essentially my fault (though I documented the
> embeddable package relatively well, modulo a few uses I hadn't imagined).
> Maybe my holiday writing project can be some better docs for choosing how to
> install Python, espe
Paul Moore added the comment:
Thanks for the clarification.
> In all the cases I've tested, regular Python install shows up first. If it's
> not installed, the Store app shows up much of the time. This feels like the
> right design (with the caveat about "much of the time"
Paul Moore added the comment:
> > Steve, assuming that I can access the Store, should I be able to install
> > both PSF 3.7.2 and Windows Store 3.7.2 simultaneously? So I could test
> > both IDLEs that beginners might install?
>
> Yes, absolutely. (To be clea
Paul Ganssle added the comment:
> What's the use case for subclassing DateTime? These classes were not designed
> with subclassing as a use case in mind.
There are several reasons for doing it, of various levels of legitimacy. The
overall theme is that people want different behavior
Paul Ganssle added the comment:
Ah, that's my mistake. I have always been under the impression that "Versions"
meant "versions affected", not "versions that this needs to be fixed for". I
usually just selected the ones where I had verified that it's a proble
Paul Ganssle added the comment:
I am somewhat uneasy about backporting this to Python 2.7 because changing the
return type of `SomeDateTime + timedelta` could be seen as a breaking change. I
have sent a message to the datetime-SIG mailing list about this for more
visibility
Change by Paul Ganssle :
--
nosy: -p-ganssle
___
Python tracker
<https://bugs.python.org/issue22005>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I do not care enough about this to fight about it.
The issue has been open long enough that I do not think it justified the
urgency of rushing through a patch just before the release and merging without
review, but now that it is in the release of multiple
Paul Ganssle added the comment:
@Serhiy Any chance we can roll these back before the release so that they can
have some time for discussion? I have serious concerns about having to support
some Python 2/3 compatibility hack in datetime for the next 6 years. If this is
worth doing at all, I
Paul Ganssle added the comment:
I'm not sure I agree with how this was resolved. We're adding complexity to the
datetime unpickler to support unpickling pickles created in Python 2 in Python
3? I also don't really understand the encoding parts of it, but it smells very
fishy to me.
I agree
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +10143
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35364>
___
___
Py
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +10142
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Py
Paul Ganssle added the comment:
Another thing to note: I'm pretty sure this was a mistake in the first place.
There are many examples of places where the datetime module was just not
designed with inheritance in mind, for example:
- issue 32404 / issue 32403 - fromtimestamp not calling
901 - 1000 of 3183 matches
Mail list logo
