[issue35383] lib2to3 raises ParseError on argument called "print"

[Martin Panter]

Martin Panter  added the comment:

Previous related reports:

* Issue 35260: “2to3” doesn’t parse Python 3’s “print” function by default 
because it is supposed to translate Python 2 syntax
* Issue 2412: “2to3” should support “from __future__ import print_function”. 
That frees up the “print” reserved keyword in Python 2.6+.

--
nosy: +martin.panter
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
superseder:  -> 2to3 Parse Error on Python 3 print() with arguments

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35438] Extension modules using non-API functions

[Josh Rosenberg]

Josh Rosenberg  added the comment:

Batteries-included extension modules aren't limited to the public and/or 
limited API; they use tons of undocumented internal APIs (everything to do with 
Py_IDENTIFIERs being an obvious and frequently used non-public API).

_PyObject_LookupSpecial is necessary to lookup special methods on the class of 
an instance (bypassing the instance itself) when no C level slot is associated 
with the special method (e.g. the math module using it to look up __ceil__ to 
implement math.ceil). Sure, each of these modules could reimplement it from 
scratch, but I'm not seeing the point in doing so.

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35438] Extension modules using non-API functions

[Eddie Elizondo]

Eddie Elizondo  added the comment:

Correction, this is not as trivial as just using `PyObject_GetAttrString`. Will 
investigate the correct behavior.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35439] New class instance not initializing variables of type list

[Ammar Askar]

Ammar Askar  added the comment:

This is expected behavior, take a look at this section in the tutorial on 
classes: 
https://docs.python.org/3/tutorial/classes.html#class-and-instance-variables

Unlike say Java, member variables need to be initialized in the constructor.

--
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35439] New class instance not initializing variables of type list

[Arturo Inzunza]

New submission from Arturo Inzunza :

List type variables in a class are not reset on new instances of the class.

Example: 

class Klazz:
lst = []
def __init__(self, va):
print(self.lst)
self.lst.append(va)


k = Klazz(1)
[]  -> This is correct as the lst value is empty on class instantiation

k2 = Klazz(2)
[1]   -> This is wrong, a totally new instance of the class retains the value 
of a previous class instance lst variable

k3 = Klazz(3)
[1, 2]  -> And so on... new instances all share the same list

--
messages: 331370
nosy: Arturo Inzunza
priority: normal
severity: normal
status: open
title: New class instance not initializing variables of type list
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] Add a function for computing binomial coefficients to the math module

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Brett, what was the purpose of the title change?

> title: The math module should provide a function for computing 
> binomial coefficients -> Add a function for computing binomial 
> coefficients to the math module

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Steve Dower  added the comment:

> In general, I don't think we've done that great a job of publicising
> the various install options on Windows - we still get pip users trying
> to install packages into the embedded distribution, which they are
> using as if it were a standalone interpreter, and as far as I can tell
> essentially no-one knows about the nuget packages for Python. Let's
> not repeat the mistakes we've made previously with this new
> distribution option.

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, especially since if/when this merges we'll finally have a good answer 
for "installing from a build without the installer" (using the PC/layout 
script, which *sigh* also needs a big fat manual).

I feel like right now there's enough here that isn't quite locked down and I 
don't want to guarantee it. For example, in a future release of Windows we may 
be able to enable it to write to the actual %APPDATA% folder instead of an 
app-private one - should we document the current paths and then "break" it in 
the future? Or should we document that using the "Reset app" features will 
clean up everything fully now, knowing that if we change the %APPDATA% location 
later then _that_ will break?

So for now, I want an unguaranteed store package that can be used but may 
change over time (and I'll update the text on the page to reflect that). Now is 
not the time to lock in all aspects of how it works, exactly as you say. But 
please hold me accountable for adding specific docs for the first 3.8 release - 
hopefully it's clear by then (if not earlier) what behavior we're happy with.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35429] Incorrect use of raise NotImplemented

[Brett Cannon]

Brett Cannon  added the comment:

This was fixed by https://github.com/python/cpython/pull/10934

--
nosy: +brett.cannon
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] Add a function for computing binomial coefficients to the math module

[Brett Cannon]

Change by Brett Cannon :


--
title: The math module should provide a function for computing binomial 
coefficients -> Add a function for computing binomial coefficients to the math 
module

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35376] modulefinder skips nested modules with same name as top-level bad module

[Brett Cannon]

Brett Cannon  added the comment:

PRs should always be against 'master' unless the issue is already fixed there.

--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35376] modulefinder skips nested modules with same name as top-level bad module

[Brett Cannon]

Change by Brett Cannon :


--
nosy: +jvr

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35376] modulefinder skips nested modules with same name as top-level bad module

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35376] modulefinder skips nested modules with same name as top-level bad module

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33747] Failed separate test_patch_propogrates_exc_on_exit in test_unittest

[miss-islington]

Change by miss-islington :


--
pull_requests: +10269

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33747] Failed separate test_patch_propogrates_exc_on_exit in test_unittest

[miss-islington]

Change by miss-islington :


--
pull_requests: +10268

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33747] Failed separate test_patch_propogrates_exc_on_exit in test_unittest

[Brett Cannon]

Brett Cannon  added the comment:


New changeset 3cf74384b53b998fa846dc2590cedf9ad2a0d5fd by Brett Cannon 
(Anirudha Bose) in branch 'master':
bpo-33747: Avoid mutating the global sys.modules dict in unittest.mock tests 
(GH-8520)
https://github.com/python/cpython/commit/3cf74384b53b998fa846dc2590cedf9ad2a0d5fd


--
nosy: +brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35438] Extension modules using non-API functions

[Eddie Elizondo]

New submission from Eddie Elizondo :

Three extension modules: _testcapimodule.c, posixmodule.c, and mathmodule.c are 
using `_PyObject_LookupSpecial` which is not API.

These should instead use `PyObject_GetAttrString`, `PyType_GetSlot`.

--
components: Library (Lib)
messages: 331364
nosy: eelizondo
priority: normal
severity: normal
status: open
title: Extension modules using non-API functions
type: behavior
versions: Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Paul Moore]

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" requiring changes 
> outside of our direct control), but without actually giving it to people in 
> all their messy configurations there is literally no way to be sure.

