Re: [Python-Dev] Is object the most base type? (bpo-20285)
On Fri, Feb 02, 2018 at 01:53:00AM -0500, Terry Reedy wrote: > >>> object.__doc__ > 'The most base type' [...] > I have suggested > "The superclass for all Python classes." > "The starting base class of all types and classes other than itself." > > I intended to pick the second, but Serhiy Storchake wants more opinions. Yay, bike-shedding! How about: "the base class of the class heirarchy" "the root of the class heirarchy" Java used to say this about Object: "The root class of the Java class hierarchy. All non-primitive types (including arrays) inherit either directly or indirectly from this class." but now says: "Class Object is the root of the class hierarchy. Every class has Object as a superclass. All objects, including arrays, implement the methods of this class." https://developer.android.com/reference/java/lang/Object.html Ruby says this about Object and BasicObject: "Object is the default root of all Ruby objects. Object inherits from BasicObject which allows creating alternate object hierarchies." "BasicObject is the parent class of all classes in Ruby. It's an explicit blank class." https://ruby-doc.org/core-2.5.0/Object.html https://ruby-doc.org/core-2.5.0/BasicObject.html The root of Julia's object heirarchy is Any, but if it is documented anywhere, I can't find it. The interactive help just says: Any No documentation found. Summary: abstract Any <: Any -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Is object the most base type? (bpo-20285)
>>> object.__doc__ 'The most base type' I and several people on python-list thread "interactive help on the base object" (Dec 2013) thought this could be improved. On https://bugs.python.org/issue20285 and https://github.com/python/cpython/pull/4759 After some research, I believe the following, which is wrote on the issue, explains the uneasiness many feel. 'Base' is actually two words. As a noun (or verb), it comes from Ancient Greek βάσις (básis), a foundation from which other things extend or derive. As an adjective, it comes from Late Latin bassus (“low”). In computer science and Python, the couplet 'base class' is being used, it seems to me and apparently others, as a noun-noun compound, meaning, 'foundation class', not as an adjective-noun phrase meaning 'low class' (let along 'depraved class'). However, 'most base class' must be parsed as '(most base) class', with 'base' re-interpreted as the adjective meaning 'low' (or worse). The switch in meaning of 'base' is similar in 'baseball' versus 'most base ball'. --- I have suggested "The superclass for all Python classes." "The starting base class of all types and classes other than itself." I intended to pick the second, but Serhiy Storchake wants more opinions. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dataclasses and correct hashability
On 2 February 2018 at 11:49, Elvis Pranskevichus wrote: > In my experience this type of breakage is so subtle that people will > happily write code lots of code like this without noticing. My main > objection here is that the dataclass does not go far enough to prevent > obviously wrong behaviour. Or it goes too far with the whole hash/ > frozen distinction. For 3.7, I think we should seriously considered just straight up disallowing the "hash=True, frozen=False" combination, and instead require folks to provide their own hash function in that case. "Accidentally hashable" (whether by identity or field hash) isn't a thing that data classes should be allowing to happen. If we did that, then the public "hash" parameter could potentially be dropped entirely for the time being - the replacement for "hash=True" would be a "def __hash__: ..." in the body of the class definition, and the replacement for "hash=False" would be "__hash__ = None" in the class body. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dataclasses and correct hashability
On Thursday, February 1, 2018 8:37:41 PM EST Eric V. Smith wrote: > > hash=None and compare=True leads to the same result, which, I > > think is even worse. > > Have you actually tried that? I meant this: @dataclasses.dataclass(hash=True) class A: foo: int = dataclasses.field(compare=True) > I don't recommend ever specifying the decorator hash= parameter > unless you have an unusual use case, in which case it's on you to > get it right. In my experience this type of breakage is so subtle that people will happily write code lots of code like this without noticing. My main objection here is that the dataclass does not go far enough to prevent obviously wrong behaviour. Or it goes too far with the whole hash/ frozen distinction. Elvis ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dataclasses and correct hashability
On 2/1/2018 8:29 PM, Elvis Pranskevichus wrote: On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote: I should add: This is why you shouldn't override the default (hash=None) unless you know what the consequences are. Can I ask why you want to specify hash=True? hash=None and compare=True leads to the same result, which, I think is even worse. Have you actually tried that? >>> @dataclass(hash=None) ... class A: ... foo: int = field(hash=True, compare=True) ... >>> hash(A(2)) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'A' I believe the default hash=None on the class decorator does right thing. Please provide a counter-example. >> You're allowed to override the parameters to dataclasses.dataclass >> for cases where you know what you're doing. Consenting adults, >> and all. > > I don't agree with this. You are comparing implicit dataclass > behavior with an explicit shoot-in-the-foot __hash__() definition. I don't recommend ever specifying the decorator hash= parameter unless you have an unusual use case, in which case it's on you to get it right. There was recently a long python-dev discussion on this issue. I need to update the PEP to reflect it, but the advice still stands: you almost always want to use the default hash=None. Do you have a use case for specifying a hash function on a class with mutable instances? Maybe you want frozen=True? Eric ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dataclasses and correct hashability
On Thursday, February 1, 2018 8:21:03 PM EST Eric V. Smith wrote: > I should add: This is why you shouldn't override the default > (hash=None) unless you know what the consequences are. Can I ask > why you want to specify hash=True? hash=None and compare=True leads to the same result, which, I think is even worse. > You're allowed to override the parameters to dataclasses.dataclass > for cases where you know what you're doing. Consenting adults, > and all. I don't agree with this. You are comparing implicit dataclass behavior with an explicit shoot-in-the-foot __hash__() definition. Elvis ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dataclasses and correct hashability
On 2/1/2018 8:17 PM, Eric V. Smith wrote:
On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote:
There appears to be a critical omission from the current dataclass
implementation: it does not make hash=True fields immutable.
Per Python spec:
"the implementation of hashable collections requires that a key’s hash
value is immutable (if the object’s hash value changes, it will be in
the wrong hash bucket)"
Yet:
import dataclasses
@dataclasses.dataclass(hash=True)
class A:
foo: int = dataclasses.field(hash=True, compare=True)
a = A(foo=1)
s = set()
s.add(a) # s == {a}
a.foo = 2
print(a in s)
print({a} == s}
print(s == s)
# prints False False True
This looks to me like a clearly wrong behavior.
Elvis
Data classes do not protect you from doing the wrong thing. This is the
same as writing:
class A:
def __init__(self, foo):
self.foo = foo
def __hash__(self):
return hash((self.foo,))
You're allowed to override the parameters to dataclasses.dataclass for
cases where you know what you're doing. Consenting adults, and all.
I should add: This is why you shouldn't override the default (hash=None)
unless you know what the consequences are. Can I ask why you want to
specify hash=True?
Eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dataclasses and correct hashability
On 2/1/2018 7:34 PM, Elvis Pranskevichus wrote:
There appears to be a critical omission from the current dataclass
implementation: it does not make hash=True fields immutable.
Per Python spec:
"the implementation of hashable collections requires that a key’s hash
value is immutable (if the object’s hash value changes, it will be in
the wrong hash bucket)"
Yet:
import dataclasses
@dataclasses.dataclass(hash=True)
class A:
foo: int = dataclasses.field(hash=True, compare=True)
a = A(foo=1)
s = set()
s.add(a) # s == {a}
a.foo = 2
print(a in s)
print({a} == s}
print(s == s)
# prints False False True
This looks to me like a clearly wrong behavior.
Elvis
Data classes do not protect you from doing the wrong thing. This is the
same as writing:
class A:
def __init__(self, foo):
self.foo = foo
def __hash__(self):
return hash((self.foo,))
You're allowed to override the parameters to dataclasses.dataclass for
cases where you know what you're doing. Consenting adults, and all.
Eric.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Dataclasses and correct hashability
There appears to be a critical omission from the current dataclass
implementation: it does not make hash=True fields immutable.
Per Python spec:
"the implementation of hashable collections requires that a key’s hash
value is immutable (if the object’s hash value changes, it will be in
the wrong hash bucket)"
Yet:
import dataclasses
@dataclasses.dataclass(hash=True)
class A:
foo: int = dataclasses.field(hash=True, compare=True)
a = A(foo=1)
s = set()
s.add(a) # s == {a}
a.foo = 2
print(a in s)
print({a} == s}
print(s == s)
# prints False False True
This looks to me like a clearly wrong behavior.
Elvis
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OS-X builds for 3.7.0
>> Ned Deily is in charge of the Mac build (as well as current release > manager). Within the last week, he revised the official builds (now two, I > believe) for 3.7.0b1, due in a day or so. One will be a future oriented > 64-bit build. The PR and What's New have more. > What's New doesn't mention it, but Ned's annoucemtn does: """ Attention macOS users: with 3.7.0b1, we are providing a choice of two binary installers. The new variant provides a 64-bit-only version for macOS 10.9 and later systems; this variant also now includes its own built-in version of Tcl/Tk 8.6. We welcome your feedback. """ So that's a start -- thanks Ned! He may not be reading this thread, but will read MacOS tracker issues with > a specific proposal, data and a patch. Comparisons should be against the > current master or an installed 3.7.0b1. I hope the folks on this thread that know what they are doing can test and make suggestions :-) -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is Python for Windows compiled with MSVC?
> I would also point out that CPython (distutils, specifically)
supported mingw builds (that's the original mingw 32-bit version) for
a long time. Support for that bit-rotted as the mingw project
fragmented with various 64-bit versions, and slow progress from the
mingw project(s) for supporting newer CRTs on Windows. No-one from the
community who used mingw was providing patches back to distutils or
Python, and so the support for mingw was (I believe) dropped. It
sounds as if people have since then got things to a point where
building extensions with (some form of ) mingw is possible, but I
don't know the details, and I'm not aware of any documentation that's
been contributed back to Python on how "mingw support for building
extensions" works these days.
The question isn't whether I can build Python with MinGW: I know I can. The
problem is that if I do that, I make the users of my package depend on my
special build of Python. This also means that the packages built by others
(who are unaware of my special build of Python) may or may not work for them.
In practice, if I want to make sure that the users of my packages can actually
use them, I cannot allow myself to link them against a Python binary of my
choice. It has to be their choice.
We'd be more than happy to support building extensions with
alternative compilers (such as one of the various gcc builds that go
under the banner of "mingw") - that's a completely different matter
than switching the CPython build process to use mingw - but it's down
to the community of users of such a compiler to contribute that
support. Expecting "someone else", and particularly someone who
doesn't need it, to provide that support, is unreasonable.
Well, guys, since you are here, I assumed you were in the business of deciding
which compiler to compile your code with. I really, just asked a question.
It's obvious that I don't agree with your decision, but I wanted to hear your
argument. Nowhere did I suggest that you should do any work for me or anything
of that kind. All I wanted was information to make an informed decision about
using Python and its extensions ecosystem. I've got my answers, for which I'm
thankful.
I'm sorry for the disclaimer that follows this email. Unfortunately, I'm too a
slave of circumstances, s.a. my employer and the IT department that would not
let me send an email without this legal mumbo-jumbo.
Best.
Oleg
This communication and all information contained in or attached to it is
confidential, intended solely for the addressee, may be legally privileged and
is the intellectual property of one of the companies of NEX Group plc ("NEX")
or third parties. If you are not the intended addressee or receive this message
in error, please immediately delete all copies of it and notify the sender. We
have taken precautions to minimise the risk of transmitting software viruses,
but we advise you to carry out your own virus checks on any attachments. We do
not accept liability for any loss or damage caused by software viruses. NEX
reserves the right to monitor all communications. We do not accept any legal
responsibility for the content of communications, and no communication shall be
considered legally binding. Furthermore, if the content of this communication
is personal or unconnected with our business, we accept no liability or
responsibility for it. NEX Group plc is a public limited company regi
stered in England and Wales under number 10013770 and certain of its
affiliates are authorised and regulated by regulatory authorities. For further
regulatory information please see www.NEX.com.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is Python for Windows compiled with MSVC?
On Feb 1, 2018, at 04:19, Oleg Sivokon wrote: > > Oh, so this is the real reason... well, corporate interests are hard to argue > against. But, this is an interesting statistic nevertheless. Thanks for > letting me know. Maybe it hasn’t happened because no volunteer has stepped up to do it. Or maybe no corporation thinks it a good business investment to pay employees to do it. What other options are there, and if none, then which of those can you solve? Or to paraphrase a timeless quote: Ask not what Python can do for you, ask what you can do for Python. -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is Python for Windows compiled with MSVC?
> As much as Steve is unlikely to do the work to initiate and > maintain support of these other tools—whether due to his employer's > interests or his own—I too was unlikely to do work like this thread is > asking. In fact, the chances I would have done it were zero because I was > sitting on my couch upgrading our Visual Studio versions because it let me > do better stuff at my day job, though I was always open to review patches > that supported alternatives without major disruption. However, they never > came. I suspect the same could be said of Martin and anyone else working in > this area prior to that, because nothing has really changed. It would be cool though if Microsoft started providing a cross-compiler running on Linux. This could even be the only compiler shipped with Visual Studio, now that Windows can run Linux userland. Cross-compilers from Microsoft would not be totally unheard of. IIRC, the last DOS versions (Visual C++ 1.5x) were Win32 binaries building for DOS 16 bit. Technically speaking, using a 32 bit compiler for building for 64 bit Windows or the other way around would probably count as cross-compilation anyway. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is Python for Windows compiled with MSVC?
On Thu, Feb 1, 2018 at 4:19 AM, Oleg Sivokon wrote: > > > so why shouldn’t the one with the most users? > > Because it makes compilation difficult, and cross-compilatin completely > impossible? Why is it difficult: a package maintainer needs to (1) buy MS > Windows (2) create a special workflow for compiling on a different > machine. This is both costly and inconsistent with free-as-in-freedom... > It makes cross-compilation impossible because libraries produced by any > tool that can run on all target platforms are incompatible with Python > binaries on MS Windows. > > Again, many languages (i.e. projects similar in size an purpose to > CPython) took a different approach: they use GNU compilers to be able to > compile cross-platform. This is true for Ruby and Go at least. I would > need to investigate further, but I think these two examples should be > enough. > They should be enough for *what*, though? You can tell people what everyone else is doing, but the difference between that and what we have is someone's time and effort. > I’m likely biased because I work there and I’m the main intermediary with > python-dev, but these days Microsoft is one of the strongest supporters of > CPython. We employ the most core developers of any private company and we > all are allowed work time to contribute, we provide full access to our > development tools and platforms to all core developers and some prominent > projects, we’ve made fixes, enhancements and releases or core products such > as the CRT, MSVC, Visual Studio, Visual Studio Code, and Azure SPECIFICALLY > to support CPython development and users. As far as I know, ALL the Windows > buildbots are running on Azure subscriptions that Microsoft provides > (though managed by some awesome volunteers). You’ll see us at PyCon US > under the biggest banner and we’ll have a booth filled with engineers and > not recruiters. Crash reports from thousands of opted-in users come into > our systems and have directly lead to both CPython and Windows bug fixes. > > Oh, so this is the real reason... well, corporate interests are hard to > argue against. But, this is an interesting statistic nevertheless. Thanks > for letting me know. I think that's a mischaracterization of the situation. The MS toolchain was chosen some time long before I (or Steve) got involved, and when I upgraded us from VS2008 to VS2010 for 3.3 ~6 years ago I had several messages similar to this thread. As much as Steve is unlikely to do the work to initiate and maintain support of these other tools—whether due to his employer's interests or his own—I too was unlikely to do work like this thread is asking. In fact, the chances I would have done it were zero because I was sitting on my couch upgrading our Visual Studio versions because it let me do better stuff at my day job, though I was always open to review patches that supported alternatives without major disruption. However, they never came. I suspect the same could be said of Martin and anyone else working in this area prior to that, because nothing has really changed. Like the previous times this sort of question has come up—and really, for any question on this list—it ultimately turns into a matter of how much the solution is wanted and how much effort people are willing to give to make it happen. Historically, the former has had small amounts, and the latter has had much smaller amounts. Without a change there I don't think one will materialize in a released version of Python. Brian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is Python for Windows compiled with MSVC?
On 2018-02-01 10:19, Oleg Sivokon wrote: > >> so why shouldn’t the one with the most users? > > Because it makes compilation difficult, and cross-compilatin completely > impossible? Why is it difficult: a package maintainer needs to (1) buy MS > Windows (2) create a special workflow for compiling on a different machine. > This is both costly and inconsistent with free-as-in-freedom... It makes > cross-compilation impossible because libraries produced by any tool that can > run on all target platforms are incompatible with Python binaries on MS > Windows. > > Again, many languages (i.e. projects similar in size an purpose to CPython) > took a different approach: they use GNU compilers to be able to compile > cross-platform. This is true for Ruby and Go at least. I would need to > investigate further, but I think these two examples should be enough. > >> I’m likely biased because I work there and I’m the main intermediary with >> python-dev, but these days Microsoft is one of the strongest supporters of >> CPython. We employ the most core developers of any private company and we >> all are allowed work time to contribute, we provide full access to our >> development tools and platforms to all core developers and some prominent >> projects, we’ve made fixes, enhancements and releases or core products such >> as the CRT, MSVC, Visual Studio, Visual Studio Code, and Azure SPECIFICALLY >> to support CPython development and users. As far as I know, ALL the Windows >> buildbots are running on Azure subscriptions that Microsoft provides (though >> managed by some awesome volunteers). You’ll see us at PyCon US under the >> biggest banner and we’ll have a booth filled with engineers and not >> recruiters. Crash reports from thousands of opted-in users come into our >> systems and have directly lead to both CPython and Windows bug fixes. > > Oh, so this is the real reason... well, corporate interests are hard to argue > against. But, this is an interesting statistic nevertheless. Thanks for > letting me know. You are drawing the wrong conclusion here. CPython has been using MSVC many years before Microsoft even started to sponsor MSDN subscriptions for core developers. MSVC is the default Windows compiler for over 20 years now. IIRC Microsoft started to donate MSDN subscription for about 5 years and Steve has been helping out with Windows improvement for about 5 years. Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is Python for Windows compiled with MSVC?
> so why shouldn’t the one with the most users?
Because it makes compilation difficult, and cross-compilatin completely
impossible? Why is it difficult: a package maintainer needs to (1) buy MS
Windows (2) create a special workflow for compiling on a different machine.
This is both costly and inconsistent with free-as-in-freedom... It makes
cross-compilation impossible because libraries produced by any tool that can
run on all target platforms are incompatible with Python binaries on MS Windows.
Again, many languages (i.e. projects similar in size an purpose to CPython)
took a different approach: they use GNU compilers to be able to compile
cross-platform. This is true for Ruby and Go at least. I would need to
investigate further, but I think these two examples should be enough.
> I’m likely biased because I work there and I’m the main intermediary with
> python-dev, but these days Microsoft is one of the strongest supporters of
> CPython. We employ the most core developers of any private company and we all
> are allowed work time to contribute, we provide full access to our
> development tools and platforms to all core developers and some prominent
> projects, we’ve made fixes, enhancements and releases or core products such
> as the CRT, MSVC, Visual Studio, Visual Studio Code, and Azure SPECIFICALLY
> to support CPython development and users. As far as I know, ALL the Windows
> buildbots are running on Azure subscriptions that Microsoft provides (though
> managed by some awesome volunteers). You’ll see us at PyCon US under the
> biggest banner and we’ll have a booth filled with engineers and not
> recruiters. Crash reports from thousands of opted-in users come into our
> systems and have directly lead to both CPython and Windows bug fixes.
Oh, so this is the real reason... well, corporate interests are hard to argue
against. But, this is an interesting statistic nevertheless. Thanks for
letting me know.
Best.
Oleg
This communication and all information contained in or attached to it is
confidential, intended solely for the addressee, may be legally privileged and
is the intellectual property of one of the companies of NEX Group plc ("NEX")
or third parties. If you are not the intended addressee or receive this message
in error, please immediately delete all copies of it and notify the sender. We
have taken precautions to minimise the risk of transmitting software viruses,
but we advise you to carry out your own virus checks on any attachments. We do
not accept liability for any loss or damage caused by software viruses. NEX
reserves the right to monitor all communications. We do not accept any legal
responsibility for the content of communications, and no communication shall be
considered legally binding. Furthermore, if the content of this communication
is personal or unconnected with our business, we accept no liability or
responsibility for it. NEX Group plc is a public limited company registered in
England and Wales under number 10013770 and certain of its affiliates are
authorised and regulated by regulatory authorities. For further regulatory
information please see www.NEX.com.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OS-X builds for 3.7.0
On Thu, Feb 1, 2018 at 12:18 AM, Chris Barker wrote: > On Wed, Jan 31, 2018 at 3:13 AM, Joni Orponen > wrote: > >> On Wed, Jan 31, 2018 at 12:43 AM, Chris Barker - NOAA Federal < >> chris.bar...@noaa.gov> wrote: >> >>> And maybe we could even get rid of the "Framework" builds.. >>> >>> Please do not. These make life easier for doing things the Apple way for >>> signed sandboxed applications. >>> >>> For the record, are you re-distributing the python.org builds, or >>> re-building yourself? >>> >> >> We are re-building ourselves. >> > > Then it makes no difference to you if the pyton.org binaries are > Framework builds... though maybe you want the configure target available. > And if the official distribution distributes a Framework, the configure target and build for that are also actually maintained, which will keep them likelier usable. Would we not be doing a couple of very specific things, we'd be able to use the distributed Framework as well. It is not unconceivable we could use it as-is in the future or for other projects. -- Joni Orponen ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Why is Python for Windows compiled with MSVC?
On 1 February 2018 at 00:42, Gregory P. Smith wrote: > TL;DR of Steve's post - MSVC is the compiler of choice for most serious > software on Windows. So we use it to best integrate with the world. There is > no compelling reason to change that. > > The free-as-in-beer MSVC community edition is finally non-sucky (their > earlier efforts were crippled, they seem to have learned the lesson) > > There are other viable Windows compilers. If we want to support those in > CPython someone needs to contribute the work to do so, ongoing maintenance, > and buildbots. I'd love to see a Clang based Windows build (Google Chrome > is built using that). But I have no motivating reason to do the work. I > believe such a build could be made to integrate and inter-operate fully with > MSVC builds and ABIs. We could probably even make cross-compilation of > extensions from Linux -> Windows work that way. > > We're highly unlikely to ever stop shipping python.org Windows binaries > built with anything other than MSVC unless Microsoft takes a turn toward the > dark side again. I would also point out that CPython (distutils, specifically) supported mingw builds (that's the original mingw 32-bit version) for a long time. Support for that bit-rotted as the mingw project fragmented with various 64-bit versions, and slow progress from the mingw project(s) for supporting newer CRTs on Windows. No-one from the community who used mingw was providing patches back to distutils or Python, and so the support for mingw was (I believe) dropped. It sounds as if people have since then got things to a point where building extensions with (some form of ) mingw is possible, but I don't know the details, and I'm not aware of any documentation that's been contributed back to Python on how "mingw support for building extensions" works these days. We'd be more than happy to support building extensions with alternative compilers (such as one of the various gcc builds that go under the banner of "mingw") - that's a completely different matter than switching the CPython build process to use mingw - but it's down to the community of users of such a compiler to contribute that support. Expecting "someone else", and particularly someone who doesn't need it, to provide that support, is unreasonable. Disclaimer: This all comes under "as far as I know" - I did a lot of work on mingw support back when it was supported (including trying to push patches back to the mingw people) but haven't been following it for a long time. Things could be very different now than I remember. Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
