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
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 fr
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 :
> http://hg.pyt
On Thu, Nov 21, 2013 at 4:17 PM, Nick Coghlan 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
source (you just nee
On Fri, 22 Nov 2013 09:17:14 +1000
Nick Coghlan 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
terribly weird an
On Thu, Nov 21, 2013 at 2:53 PM, 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
On 22.11.13 00:53, Antoine Pitrou wrote:
On Thu, 21 Nov 2013 18:43:37 -0500
Barry Warsaw 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 Committe
On Thu, 21 Nov 2013 18:43:37 -0500
Barry Warsaw 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.
>
> Just to
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 11/21/2013 5:13 PM, mar...@v.loewis.de wrote:
Quoting Greg Ewing :
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
On 22 Nov 2013 09:02, "Victor Stinner" wrote:
>
> 2013/11/21 Nick Coghlan :
> > 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
On 21 November 2013 21:27, Chris Barker 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 distributing a
VS2
2013/11/21 Nick Coghlan :
> 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 the 5th biggest use
On 22 Nov 2013 02:03, "Chris Barker - NOAA Federal"
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 to that PPC
On Thu, Nov 21, 2013 at 1:32 PM, Christian Tismer wrote:
> 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 compatible.
but instead
On 22 Nov 2013 07:43, "Charles-François Natali" 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.
>
> Thanks to
On 22 Nov 2013 04:12, "Christian Heimes" 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 with no real
Quoting Greg Ewing :
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 right, there's nothing stoppi
2013/11/21 Charles-François Natali :
> 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!
Thanks
> -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á
On Thu, Nov 21, 2013 at 1:02 PM, Greg Ewing wrote:
> 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
>>
On Thu, Nov 21, 2013 at 4:09 PM, Greg Ewing wrote:
> 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?
>
Well, it's esse
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
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
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
On Thu, Nov 21, 2013 at 4:12 PM, Paul Moore wrote:
> On 21 November 2013 21:02, Greg Ewing 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
Nick Coghlan wrote:
> On 21 Nov 2013 10:33, "Antoine Pitrou" 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 2008-compiled Pytho
On Thu, Nov 21, 2013 at 1:12 PM, Paul Moore 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 (compatibility tags) fo
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 r
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 build
On Thu, Nov 21, 2013 at 1:09 PM, Greg Ewing wrote:
> 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,
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
https://mail.python.org/m
On 21 November 2013 21:02, Greg Ewing 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 been done before, but
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 Pytho
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 havi
Quoting Christian Heimes :
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 anymore, or continue
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
On Thu, 21 Nov 2013 12:36:48 +
Kristján Valur Jónsson 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 option for some users,
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 V
On Thu, Nov 21, 2013 at 10:53 AM, Christian Tismer wrote:
> 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
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~
On Wed, Nov 20, 2013 at 5:41 PM, Mark Lawrence wrote:
> 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 to this effe
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 s
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 th
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 wh
...
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 DLLs,
On 21 November 2013 21:31, wrote:
>
> Quoting Nick Coghlan :
>
>> 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 "restricted API"
> hides the objec
Quoting Christian Tismer :
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: What is the "Python 2.
On Thu, Nov 21, 2013 at 10:31 AM, Christian Heimes wrote:
> 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
On 21 November 2013 22:51, Christian Heimes 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 builders could th
> > 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 misunders
On 22 November 2013 00:16, Kristján Valur Jónsson 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 don't get
>>
Correct.
On Nov 21, 2013 10:15 AM, "Daniel Holth" 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
> wrote:
> > Am 21.11.2013 18:57, schrieb Tim Peters:
> >> Best to change the failing tests. For examp
+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 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. Sor
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 per
[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
On Thu, 21 Nov 2013 09:19:27 +
Kristján Valur Jónsson 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 conformance.
Why is that?
On 21 November 2013 11:15, 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 Windows, and upload
Quoting Nick Coghlan :
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 default if Python
Quoting Barry Warsaw :
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 improvement and n
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.* primitives
> -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,
62 matches
Mail list logo