Agreed, it does sound like it's probably the correct approach. But I'd
strongly recommend that as much of the behaviour as possible gets
documented as part of this change. There are a *lot* of projects out
there that write code for Windows based on a relatively superficial
understanding of all of the complexities that come into play here -
most registry scanning code is based on guesswork and reverse
engineering of how things worked before PEP 514 (I should know, I
wrote rather a lot of it!!!) and plays fast and loose with even things
like 32-bit/64-bit registry overlaying (it's late and I'm tired, sorry
for not using the accurate term). Settig projects like virtualenv,
tox, nox, pew, pipenv etc up for new bug reports associated with store
installs, without any sort of guidance as to what's going on in the
official docs, seems unfriendly at best. (I'm thinking of a section in
"Python Setup and Usage" covering the store installer - that in
addition to the changes in
https://docs.python.org/3.7/using/windows.html#installation-steps
needed to mention that there's now five installers available).

> A regular install does not create "python3" and "python3.7" shortcuts on 
> PATH, so if you use those you'll prefer the store app. But we've never used 
> those, so there shouldn't be any change to existing behaviour. And I've never 
> really been opposed to adding them to the Python installer, I just haven't 
> done the work (and neither has anyone else) - I'd still be opposed to 
> modifying PATH from the traditional installer though, as all of those 
> problems remain.

The "pythonup" project (https://github.com/uranusjr/pythonup-windows)
creates versioned copies of python - python3.7.exe. Again, it's a
non-standard project, so not technically our problem, but I'd be
interested in how it would interact with the Store python.

I do appreciate that we need to get the store installer out there in
order to test things like this, and that initially at least there
aren't going to be a huge number of people using the store installer
over the traditional one (and likely vanishingly small numbers of
people using both in parallel). But conversely, there's a class of
problems that will be reported to other projects rather than to us,
and I think we should be trying to support those other projects in
dealing with this change, not simply leaving it up to them to find out
about it (I doubt they'd even know to ask "did you use the store
install or the traditional one" when diagnosing a problem).

In general, I don't think we've done that great a job of publicising
the various install options on Windows - we still get pip users trying
to install packages into the embedded distribution, which they are
using as if it were a standalone interpreter, and as far as I can tell
essentially no-one knows about the nuget packages for Python. Let's
not repeat the mistakes we've made previously with this new
distribution option.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35435] Discourage external links to old docs.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I changed the title to better state the actual issue and goal of action.

The termination solution is rejected, but further revisions to docs and site 
need not be.  Adding the auto updated https://docs.python.org/3/ was a good 
move (and a reason to not casually go to a 4.0 release) but not the end of what 
we could do.

I agree with Ned that easier internal access, such as through 'other...', would 
be nice.

--
nosy: +terry.reedy
stage:  -> needs patch
title: Documentation of 3.3 is available -> Discourage external links to old 
docs.
type:  -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35401] Upgrade Windows and macOS installers to use OpenSSL 1.1.0j / 1.0.2q

[Steve Dower]

Steve Dower  added the comment:

Bin and source dependency repos are updated - just needs the project updates 
now and testing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35403] support application/wasm in mimetypes and http.server

[Terry J. Reedy]

Change by Terry J. Reedy :


--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35402] Upgrade macOS (and Windows?) installer to Tcl/Tk 8.6.9.1

[Terry J. Reedy]

Terry J. Reedy  added the comment:

... and master.

I believe for Windows the policy has been to stick with one tcl/tk version for 
a Python version.  But I don't know that this is written on stone.  If not too 
much trouble, I would like master updated occasionally during the a1 period 
rather than just once around b1.  I am not sure about backports.

--
nosy: +serhiy.storchaka, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Ethan Smith]

Change by Ethan Smith :


--
nosy: +Ethan Smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35383] lib2to3 raises ParseError on argument called "print"

[Terry J. Reedy]

Terry J. Reedy  added the comment:

In 2.x, 'print' is a reserved keyword and compiling foo fails with SyntaxError. 
 AFAIK, 2to3 expects the input to be *valid* 2.x code that compiles.  So it 
seems to me that the bug is in the input, not 2to3, and that this issue should 
be closed as 'not a bug'.

--
nosy: +benjamin.peterson, terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Steve Dower  added the comment:

> How will the Windows Store install work alongside the PSF one?

Oh, and since I didn't mention it in my direct answer, the Store install goes 
to a totally different location (per machine, no elevation required), as do 
packages installed using pip (automatically per user). Nothing is shared 
between the two installs at all.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Steve Dower  added the comment:

> The first thing I'll note is that I'm not aware of any documentation
> on the Windows Store installer, and how it works.

Right now, correct.

> How will the Windows Store install work alongside the PSF one?

It will go into PATH under the same names as on other platforms (python, 
python3, python3.7, and same for pip and idle). The Windows Store makes it 
possible to do this reliably, so it's just on by default (and configurable 
through OS-provided UI for selecting the app to respond to a certain name).

If you have already installed it traditionally and enabled the PATH 
modification, that will take precedence. So you'll get the MSI installed 
Python. If you've modified PATH by hand, it depends on where you put it.

> If I have PSF Python 3.7.1 and Store Python
> 3.7.2 simultaneously installed, which will py.exe -3.7 select? Can I
> influence it to choose the other one? Same question for 3rd party
> tools like "virtualenv -p 3.7"

Right now, py.exe will not detect it. This is an unavoidable limitation right 
now (specifically, enumeration of classic app compatibility keys does not work, 
though direct access does), but it may become avoidable in the future (and 
being able to say "Python needs it" is actually going to be useful for removing 
the limitation).

As usual, our recommended way to influence choice of Python is to specify it. 
"virtualenv -p 3.7" will find a traditionally installed Python first, but if 
it's not there and the store one is it *might* find the store one (it depends 
whether it requests the specific registry key or tries to enumerate all of them 
- again, I've got people looking into enabling enumeration, but we're talking 
about adding another feature to Windows specifically for Python, and those take 
time).

