Christian Tismer stackless.com> writes:
>
> Howdy friends,
>
> according to pep 404, there will never be an official Python 2.8.
> The migration path is from 2.7 to 3.x.
>
[...]
> And if not, what do you suggest then?
Stackless Python 2.799
> It will be submitted by end of November, thanks f
Steve Dower wrote:
> The advice I've been given on FILE* is that there's probably no way to make it
> work correctly due to its internal buffering. Unfortunately, there are more
> places where this leaks through than just the APIs using them - extensions
> that
> call os.dup(fd), PyNumber_AsSsize_
Ethan Furman wrote:
[Redirecting to Python Dev]
On 11/22/2013 10:25 AM, Richard Tew wrote:
>
Yet, we're told we should adopt wacky version numbers like 10, or
rename our project from Stackless Python.
Sometimes we have to do wacky stuff to avoid unnecessary confusion.
Maybe imaginary versi
> Martin v. Löwis wrote:
> Am 22.11.13 19:10, schrieb Steve Dower:
>> I'd really want to update distutils.msvc9compiler to detect later
>> versions as well, since that would make 'pip install' work properly
>> for a large (majority?) of users for a large (majority?) of packages
>> with extension mo
On Fri, 22 Nov 2013 10:59:31 -0800
Ethan Furman wrote:
>
> > Yet, we're told we should adopt wacky version numbers like 10, or
> > rename our project from Stackless Python.
>
> Sometimes we have to do wacky stuff to avoid unnecessary confusion.
Or it can be "Stackless Python 2.7 Extended Life"
[Redirecting to Python Dev]
On 11/22/2013 10:25 AM, Richard Tew wrote:
On Sat, Nov 23, 2013 at 3:16 AM, Ethan Furman wrote:
On 11/22/2013 01:00 AM, Richard Tew wrote:
Yet, suddenly, the chance that we may release a "Stackless Python
2.8", is a concern.
Because there is no CPython 2.8 to mir
Am 22.11.13 19:10, schrieb Steve Dower:
> I'd really want to update distutils.msvc9compiler to detect later
> versions as well, since that would make 'pip install' work properly
> for a large (majority?) of users for a large (majority?) of packages
> with extension modules. Some may consider this P
Martin v. Löwis wrote:
> Am 22.11.13 01:58, schrieb Steve Dower:
>
>> I'm happy to work on a PEP and changes for what I described above, if
>> there's enough interest? I can also update distutils to detect and
>> build with any available compiler, though this may be more of a
>> feature than we'd
Am 22.11.13 17:54, schrieb Christian Tismer:
> The discussion is over, but I cannot let this comment go through without
> citing my original question, again:
>
>> My question
>> ---
>>
>> I have created a very clean Python 2.7.6+ based CPython with the
>> Stackless
>> additions, that compi
On 22/11/13 13:47, "Martin v. Löwis" wrote:
Am 22.11.13 10:00, schrieb Richard Tew:
That there are people who would consider using the trademark to force
us to change the name we've been using without harm for 14 years,
worries me. It's one thing to perhaps use it to stop someone scamming
Pytho
On Nov 22, 2013, at 03:55 PM, Antoine Pitrou wrote:
>(perhaps Barry will play a bass solo? :-))
Now, now, we don't want to give Chris incentive, do we? :)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo
On Fri, 22 Nov 2013 22:00:54 +1300
Richard Tew wrote:
>
> Was there any concern about the dozens of "Stackless Python 2.x" and
> "Stackless Python 3.x" versions that I have released over the years
> being a cause for confusion? Or more importantly, any actual problems
> experienced?
>
> Yet, su
On 11/22/2013 01:00 AM, Richard Tew wrote:
[snip]
Yet, suddenly, the chance that we may release a "Stackless Python
2.8", is a concern.
Because there is no CPython 2.8 to mirror, and we've said there will not be one.
It certainly didn't help that this was presented one week before the featur
Am 22.11.13 10:00, schrieb Richard Tew:
> That there are people who would consider using the trademark to force
> us to change the name we've been using without harm for 14 years,
> worries me. It's one thing to perhaps use it to stop someone scamming
> Python users, and another to suggest using i
On Fri, Nov 22, 2013 at 10:32 PM, Nick Coghlan wrote:
> A few folks overreacted in their concern about the community confusion
> such a move would inevitably create - *anything* called "Python 2.8"
> is going to give the impression that we've changed our mind about 2.7
> being the last feature rel
On 22 November 2013 19:00, Richard Tew wrote:
> We're not talking about releasing a Python 2.8 against anyone's wishes
> here. Or in _this specific case_, doing anything other than naming
> something in a way we've been naming it for over a decade. Yet it's
> reached the point where people are a
Am 22.11.13 01:58, schrieb Steve Dower:
> I'm happy to work on a PEP and changes for what I described above, if
> there's enough interest? I can also update distutils to detect and
> build with any available compiler, though this may be more of a
> feature than we'd want for 2.7 at this point.
I
On 22 Nov 2013 10:58, "Steve Dower" wrote:
>
> 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 larg
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
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 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
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
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
> -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
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
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~
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
>>
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
> -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
Another alternative I'd prefer to an ABI version bump: backporting the "C
runtime independence" aspects of the stable ABI to Python 2.7.
There are only a relatively small number of APIs that lead to the
requirement for consistent C runtimes, so allowing those to be excluded at
compile time would m
On 21 Nov 2013 10:33, "Antoine Pitrou" wrote:
>
> On Wed, 20 Nov 2013 17:30:44 -0500
> Barry Warsaw wrote:
> > 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 wh
On Wed, Nov 20, 2013 at 5:36 PM, Christian Tismer wrote:
> Hey Barry,
>
>
> On 20.11.13 23:30, Barry Warsaw wrote:
>>
>> 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
On 20/11/2013 23:36, Christian Tismer wrote:
Hey Barry,
On 20.11.13 23:30, Barry Warsaw wrote:
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
Yes Paul,
On 20.11.13 23:15, Paul Moore wrote:
On 20 November 2013 22:04, Christian Tismer wrote:
My question is not answered at all, sorry Joao!
I did not ask a teacher for his opinion on Stackless, but the community
about the
validity of pep 404.
I don't want a python 2.7 that does not inst
On Wed, 20 Nov 2013 17:30:44 -0500
Barry Warsaw wrote:
> 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.
On 11/20/2013 5:30 PM, Barry Warsaw wrote:
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 i
Hey Barry,
On 20.11.13 23:30, Barry Warsaw wrote:
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 conside
On Wed, Nov 20, 2013 at 12:52 PM, Christian Tismer wrote:
> according to pep 404, there will never be an official Python 2.8.
> The migration path is from 2.7 to 3.x.
>
> I agree with this strategy in almost all consequences but this one:
>
> Many customers are forced to stick with Python 2.X beca
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 not a bug fix,
>where I disa
On 20 November 2013 22:04, Christian Tismer wrote:
> My question is not answered at all, sorry Joao!
> I did not ask a teacher for his opinion on Stackless, but the community
> about the
> validity of pep 404.
>
> I don't want a python 2.7 that does not install correctly, because people
> don't re
My question is not answered at all, sorry Joao!
I did not ask a teacher for his opinion on Stackless, but the community
about the
validity of pep 404.
I don't want a python 2.7 that does not install correctly, because people
don't read instructions. And exactly that will happen if I submit a mo
I'd say publishing a high profile installable code with a "python 2.8" name
would cause a lot of undesired confusion to start with.
I usually lecture on Python to present the language to college students and
I.T. workers - and explaining away the current versioning scheme (use
either 2.7 or 3.3) i
76 matches
Mail list logo
