-Original Message-
From: Python-Dev [mailto:python-dev-
bounces+kristjan=ccpgames@python.org] On Behalf Of Christian Tismer
Sent: 20. nóvember 2013 23:37
To: Barry Warsaw; python-dev@python.org
Subject: Re: [Python-Dev] PEP 0404 and VS 2010
Hey Barry,
In any case, my
Hi,
First, in case such project already exists, could someone point me towards this?
It occurs to me that in some cases may be possible to run exhaustive
test on user-implemented synchronisation code.
let's say, in a simple case, we've got a 2 threads, some user code
using threading.*
Quoting Barry Warsaw ba...@python.org:
On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:
Many customers are forced to stick with Python 2.X because of other
products,
but they require a Python 2.X version which can be compiled using Visual
Studio 2010 or better. This is considered an
Quoting Nick Coghlan ncogh...@gmail.com:
Another alternative I'd prefer to an ABI version bump: backporting the C
runtime independence aspects of the stable ABI to Python 2.7.
That sounds doable. If we provided a python2.dll, would could make the
header files using the restricted API by
On 21 November 2013 11:15, mar...@v.loewis.de wrote:
Whether this would be a good idea or not, I don't know. It would create
separate ecosystems for different releases of Python 2.7 for different
CRTs. Package authors would have to create multiple binary releases of
the same modules for
On Thu, 21 Nov 2013 09:19:27 +
Kristján Valur Jónsson krist...@ccpgames.com wrote:
For reasons of work and others, I never got round to creating that branch but
recently Stackless development has picked up the pace to the point where we
feel it necessary to break with strict 2.7
-Original Message-
From: Python-Dev [mailto:python-dev-
bounces+kristjan=ccpgames@python.org] On Behalf Of Antoine Pitrou
Sent: 21. nóvember 2013 12:06
To: python-dev@python.org
Subject: Re: [Python-Dev] PEP 0404 and VS 2010
On Thu, 21 Nov 2013 09:19:27 +
Kristján Valur
2013/11/21 Charles-François Natali cf.nat...@gmail.com:
I'm happy to officially accept PEP 454 aka tracemalloc.
The API has substantially improved over the past weeks, and is now
both easy to use and suitable as a fundation for high-level tools for
memory-profiling.
Thanks to Victor for his
Quoting Greg Ewing greg.ew...@canterbury.ac.nz:
Concerning the version number, I thought the intention of
PEP 404 was simply to say that the PSF would not be releasing
anything called Python 2.8, not to forbid anyone *else*
from doing so.
Or am I wrong about that?
That's correct.
If I'm
On 21 November 2013 21:02, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Is that much different from package authors having to
release binaries for different versions of Python,
if they want to support older versions?
Having multiple binaries for the same x.y version
is different from what's
On Thu, 21 Nov 2013 12:36:48 +
Kristján Valur Jónsson krist...@ccpgames.com wrote:
Yes, we have stackless 3.3
But there is desire to have a 2.X version, with added fixes from 3.x, e.g.
certain improvements in the
standard library etc.
It's the old argument: moving to 3.x is not an
On 22 Nov 2013 07:43, Charles-François Natali cf.nat...@gmail.com wrote:
Hi,
I'm happy to officially accept PEP 454 aka tracemalloc.
The API has substantially improved over the past weeks, and is now
both easy to use and suitable as a fundation for high-level tools for
memory-profiling.
On Thu, Nov 21, 2013 at 4:12 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 21 November 2013 21:02, Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Is that much different from package authors having to
release binaries for different versions of Python,
if they want to support older versions?
On Thu, Nov 21, 2013 at 1:32 PM, Christian Tismer tis...@stackless.comwrote:
I am converted to an OS X developer since 2006, but never had ABI
problems,
because I use homebrew,
Right, different story -- you are supposed to compile everything on the
target system, so everything stays
Am 21.11.2013 16:12, schrieb Barry Warsaw:
On Nov 21, 2013, at 02:16 PM, Kristján Valur Jónsson wrote:
Oh, this is the misunderstanding. No one is trying to get permission for
CPython 2.8, only Stackless Python 2.8.
I think this is a very bad idea. We've worked hard to send the message
On 11/21/2013 10:53 AM, Christian Tismer wrote:
So even if VS2010 exists only in the stackless branch, it is very likely
to get used as CPython VS 2010, and I again have the naming problem ...
What's wrong with calling it CPython VS 2010? And Stackless VS 2010?
--
~Ethan~
Am 21.11.2013 18:57, schrieb Tim Peters:
Best to change the failing tests. For example, _they_ can sort the
dict keys if they rely on a fixed order. Sorting in general is a
dubious idea because it can be a major expense with no real benefit
for most uses.
I don't consider repr() as a
On 22 Nov 2013 02:03, Chris Barker - NOAA Federal chris.bar...@noaa.gov
wrote:
with older releases (I admit I don't understand the ABI compatibility on
OSX).
Well, with OS-X, it's not exactly the C lic in the same way, but there
are different SDKs for different OS versions, and you can add
2013/11/21 Nick Coghlan ncogh...@gmail.com:
Huzzah! Thanks to you both for getting this ready for inclusion :)
I now hope that someone will use it :-)
By the way, collections.namedtuple has a private _source attribute.
This attributes uses something like 676.2 kB in the Python test suite,
it
On 21 November 2013 21:27, Chris Barker chris.bar...@noaa.gov wrote:
That's already the unstated case. But besides stackless, it some of us are
advocating that there be python.org-provided binaries built with a newer
compiler (eventually, anyway).
I see no problem with python.org producing and
On 11/21/2013 12:23 PM, Christian Tismer wrote:
Maybe I would generate a cpython and spython exe and support them
both in the same distribution?
That sounds cool, if possible.
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Nov 21, 2013 at 1:09 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Concerning the version number, I thought the intention of
PEP 404 was simply to say that the PSF would not be releasing
anything called Python 2.8, not to forbid anyone *else*
from doing so.
Or am I wrong about
On 22 Nov 2013 09:02, Victor Stinner victor.stin...@gmail.com wrote:
2013/11/21 Nick Coghlan ncogh...@gmail.com:
Huzzah! Thanks to you both for getting this ready for inclusion :)
I now hope that someone will use it :-)
By the way, collections.namedtuple has a private _source attribute.
On 21/11/13 19:59, Ethan Furman wrote:
On 11/21/2013 10:53 AM, Christian Tismer wrote:
So even if VS2010 exists only in the stackless branch, it is very likely
to get used as CPython VS 2010, and I again have the naming problem ...
What's wrong with calling it CPython VS 2010? And Stackless
[Christian Heimes]
the buildbots are flaky because two repr() tests for userdict and
functools.partial fail every now and then. The test cases depend on a
fixed order of keyword arguments the representation of userdict and
partial instances. The improved hash randomization of PEP 456 shows its
On 11/21/2013 5:13 PM, mar...@v.loewis.de wrote:
Quoting Greg Ewing greg.ew...@canterbury.ac.nz:
Concerning the version number, I thought the intention of
PEP 404 was simply to say that the PSF would not be releasing
anything called Python 2.8, not to forbid anyone *else*
from doing so.
Or
On Wed, Nov 20, 2013 at 5:41 PM, Mark Lawrence breamore...@yahoo.co.ukwrote:
On 20/11/2013 22:01, Antoine Pitrou wrote:
pathlib imports many modules at startup, so for scripts for which
startup time is critical using os.path may still be the best option.
Will there be or is there a note
On Nov 21, 2013, at 06:36 PM, Terry Reedy wrote:
As usual, 'I am not a lawyer', but if Christian wants to push forward with
using 'Python 2.8', I suggest that he consult the PSF Trademark Committee and
lawyer first.
Just to make clear, I'm definitely *not* suggesting this particular case ever
On Thu, 21 Nov 2013 18:43:37 -0500
Barry Warsaw ba...@python.org wrote:
On Nov 21, 2013, at 06:36 PM, Terry Reedy wrote:
As usual, 'I am not a lawyer', but if Christian wants to push forward with
using 'Python 2.8', I suggest that he consult the PSF Trademark Committee and
lawyer first.
Nick Coghlan wrote:
On 21 Nov 2013 10:33, Antoine Pitrou solip...@pitrou.net wrote:
I think it isn't only about teaching it to build with VS 2010, but
providing binaries compatible with the VS 2010 runtime.
Otherwise, AFAIU, if extensions are built with VS 2010 but loader with
a VS
+1 on unsorted repr(). It makes it obvious that the collection is not sorted.
On Thu, Nov 21, 2013 at 1:10 PM, Christian Heimes christ...@python.org wrote:
Am 21.11.2013 18:57, schrieb Tim Peters:
Best to change the failing tests. For example, _they_ can sort the
dict keys if they rely on a
On 22.11.13 00:53, Antoine Pitrou wrote:
On Thu, 21 Nov 2013 18:43:37 -0500
Barry Warsaw ba...@python.org wrote:
On Nov 21, 2013, at 06:36 PM, Terry Reedy wrote:
As usual, 'I am not a lawyer', but if Christian wants to push forward with
using 'Python 2.8', I suggest that he consult the PSF
On Nov 21, 2013, at 02:16 PM, Kristján Valur Jónsson wrote:
Oh, this is the misunderstanding. No one is trying to get permission for
CPython 2.8, only Stackless Python 2.8.
I think this is a very bad idea. We've worked hard to send the message that
the migration path is to Python 3 and while I
On Fri, 22 Nov 2013 09:17:14 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Skipping saving _source under -OO would probably be a good thing, but
otherwise it's a public API with the usual backwards compatibility
guarantees.
I think skipping saving _source under -OO should be a bugfix. It's
On Thu, Nov 21, 2013 at 4:17 PM, Nick Coghlan ncogh...@gmail.com wrote:
Skipping saving _source under -OO would probably be a good thing, but
otherwise it's a public API with the usual backwards compatibility
guarantees.
One alternative might be to make it a property that re-generates the
On 21 November 2013 22:51, Christian Heimes christ...@python.org wrote:
Am 21.11.2013 12:31, schrieb mar...@v.loewis.de:
That sounds doable. If we provided a python2.dll, would could make the
header files using the restricted API by default if Python is compiled
with VS 2010. Extension
On 22 November 2013 00:16, Kristján Valur Jónsson krist...@ccpgames.com wrote:
For Stackless, neither argument applies because 2.8 work would be done
by us and stackless has no particular allegiance towards either version.
Stackless can release their own Stackless 2.8 if they want, but I
Hum, I don't think that regex module will enter Python 3.4 before this
week-end, there is no PEP.
For the Introspection information for builtins, I think the PEP 436
has been accepted. The code has been merged, but the PEP status is
still draft.
Victor
2013/11/22 barry.warsaw
Hi,
I'm happy to officially accept PEP 454 aka tracemalloc.
The API has substantially improved over the past weeks, and is now
both easy to use and suitable as a fundation for high-level tools for
memory-profiling.
Thanks to Victor for his work!
Charles-François
Am 21.11.2013 12:31, schrieb mar...@v.loewis.de:
That sounds doable. If we provided a python2.dll, would could make the
header files using the restricted API by default if Python is compiled
with VS 2010. Extension builders could then regularly compile their
extensions with VS 2010, or VS
mar...@v.loewis.de wrote:
Package authors would have to create multiple binary releases of
the same modules for Windows, and upload them to PyPI. pip would have
to learn to download the right one, depending on what build of Python
2.7 is running.
Is that much different from package authors
Nick Coghlan wrote:
For 2.7.7, I think some combination of the two following ideas would be worth
pursuing:
- a C runtime independent API flag (set by default on Windows when building
with
a compiler other than VS2008). This would largely be a backport of some of the
stable ABI work from
On 21 November 2013 21:31, mar...@v.loewis.de wrote:
Quoting Nick Coghlan ncogh...@gmail.com:
Another alternative I'd prefer to an ABI version bump: backporting the C
runtime independence aspects of the stable ABI to Python 2.7.
P.S. Thinking about this, there are some issues. The
For Stackless, neither argument applies because 2.8 work would be done
by us and stackless has no particular allegiance towards either version.
Stackless can release their own Stackless 2.8 if they want, but I don't get
why
CPython would have a 2.8 too.
Oh, this is the
On 21/11/13 22:13, Glenn Linderman wrote:
On 11/21/2013 12:23 PM, Christian Tismer wrote:
Maybe I would generate a cpython and spython exe and support them
both in the same distribution?
That sounds cool, if possible.
Hooka Hooka!
Let's see if the nightmares agree :-)
--
Christian Tismer
Quoting Christian Tismer tis...@stackless.com:
Can I rely on PEP 404 that the Python 2.8 namespace never will clash
with CPython?
This question still hasn't been answered (AFAICT). So let me try to answer
it, and apologies upfront for being picky.
First, I don't understand the question:
On Thu, Nov 21, 2013 at 10:53 AM, Christian Tismer tis...@stackless.comwrote:
I also think having a 2.8 out there that is exactly the same as 2.7,
except that it was built with a different version of a compiler on one
particular platform is a very very bad idea.
This was not my proposal. I
On Thu, Nov 21, 2013 at 4:09 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
Concerning the version number, I thought the intention of
PEP 404 was simply to say that the PSF would not be releasing
anything called Python 2.8, not to forbid anyone *else*
from doing so.
Or am I wrong about
Kristján Valur Jónsson wrote:
The namespace question from Christian has to do with a python28.dll which
would be
built using VS2010, that this would never clash with a CPython version built the
same way.
However, it *would* clash with someone else who did the same
thing, e.g. Fred Bloggs
On Nov 22, 2013, at 02:04 AM, Victor Stinner wrote:
Hum, I don't think that regex module will enter Python 3.4 before this
week-end, there is no PEP.
Okay thanks, I'll remove this from PEP 429.
For the Introspection information for builtins, I think the PEP 436
has been accepted. The code has
On 21/11/13 20:46, Chris Barker wrote:
well, as you said below, you want to keep binary compatibility between
stackless and cPython, right down to the same dll name, so yes, it is
about Python. And since we are talking about it -- it actually would
be nice to be able to have a builds of python
Quoting Christian Heimes christ...@python.org:
What about the CAPI functions like PyFile_FromFile() and PyFile_AsFile()
that take a FILE* as argument?
They are unable in the stable ABI, and would be unavailable in
py27compat.dll. Modules using them would have to be rewritten to not
use them
Hi,
the buildbots are flaky because two repr() tests for userdict and
functools.partial fail every now and then. The test cases depend on a
fixed order of keyword arguments the representation of userdict and
partial instances. The improved hash randomization of PEP 456 shows its
power. I haven't
On Thu, Nov 21, 2013 at 1:02 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote:
mar...@v.loewis.de wrote:
Package authors would have to create multiple binary releases of
the same modules for Windows, and upload them to PyPI. pip would have
to learn to download the right one, depending on what
with older releases (I admit I don't understand the ABI compatibility on
OSX).
Well, with OS-X, it's not exactly the C lic in the same way, but there are
different SDKs for different OS versions, and you can add to that PPC vs
Intel processors and 32 vs 64 bit.
So we have for years had two
On Thu, Nov 21, 2013 at 10:31 AM, Christian Heimes christ...@python.orgwrote:
Am 21.11.2013 16:12, schrieb Barry Warsaw:
On Nov 21, 2013, at 02:16 PM, Kristján Valur Jónsson wrote:
Oh, this is the misunderstanding. No one is trying to get permission
for
CPython 2.8, only Stackless
On Thu, Nov 21, 2013 at 1:12 PM, Paul Moore p.f.mo...@gmail.com wrote:
None of the currently available binary distribution formats
distinguish Windows binaries by anything other than minor version. For
wheels (and I think eggs), this is a showstopper as the name is
essential metadata
Correct.
On Nov 21, 2013 10:15 AM, Daniel Holth dho...@gmail.com wrote:
+1 on unsorted repr(). It makes it obvious that the collection is not
sorted.
On Thu, Nov 21, 2013 at 1:10 PM, Christian Heimes christ...@python.org
wrote:
Am 21.11.2013 18:57, schrieb Tim Peters:
Best to change the
On 22 Nov 2013 04:12, Christian Heimes christ...@python.org wrote:
Am 21.11.2013 18:57, schrieb Tim Peters:
Best to change the failing tests. For example, _they_ can sort the
dict keys if they rely on a fixed order. Sorting in general is a
dubious idea because it can be a major expense
...
I also think having a 2.8 out there that is exactly the same as 2.7,
except that it was built with a different version of a compiler on one
particular platform is a very very bad idea.
This was not my proposal. I was seeking a way to make a version that
produces no collisions with
Concerning the version number, I thought the intention of
PEP 404 was simply to say that the PSF would not be releasing
anything called Python 2.8, not to forbid anyone *else*
from doing so.
Or am I wrong about that?
If I'm right, there's nothing stopping Christian from
releasing Stackless
On Thu, Nov 21, 2013 at 2:53 PM, Nick Coghlan ncogh...@gmail.com wrote:
For 2.7.7, I think some combination of the two following ideas would be
worth pursuing:
- a C runtime independent API flag (set by default on Windows when
building with a compiler other than VS2008). This would largely
62 matches
Mail list logo