> Basically, I'm not clear on how having the Store install and the PSF
> install simultaneously present will work - very few tools in my
> experience really support PEP 514 (not even the `py` launcher) - and
> frankly, if we're going to break tool assumptions that there's only
> one official "3.7" present at any time, we're on very shaky ground
> claiming that PEP 514 warned them if we haven't even updated our own
> supplied tool! (I know that there's lots of ways people can have
> multiple versions right now - PSF plus Anaconda, for example - but
> it's fine to say "you're mixing distributions, you're on your own" in
> that case. If the PSF is publishing two versions of 3.7, which can be
> simultaneously installed, we can't really use that argument.

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" requiring changes 
outside of our direct control), but without actually giving it to people in all 
their messy configurations there is literally no way to be sure.

A regular install does not create "python3" and "python3.7" shortcuts on PATH, 
so if you use those you'll prefer the store app. But we've never used those, so 
there shouldn't be any change to existing behaviour. And I've never really been 
opposed to adding them to the Python installer, I just haven't done the work 
(and neither has anyone else) - I'd still be opposed to modifying PATH from the 
traditional installer though, as all of those problems remain.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Paul Moore]

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 clear, both are PSF approved and under the PSF 
> name/copyright/etc., so I've been calling them "traditional" and "Store" 
> installers when I talk about them.)

I'd like to expand on this question a little. The first thing I'll
note is that I'm not aware of any documentation on the Windows Store
installer, and how it works. It's possible there's a docs patch in
here somewhere, but to be honest, there are 8 PRs linked to this issue
and I don't have the time to check them all right now.

How will the Windows Store install work alongside the PSF one? Will it
work the same, in that neither will go on PATH unless the user
explicitly requests it? If I have PSF Python 3.7.1 and Store Python
3.7.2 simultaneously installed, which will py.exe -3.7 select? Can I
influence it to choose the other one? Same question for 3rd party
tools like "virtualenv -p 3.7" - I know it's not up to us to deal with
virtualenv issues, but conversely I do think we have a responsibility
to not change assumptions that 3rd party tools rely on. In terms of
PEP 514, will the Store installer use a different tag, or some other
way of having registry entries independent of the PSF installer?

Basically, I'm not clear on how having the Store install and the PSF
install simultaneously present will work - very few tools in my
experience really support PEP 514 (not even the `py` launcher) - and
frankly, if we're going to break tool assumptions that there's only
one official "3.7" present at any time, we're on very shaky ground
claiming that PEP 514 warned them if we haven't even updated our own
supplied tool! (I know that there's lots of ways people can have
multiple versions right now - PSF plus Anaconda, for example - but
it's fine to say "you're mixing distributions, you're on your own" in
that case. If the PSF is publishing two versions of 3.7, which can be
simultaneously installed, we can't really use that argument.

Paul

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32417] fromutc does not respect datetime subclasses

[Guido van Rossum]

Change by Guido van Rossum :


--
nosy:  -gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32417] fromutc does not respect datetime subclasses

[Guido van Rossum]

Guido van Rossum  added the comment:

OK.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35435] Documentation of 3.3 is available

[Ned Deily]

Ned Deily  added the comment:

> I think as it stands, this ticket is "not a bug".

Indeed, this is not only not a bug, it's a feature that the docs for every 
Python release family are available on-line.  That said, we do have two sets of 
URLs that point to these docs:

1. https://docs.python.org/release/x.y.z/ which is the canonical link to the 
docs for a particular release and linked to from 
https://www.python.org/doc/versions/

2. https://docs.python.org/x.y/ (along with /x) which points to the most recent 
top of branch doc build for that branch.  For the next feature release branch 
(master) and branches still in bug-fix mode, the docs are automatically updated 
several times a day.  For 2.x and 3.x branches in security-fix mode or at 
end-of-life (retired), there are symlinks here that point to the doc set for 
the most recent release of that branch, i.e. the same doc set available in 
https://docs.python.org/release/x.y.z/.

There is already in place a restriction in the robots.txt file for the 
docs.python.org server to not webcrawl anything under /release but there is 
nothing (AFAICT) telling webcrawlers to ignore the "symlinked" aliases at /x.y, 
and that would seem to be the case here.

Without spending too much time on it, it seems to me there are s number of 
issues here:
1. What URL schemes do we have and want to continue to support?
2. What things do we want to show up in search engine results?
3. How do we make that happen?
4. How do we maintain this going forward?

One possibility that comes to mind:
1. unchanged from today
2. just the most current 3.x maintenance release (e.g. today 3.7)?  People 
needing accessing to other current or security-fix branches (dev, 3.6, 2.7, 
3.5) can access those docsets through the version switcher pulldown on the doc 
webpages.
3. What isn't so obvious today is how to get to docsets for other, older 
releases.  For that, perhaps we could add an "Other ..." or some such item to 
the version switcher list that would link to the complete list at 
https://www.python.org/doc/versions/ ?
4. If we think it is important to indefinitely provide the links at 
https://docs.python.org/x.y/ even after the release is retired, we could add a 
step to the release process to add an entry to robots.txt when a release enters 
security-fix-mode ?  Or earlier?  That gets back to question 2.

I think this all is something for our release docs expert, Julien, to look into.

--
assignee: docs@python -> mdk
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32417] fromutc does not respect datetime subclasses

[Paul Ganssle]

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 behaviors from their datetime 
classes and they want to maintain drop-in compatibility with datetime so that 
you don't need to re-build the whole world of datetime-handling libraries if 
you want to adopt one of these alternative datetime providers.

Ideally, you would tell people to just write API-compatible code and use 
duck-typing, but there's a lot of code in the standard library that uses 
`isinstance` checks, so things like 
`some_tzinfo.utcoffset(MyCoolDatetime.now())` will raise a TypeError.

Two popular datetime frameworks arrow and pendulum, both use datetime 
subclasses. A lot of what they are providing is convenience methods that could 
easily be free functions, but they also need to be subclasses so that they can 
change things like the semantics of arithmetic. For example, one motivation for 
the creation of pendulum was that the creator wanted this invariant to hold 
true:

assert dt1 == (dt1 - dt2) + dt2

This is basically due to the fact that in Python's datetime library, no 
distinction is made between "absolute deltas" (the absolute time between two 
events) and "calendar deltas", which makes subtraction or addition across DST 
boundaries ambiguous and occasionally lossy. Arithmetic semantics are one of 
the things about datetime I'd most love to change but for backwards 
compatibility reasons it's just not feasible.

Another reason I've seen for subclassing datetime is that this is how dateutil 
provides its backport of PEP 495 (ambiguous datetime support). We have a 
datetime subclass called _DatetimeWithFold that supports the `fold` attribute, 
and is generated only when necessary (and does not exist in Python 3.6+). 
_DatetimeWithFold is not affected by this problem because PEP 495 specifies 
that the result of an arithmetic operation always sets fold to 0, but it *was* 
affected by the earlier (now fixed) bug where the subclass did not survive a 
`replace` operation.

One last place I've seen datetime subclasses used is when you have a thin 
wrapper used for dispatch or other purposes where you are mapping between 
types. For example, at work we had to create mappings between python types and 
the types specified by a standard (developed for another language), but that 
standard specified both a datetime type (with millisecond precision) and a 
datetimeus type (with microsecond precision). The solution was a thin wrapper 
around datetime called DatetimeUs: 
https://github.com/bloomberg/python-comdb2/blob/master/comdb2/_cdb2_types.py#L62

Preventing operations from reverting to datetime was a bit of a pain, which is 
why we have a bunch of tests to check that the subclass survives basic 
operations: 
https://github.com/bloomberg/python-comdb2/blob/master/tests/test_cdb2_datetimeus.py#L95

Although it was not originally *designed* to be subclassed, support for 
datetime subclasses is already quite good. This timedelta issue is one of the 
last major issues to fix to make them truly subclass-friendly. I'll note also 
that for the past 9 years, the test suite has run all datetime tests against a 
"thin wrapper" subclass of datetime: 
https://github.com/python/cpython/blame/028f0ef4f3111d2b3fc5b971642e337ba7990873/Lib/test/datetimetester.py#L2802

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Steve Dower  added the comment:

Thanks Terry, great questions.

> I want this to be and remain an added alternative rather than a replacement 
> of the current installer directly available on python.org.  Can you assure us 
> that the latter are not going away?

Absolutely. The current installer is not going anywhere, and there's no point 
considering the possibility until we've completely dropped support for Windows 
10 1803 and earlier (which was only released this year, so dropping support is 
a long way out yet).

> Installers are always experimental until tested by multiple users on multiple 
> machines.  Even then, installation specific issues can arise. ...  To have a 
> Windows Store Python ready for 3.8, we need to start now.

Thanks for the vote of support for this point.

> 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 clear, both are PSF approved and under the PSF 
name/copyright/etc., so I've been calling them "traditional" and "Store" 
installers when I talk about them.)

Also, I've been testing IDLE regularly, since one of the advantages of being in 
the Store is that we can safely put idle[3[.7]].exe on PATH. It definitely 
works :)

I've also set up tests that run from an "installed" layout, rather than the 
source tree, and those are all passing as well (with one of the trivial test 
fixes in the PR).

> I am curious what 'restricted' versus 'non restricted' mean to Windows Store, 
> and why Python can now go there.

In general, all app stores disallow their apps from doing things that may break 
or corrupt the machines they are installed on. Apps are self-contained and can 
only operate outside of their boundaries through carefully designed 
permissions/capabilities (which often prompt the user before continuing).

Recently, Microsoft added support for "full trust" apps, which can bypass many 
of these restrictions. The aim is to allow traditional applications to swap 
their MSIs for being installed through the store, which can then ensure 
trustworthiness of at least the installers. (For example, a Store app is 
*never* going to install something into System32 or modify operating system 
files, whether it's full trust or not.) Full trust allows us to do things like 
launching non-app store processes and creating raw sockets through legacy APIs, 
so we can very easily move Python into a full trust package rather than having 
to rewrite it using approved APIs (a project that's been attempted a few times, 
but always loses low-level functionality that is considered a core part of 
Python - hence my long-term desire to make the low-level parts optional and 
have higher-level abstractions be the guaranteed parts).

> While most PRs should be complete in themselves, reasons such as ease of 
> review may suggest splitting one conceptual Pr into pieces.  They just have 
> to be reviewed together, or with expectation of a needed followup (and a 
> revert if it does not appear).  I have done this to get readable diffs for 
> major refactorings that moved and edited multiple chunks of code in a large 
> file.

I agree that it's valuable and I've done it internally plenty of times. 
Unfortunately, no matter how much people repeatedly say that a PR for CPython 
is part of a chain, there always seems to be pushback from people who ignore 
that and won't approve a critical prerequisite because there's "no need".

There's also the point that many of the changes were not known to be needed 
before the others were made. The pre-squash history is very interleaved between 
the various changes, and extracting them into separate PRs that totally stand 
alone is nearly as much work as solving the issues in the first place. I made 
the call this time to keep them all together and direct reviewers' attention 
towards the relevant parts. It turns out that didn't attract reviewers, so I'll 
come up with a new strategy next time I want to get people's attention on a 
change (maybe Buzzfeed style headlines? :) )

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31354] Fixing a bug related to LTO only build

[Charalampos Stratakis]

Charalampos Stratakis  added the comment:

Hi Ned,

I recently pushed a fix on the master and 3.7 for this exact issue: 
https://bugs.python.org/issue35351 but it builds on top of 
https://github.com/python/cpython/pull/10922 which is not yet in 3.6.

Thus 3.7 is fine for the rc cutoff.

However there is another side effect of that change with the linker flags also 
leaking: https://bugs.python.org/issue35257 but it proved to be more 
complicated than what I initially thought to fix it.

PR here: https://github.com/python/cpython/pull/10900

The issue is that I figured it wouldn't make it to the 3.6 branch as it would 
require extensive review due to the complexity of the build system and the 
requirement for extensive review to catch any possible regressions, thus it 
would be late for the rc cutoff.

It would take some days to figure out everything I believe. Would it be 
possible to push that after rc1? Or maybe not fixing that would be better, 
deadline wise? I consider this an important issue but some more feedback is 
always welcome.

Side note on your comment: The compiler used (CC) also seems to leak into 
distutils instead of the system default CC, on linux with 'python3 setup.py 
build'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Various questions and comments:

0. Steve: For more than one reason, I want this to be and remain an added 
alternative rather than a replacement of the current installer directly 
available on python.org.  Can you assure us that the latter are not going away? 
 I would have the same concern about adding something to the Apple/Mac store.

1. Ned: Since enhancements are not normally backported, it would be nice to 
have your approval, in whatever form it took, recorded here and not just in 
private email.  I give a reason below.

2. Installers are always experimental until tested by multiple users on 
multiple machines.  Even then, installation specific issues can arise.  As I 
remember, the current installer, when new in 3.5, needed a shakedown period.  
One installer-specific issue was the initial working directory.  To have a 
Windows Store Python ready for 3.8, we need to start now.

There was once an issue where one of the installers failed to include one 
idlelib file. I believe it was help.html. I since added idle_test/test_help.py, 
which would now fail with something like "No such file or directory: 
'C:\\Programs\\Python37\\Lib\\idlelib\\help.html'".)
Repository testing does not test the actual binaries that users install, in 
their production context.

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?

3. Anyone: Though it is not essential that I know, I am curious what 
'restricted' versus 'non restricted' mean to Windows Store, and why Python can 
now go there.  My search only came up with age restrictions, which python does 
not need (in my opinion).

4. While most PRs should be complete in themselves, reasons such as ease of 
review may suggest splitting one conceptual Pr into pieces.  They just have to 
be reviewed together, or with expectation of a needed followup (and a revert if 
it does not appear).  I have done this to get readable diffs for major 
refactorings that moved and edited multiple chunks of code in a large file.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32417] fromutc does not respect datetime subclasses

[Guido van Rossum]

Guido van Rossum  added the comment:

What's the use case for subclassing DateTime? These classes were not designed 
with subclassing as a use case in mind.

--
nosy: +gvanrossum

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35435] Documentation of 3.3 is available

[Mariatta Wijaya]

Mariatta Wijaya  added the comment:

> put a prominent note at the top of each page "This is an unsupported version 
> of the docs, for the latest version see blah blah blah" and link to the most 
> recent version.


Not sure how straightforward it will be to do this, and whether it will worth 
the trouble. Julien, perhaps you know more about this and can provide 
assessment. Perhaps it needs to be done from within python-docs-theme?

FWIW, the landing page of each version (example https://docs.python.org/3.3/) 
states when it was last built. It can be an indication that it is outdated.

There's also a related issue in python.org to better inform people of which 
Python versions are still maintained or not: 
https://github.com/python/pythondotorg/issues/1302

I think as it stands, this ticket is "not a bug".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32417] fromutc does not respect datetime subclasses

[Paul Ganssle]

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 problem.

I do not think this should be backported to 3.6. From the discussion in the 
datetime-SIG mailing list, we have realized that this change will *also* break 
anyone whose default constructor does not support the same signature as the 
base datetime. I think this is probably not a major problem (many other 
alternate constructors assume that the constructor accepts arguments as 
datetime does), but it's not something that I think we should be changing in a 
patch version.

--
versions:  -Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue31354] Fixing a bug related to LTO only build

[Ned Deily]

Ned Deily  added the comment:

This issue is still open and blocking the upcoming 3.7.2rc1 and 3.6.8rc1 
releases.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35401] Upgrade Windows and macOS installers to use OpenSSL 1.1.0j / 1.0.2q

[Steve Dower]

Steve Dower  added the comment:

I'm getting the cpython-source-deps repo updated now, and will do the Windows 
updates shortly after.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue17185] unittest mock create_autospec doesn't correctly replace mocksignature

[Mario Corchero]

Mario Corchero  added the comment:

Agree that it sounds reasonable to just set `__signature__` to tell `inspect` 
where to look at (thanks PEP 362 :P). Not an expert here though.

For the partials bug, I'll add Pablo as we were speaking today about something 
similar :) but that might be unrelated (though interesting and worth fixing!) 
from the issue Chris brought up.

--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32417] fromutc does not respect datetime subclasses

[STINNER Victor]

STINNER Victor  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.

You asked to backport up to Python 3.6. The change is either fine to be 
backported to 2.7 and 3.6, or should not be backported. I prefer to have the 
same policy for stable branches... but I also understand that 2.7 requires even 
more stability.

--
versions:  -Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32417] fromutc does not respect datetime subclasses

[Paul Ganssle]

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.

If it is decided that this is just a bugfix, I'm OK with creating a backport 
for 2.7 (provided that there's nothing so different about 2.7 that the fix 
becomes much bigger).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue32417] fromutc does not respect datetime subclasses

[STINNER Victor]

STINNER Victor  added the comment:

Since the C code is only a few lines, what do you think of also fixing Python 
2.7?

--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33694] test_asyncio: test_start_tls_server_1() fails on Python on x86 Windows7 3.7 and 3.x

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +10267

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Paul Ganssle]

Change by Paul Ganssle :


--
nosy:  -p-ganssle

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Paul Ganssle]

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 versions, I think we may 
be stuck with it.

This *is* something that users can work around by not abusing pickle in this 
way and instead using a proper cross-platform serialization format. I realize 
that that makes it *more difficult* for some people to do so, but as Gregory 
points out, these people are doing dangerous stuff that will break in a way 
that we are not going to be willing or able to fix at some point *anyway*.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[kellerfuchs]

kellerfuchs  added the comment:

@Steven D'Aprano:
> all call this nCr, and nPr for the permutation version. This matches 
> the notation taught in secondary school maths classes in Australia. 
> That's common and familiar notation for secondary school students, but 
> personally I'm not super-keen on it.

It's also not universal; in my experience, most calculators are localized for a 
given market, and may use different notations (in particular, the notation for 
combinations/binomial numbers changes across countries).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue9566] Compilation warnings under x64 Windows

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 028f0ef4f3111d2b3fc5b971642e337ba7990873 by Victor Stinner in 
branch 'master':
bpo-9566: Fix compiler warnings in peephole.c (GH-10652)
https://github.com/python/cpython/commit/028f0ef4f3111d2b3fc5b971642e337ba7990873


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[kellerfuchs]

kellerfuchs  added the comment:

> I'd personally prefer that floats not be accepted; I think this was a 
> misfeature of `factorial` that we shouldn't compound.

OK; I only went with that because I assumed there were Good Reasons© that 
factorial did it, but if rejecting integral floats isn't going to be a 
controversial move I'm also in favor of it.

Updating the PR momentarily to check that binomial rejects floats.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[kellerfuchs]

kellerfuchs  added the comment:

@Mark Dickinson:
> You don't mean the "k=0" part of that, right?

Indeed not; the tests in the PR actually assert binomial(n, n) == binomial(n, 
0) == 1.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[kellerfuchs]

kellerfuchs  added the comment:

@Serhiy Storchaka:
> I think that it is better to add this function in a new module imath, which 
> could contain other integer functions

imath is a fine idea, and you already started a discussion in python-ideas@, 
but it's a much bigger undertaking than just adding this one function, and you 
can move it there once imath happens.
As such, I think it's out-of-scope in this issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This issue is already open for a long time. There is a problem which can not be 
worked around from the user side. I want to get it solved in 3.6, and today is 
the last chance for this. This is important for migrating from Python 2 to 
Python 3. You can open a discussion on Python-Dev, and if there will be 
significant opposition, this change can be reverted before releasing the final 
version of 3.6.8.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Paul Ganssle]

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 think it can safely wait until the next release.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

This is the same hack as in NumPy, so we are at least consistent here. I think 
we have to keep it some time after 2020, maybe to 2025.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +10266

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35427] logging UnicodeDecodeError from undecodable strftime output

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35436] Add missing PyErr_NoMemory() calls

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Backporting to 2.7 is not so trivial due to the number of conflicts. Zackery, 
do you mind to create a backport for 2.7?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35436] Add missing PyErr_NoMemory() calls

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 2d6bc25dbc3dc5662f13917eb759f92842bf6de6 by Serhiy Storchaka in 
branch '3.6':
bpo-35436: Add missing PyErr_NoMemory() calls and other minor bug fixes. 
(GH-11015) (GH-11020) (GH-11026)
https://github.com/python/cpython/commit/2d6bc25dbc3dc5662f13917eb759f92842bf6de6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +10265

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35433] Correctly detect installed SDK versions

[Jeremy Kloth]

Jeremy Kloth  added the comment:

> Is it a warning or an error? What is the warning/error message? What is your 
> buildbot?

It is a compiler error as you point out below (with message).  By buildbot is:

https://buildbot.python.org/all/#/workers/12

> Right now, it seems like only "AMD64 Windows7 SP1 3.x" is still red:
>
> "2>C:\Program Files 
> (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140\Toolset.targets(36,5):
>  error MSB8036: The Windows SDK version 10.0.17134.0 was not found. Install 
> the required version of Windows SDK or change the SDK version in the project 
> property pages or by right-clicking the solution and selecting "Retarget 
> solution". 
> [C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pythoncore.vcxproj]"
>
> https://buildbot.python.org/all/#/builders/40/builds/1322
>
> Are you talking about this error?

All the builders on my buildbot can no longer find a matching SDK
version due to how the SDK version detection is handled.  Previously,
my buildbot had VS2015.2 installed whose build tools (version 1.2)
didn't use the property `DefaultWindowsSDKVersion` to select the SDK
version and just defaulted to Windows 8.1 SDK.  Now that I've updated
to VS2015.3 (includes build tools 1.4) it *does* use this property to
select the SDK version.  However, I have a newer SDK installed than is
listed in the hard-coded list so it defaults to highest one in the
list causing the missing SDK error.

This PR changes the detection logic to simply accept what SDK the user
has installed as long as it is newer (or the same) as the minimum
allowed version.

For those versed in MSBuild, this should be fairly self-evident, but
hopefully this helps those who are not :)

--
nosy: +jeremy.kloth

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Steve Dower  added the comment:

>> We haven't done RC yet - why is pushing this now so bad?
> I reverted your change because it broke all Windows buildbots, and we have a 
> policy to revert a change if buildbots turn red and no fix can be found in 2 
> hours

I don't dispute that policy, but you said it shouldn't go in between RC and a 
release, which it isn't.

> nitpicking: Your change modify venv and two tests, it's not purely 
> Windows-only :-)

More nitpicking: the venv changes only affect Windows. Which makes it purely 
Windows and tests, exactly as I said. Adding smiles doesn't save you from 
having to read :)

> Sorry, I don't know Windows App Store, I don't understand the restriction 
> "there has to be a release of this or it remains untestable". Would you mind 
> to elaborate?

Sure. You can start by reading this thread, but the summary is that App Store 
apps (regardless of platform) generally have to go through an approval process 
before they can be installed. Without going through this process, they can't be 
tested fully in context. I believe we should make a true release and put that 
through the process, rather than me just doing one out of my branch.

I provided instructions for developer testing above, which covers about 80% of 
what needs to be checked. The rest can only be tested by real use of a proper 
release.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35437] Almost all Windows buildbots are failing to compile

[STINNER Victor]

STINNER Victor  added the comment:

I revert the changes, so buildbots should go back to green. I asked Steve Dower 
to use a custom build to avoid such hiccup on the next attempt to merge his 
change.

--
priority: release blocker -> 
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +10264

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Change by Steve Dower :


--
pull_requests: +10263

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Paul Ganssle]

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 with Gregory here, pickle has so many other problems when used between 
versions of Python that it's simply not useful for cross-version serialization. 
It is useful for things like inter-process communication between two trusted 
instances of Python programs running the same version.

Also, what is the plan here for 2020+? Do we remove this hack for Python 3.9, 
or are we stuck with it indefinitely?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35436] Add missing PyErr_NoMemory() calls

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +10262

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35433] Correctly detect installed SDK versions

[STINNER Victor]

STINNER Victor  added the comment:

After I reverted bpo-34977 change, most Windows buildbots are back to green.

> In the process of eliminating compiler warnings on my buildbot, I needed to 
> update VS2015 to the latest toolset (VS2015 Update 3).  This in turn now 
> causes an error due about not having the required version of Windows SDK 
> installed.

Is it a warning or an error? What is the warning/error message? What is your 
buildbot?

Right now, it seems like only "AMD64 Windows7 SP1 3.x" is still red:

"2>C:\Program Files 
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140\Toolset.targets(36,5):
 error MSB8036: The Windows SDK version 10.0.17134.0 was not found. Install the 
required version of Windows SDK or change the SDK version in the project 
property pages or by right-clicking the solution and selecting "Retarget 
solution". 
[C:\buildbot.python.org\3.x.kloth-win64\build\PCbuild\pythoncore.vcxproj]"

https://buildbot.python.org/all/#/builders/40/builds/1322

Are you talking about this error?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Fri, Dec 07, 2018 at 01:37:36PM +, Mark Dickinson wrote:

> I'd personally prefer that floats not be accepted;

Agreed. We can always add support for floats later, but its hard to 
remove it if it turns out to be problematic.

We ought to require n, r (or n, k) to be non-negative ints with 0 <= r 
<= n. Extending this to negative ints or floats is probably YAGNI, but 
if somebody does need it, they can request an enhancement in the future.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> > Mathematically, `binomial(n, k)` for `k > n` is defined as 0.
> 
> It's not so clear cut. You can find different definitions out there. 
> Knuth et. al., for example, in the book "Concrete Mathematics", extend 
> the definition not just to negative k, but to negative n as well. 
> Mathematicians aren't very good at agreeing on things. :-)

I think the key word there is *extend*. To the degree that any 
mathematical definition is "obvious", the obvious definition for number 
of combinations ("n choose r") is going to be 1 for r == 0 and 0 for r > n.

However, I think that it is too easy to get the order of n and r (n and 
k) mixed up, and write combinations(5, 10) when you wanted to choose 5 
from 10. I know I make that mistake on my calculator *all the time*, and 
so do my students, even with the nPr notation. So I recommend we raise 
ValueError for r > n.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[STINNER Victor]

STINNER Victor  added the comment:

Since the first attempt broke all Windows buildbot workers, it would be nice to 
use a custom build before merging a new attempt :-) See instructions in the 
devguide:
https://devguide.python.org/buildbots/?highlight=custom#custom-builders

Note: Pablo used buildbot-custom to test a revert of the App Store change.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[STINNER Victor]

STINNER Victor  added the comment:

> We haven't done RC yet - why is pushing this now so bad?

I reverted your change because it broke all Windows buildbots, and we have a 
policy to revert a change if buildbots turn red and no fix can be found in 2 
hours:
https://pythondev.readthedocs.io/ci.html#revert-on-fail


> Most of the change is purely additive and does not modify the code base, the 
> rest is Windows-only or tests.

nitpicking: Your change modify venv and two tests, it's not purely Windows-only 
:-) By the way, as I wrote in my email, I would prefer to see the venv+tests 
change pushed in separated change (and explain why you do these changes).


> I'll add checks for outdated build machines, but there has to be a release of 
> this or it remains untestable, so it'll either be from my branch or from the 
> release branch.

Sorry, I don't know Windows App Store, I don't understand the restriction 
"there has to be a release of this or it remains untestable". Would you mind to 
elaborate?

Do you mean that buildbots must upgrade to VS 2017? Can Python 3.6 and 3.7 be 
compiled without any issue on VS 2017? Maybe send an email to buildbot-status 
if you want to see more buildbots running VS 2017 rather than VS 2015.

--

There was a small bug in your PR, in PC/launcher.c, fixed by commit 
4c49da0cb7434c676d70b9ccf38aca82ac0d64a9 (bpo-35436):

+if (executable == NULL) {
+error(RC_NO_MEMORY, L"A memory allocation failed");
+}

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35433] Correctly detect installed SDK versions

[Jeremy Kloth]

Jeremy Kloth  added the comment:

Sorry Victor, I should have added more context when I nosy'ed you to this issue.

Since you seem to be the "buildbot keeper" as of late, I wanted to give you a 
pointer to the reason for my failing buildbot.  Which, as I surmised, is 
failing compile due to the missing SDK error that is fixed by this PR ;)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 1133a8c0efabf6b33a169039cf6e2e03bfe6cfe3 by Serhiy Storchaka in 
branch 'master':
bpo-22005: Fix condition for unpickling a date object. (GH-11025)
https://github.com/python/cpython/commit/1133a8c0efabf6b33a169039cf6e2e03bfe6cfe3


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[Steven D'Aprano]

Steven D'Aprano  added the comment:

On Fri, Dec 07, 2018 at 12:04:44AM +, Raymond Hettinger wrote:

> Also, I'm not sure what the predominant choice for variable names 
> should be, "n things taken r at a time" or "n things taken k at time".
> 
> Also, it's worth considering whether the function should be called 
> "binomial", "choose", "combinations", or "comb".

I've done a quick survey of some of the most common/popular scientific 
calculators:

TI Nspire
TI-84 Plus
Casio Classpad
Casio FX-82AU Plus II

all call this nCr, and nPr for the permutation version. This matches 
the notation taught in secondary school maths classes in Australia. 
That's common and familiar notation for secondary school students, but 
personally I'm not super-keen on it.

For what its worth, the colour I prefer for this bikeshed are "comb" and 
"perm", which are the names used by the HP 48GX calculator. Second 
choice would be to spell the names out in full, "combinations" and 
"permutations".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35437] Almost all Windows buildbots are failing to compile

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

@Steve Notice that 468a15aaf9206448a744fc5eab3fc21f51966aad is currently 
reverted, so you need to push it again if you plan to add something on top of 
it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[Steve Dower]

Steve Dower  added the comment:

We haven't done RC yet - why is pushing this now so bad? Most of the change is 
purely additive and does not modify the code base, the rest is Windows-only or 
tests.

I'll add checks for outdated build machines, but there has to be a release of 
this or it remains untestable, so it'll either be from my branch or from the 
release branch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35433] Correctly detect installed SDK versions

[Steve Dower]

Steve Dower  added the comment:

No, it just automates something that's been manual for a while. Installing VS 
2017 on build bots is still a manual process ;)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35437] Almost all Windows buildbots are failing to compile

[Steve Dower]

Steve Dower  added the comment:

Okay, so apparently the buildbots are still building with VS 2015, and not VS 
2017.

I'll add a check for the new executable and repush. This was caused solely by 
the new code and not by any of the changes to existing code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +10261

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 19f6e83bf03b3ce22300638906bd90dd2dd5c463 by Serhiy Storchaka 
(Miss Islington (bot)) in branch '3.6':
bpo-22005: Fixed unpickling instances of datetime classes pickled by Python 2. 
(GH-11017) (GH-11022) (GH-11024)
https://github.com/python/cpython/commit/19f6e83bf03b3ce22300638906bd90dd2dd5c463


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[Mark Dickinson]

Mark Dickinson  added the comment:

One more decision that needs to be made: should the new function accept 
integer-valued floats? Or should any `float` input give a TypeError.

I'd personally prefer that floats not be accepted; I think this was a 
misfeature of `factorial` that we shouldn't compound.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[STINNER Victor]

STINNER Victor  added the comment:

> Revert "[3.7] bpo-34977: Add Windows App Store package (GH-10245)" (GH-11021)

That should repair buildbots, so I remove "release blocker" priority.

--
priority: release blocker -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 783b794a5e6ea3bbbaba45a18b9e03ac322b3bd4 by Victor Stinner in 
branch '3.7':
Revert "[3.7] bpo-34977: Add Windows App Store package (GH-10245)" (GH-11021)
https://github.com/python/cpython/commit/783b794a5e6ea3bbbaba45a18b9e03ac322b3bd4


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[Mark Dickinson]

Mark Dickinson  added the comment:

@kellerfuchs:

> From a mathematical standpoint, (n choose k) is defined for all non-negative 
> k, n, with (n chooze k) = 0 when k>n or k=0.

You don't mean the "k=0" part of that, right?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35431] The math module should provide a function for computing binomial coefficients

[Mark Dickinson]

Mark Dickinson  added the comment:

> Mathematically, `binomial(n, k)` for `k > n` is defined as 0.

It's not so clear cut. You can find different definitions out there. Knuth et. 
al., for example, in the book "Concrete Mathematics", extend the definition not 
just to negative k, but to negative n as well. Mathematicians aren't very good 
at agreeing on things. :-)

But that doesn't really matter: what we need to decide is what behaviour is 
useful for the users of the function.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[miss-islington]

Change by miss-islington :


--
pull_requests: +10260

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 0d5730e6437b157f4aeaf5d2e67abca23448c29a by Serhiy Storchaka in 
branch '3.7':
[3.7] bpo-22005: Fixed unpickling instances of datetime classes pickled by 
Python 2. (GH-11017) (GH-11022)
https://github.com/python/cpython/commit/0d5730e6437b157f4aeaf5d2e67abca23448c29a


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35436] Add missing PyErr_NoMemory() calls

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests:  -10257

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35324] ssl: FileNotFoundError when do handshake

[Windson Yang]

Windson Yang  added the comment:

I can't reproduce on my laptop. Would you please upload a minimal example?

--
nosy: +Windson Yang

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35434] Wrong bpo linked in What's New in 3.8

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

My bad. Thanks for fixing it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[STINNER Victor]

STINNER Victor  added the comment:

> I suggest to revert this change from Python 3.7: it broke all Windows 
> buildbots, see bpo-35437.

I reverted the change in master and I will merge PR 11021 once tests pass to 
revert in 3.7 as well.


> It doesn't seem like a good idea to push such change between a release 
> candidate and a final version :-(

I started a discussion on python-dev:
https://mail.python.org/pipermail/python-dev/2018-December/155932.html

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35433] Correctly detect installed SDK versions

[STINNER Victor]

STINNER Victor  added the comment:

Is this issue related to bpo-34977: Add Windows App Store package?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35436] Add missing PyErr_NoMemory() calls

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 602d307ac5e8a2da38a193dca3bdfef5994dfe67 by Serhiy Storchaka 
(Zackery Spytz) in branch '3.7':
bpo-35436: Add missing PyErr_NoMemory() calls and other minor bug fixes. 
(GH-11015) (GH-11020)
https://github.com/python/cpython/commit/602d307ac5e8a2da38a193dca3bdfef5994dfe67


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +10259

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[STINNER Victor]

STINNER Victor  added the comment:


New changeset cb0b78a070ea3b704416e74f64046178ae0dff3e by Victor Stinner in 
branch 'master':
Revert "bpo-34977: Add Windows App Store package (GH-10245)" (GH-11019)
https://github.com/python/cpython/commit/cb0b78a070ea3b704416e74f64046178ae0dff3e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +10258

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34977] Release Windows Store app containing Python

[STINNER Victor]

STINNER Victor  added the comment:

> Making the release experimental as part of the next 3.7 update was approved 
> by Ned (over email), so I merged the build.

I suggest to revert this change from Python 3.7: it broke all Windows 
buildbots, see bpo-35437. It doesn't seem like a good idea to push such change 
between a release candidate and a final version :-(

--
nosy: +ned.deily, vstinner
priority: normal -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35437] Almost all Windows buildbots are failing to compile

[STINNER Victor]

STINNER Victor  added the comment:

See also bpo-35433: "Correctly detect installed SDK versions".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue22005] datetime.__setstate__ fails decoding python2 pickle

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 8452ca15f41061c8a6297d7956df22ab476d4df4 by Serhiy Storchaka in 
branch 'master':
bpo-22005: Fixed unpickling instances of datetime classes pickled by Python 2. 
(GH-11017)
https://github.com/python/cpython/commit/8452ca15f41061c8a6297d7956df22ab476d4df4


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35411] FTP tests of test_urllib2net fail on Travis CI: 425 Security: Bad IP connecting.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Seems this is a glitch of Travis CI. PR 794 was created long time ago, and 
while it was regularly merged with master, tests become failing after recent 
updated. I expect that similar issues can be repeated with other old PRs.

After creating a copy of that PR (see PR 11017), all tests are passed.

--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com