On Fri, Jun 06, 2014 at 12:51:11PM +1200, Greg Ewing wrote:
Steven D'Aprano wrote:
(1) I asked if it would be okay for MicroPython to *optionally* use
nominally Unicode strings limited to ASCII. Pretty much the only
response to this as been Guido saying That would be a pretty lousy
option,
On 04/06/2014 16:52, Mark Lawrence wrote:
On 04/06/2014 16:32, Steve Dower wrote:
If copying into a separate list is a problem (memory-wise),
re.finditer('\\S+', string) also provides the same behaviour and gives
me the sliced string, so there's no need to index for anything.
Out of idle
On 06.06.2014 04:18, Sturla Molden wrote:
On 05/06/14 22:51, Nathaniel Smith wrote:
This gets evaluated as:
tmp1 = a + b
tmp2 = tmp1 + c
result = tmp2 / c
All these temporaries are very expensive. Suppose that a, b, c are
arrays with N bytes each, and N is large. For simple
On 06/04/2014 05:52 PM, Mark Lawrence wrote:
On 04/06/2014 16:32, Steve Dower wrote:
If copying into a separate list is a problem (memory-wise), re.finditer('\\S+',
string) also provides the same behaviour and gives me the sliced string, so
there's no need to index for anything.
Out of
Hello,
On Thu, 5 Jun 2014 22:21:30 +1000
Tim Delaney timothy.c.dela...@gmail.com wrote:
On 5 June 2014 22:01, Paul Sokolovsky pmis...@gmail.com wrote:
All these changes are what let me dream on and speculate on
possibility that Python4 could offer an encoding-neutral string type
Hi,
I added a new BaseEventLoop.is_closed() method to Tulip and Python 3.5
to fix an issue (see Tulip issue 169 for the detail). The problem is
that I don't want to add this method to Python 3.4 because usually we
don't add new methods in minor versions of Python (future version
3.4.2 in this
Hello,
On Thu, 5 Jun 2014 22:38:13 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 5 June 2014 22:10, Stefan Krah ste...@bytereef.org wrote:
Paul Sokolovsky pmis...@gmail.com wrote:
In this regard, I'm glad to participate in mind-resetting
discussion. So, let's reiterate - there's nothing
Steven D'Aprano wrote:
I don't know about car engine controllers, but presumably they have
diagnostic ports, and they may sometimes output text. If they output
text, then at least hypothetically car mechanics in Russia might prefer
their car to output правда and ложный rather than true and
On Fri, 06 Jun 2014 11:31:23 +0200, Victor Stinner victor.stin...@gmail.com
wrote:
Hi,
I added a new BaseEventLoop.is_closed() method to Tulip and Python 3.5
to fix an issue (see Tulip issue 169 for the detail). The problem is
that I don't want to add this method to Python 3.4 because
On 6 June 2014 19:31, Victor Stinner victor.stin...@gmail.com wrote:
Guido just wrote in the issue: Actually for asyncio we have special
dispensation to push new features to minor releases (until 3.5).
Please push to 3.4 so the source code is the same everywhere (except
selectors.py, which is
Paul Sokolovsky writes:
That kinda means string is atomic, instead of your characters are
atomic.
I would be very surprised if a language that behaved that way was
called a Python subset. No indexing, no slicing, no regexps, no
.split(), no .startswith(), no sorted() or .sort(), ...!?
If
Hello,
On Thu, 5 Jun 2014 23:15:54 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 5 June 2014 22:37, Paul Sokolovsky pmis...@gmail.com wrote:
On Thu, 5 Jun 2014 22:20:04 +1000
Nick Coghlan ncogh...@gmail.com wrote:
problems caused by trusting the locale encoding to be correct, but
the
Hello,
On Fri, 06 Jun 2014 20:11:27 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Paul Sokolovsky writes:
That kinda means string is atomic, instead of your characters
are atomic.
I would be very surprised if a language that behaved that way was
called a Python subset. No
On 6 June 2014 21:15, Paul Sokolovsky pmis...@gmail.com wrote:
Hello,
On Thu, 5 Jun 2014 23:15:54 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 5 June 2014 22:37, Paul Sokolovsky pmis...@gmail.com wrote:
On Thu, 5 Jun 2014 22:20:04 +1000
Nick Coghlan ncogh...@gmail.com wrote:
On 6 June 2014 21:34, Paul Sokolovsky pmis...@gmail.com wrote:
On Fri, 06 Jun 2014 20:11:27 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Paul Sokolovsky writes:
That kinda means string is atomic, instead of your characters
are atomic.
I would be very surprised if a
Hello,
On Fri, 06 Jun 2014 09:32:25 +0100
Mark Lawrence breamore...@yahoo.co.uk wrote:
On 04/06/2014 16:52, Mark Lawrence wrote:
On 04/06/2014 16:32, Steve Dower wrote:
If copying into a separate list is a problem (memory-wise),
re.finditer('\\S+', string) also provides the same
On 06/06/2014 09:53, Hrvoje Niksic wrote:
On 06/04/2014 05:52 PM, Mark Lawrence wrote:
On 04/06/2014 16:32, Steve Dower wrote:
If copying into a separate list is a problem (memory-wise),
re.finditer('\\S+', string) also provides the same behaviour and
gives me the sliced string, so there's no
Le 06/06/2014 07:00, R. David Murray a écrit :
I don't have any opinion on the workflow.
My understanding is that part of the purpose of the provisional
designation is to allow faster evolution (read: fixing) of an API before
the library becomes non-provisional. Thus I agree with Guido here,
On Fri, 06 Jun 2014 10:05:52 -0400, Antoine Pitrou anto...@python.org wrote:
Le 06/06/2014 07:00, R. David Murray a écrit :
I don't have any opinion on the workflow.
My understanding is that part of the purpose of the provisional
designation is to allow faster evolution (read: fixing)
Hello,
On Fri, 6 Jun 2014 21:48:41 +1000
Tim Delaney timothy.c.dela...@gmail.com wrote:
On 6 June 2014 21:34, Paul Sokolovsky pmis...@gmail.com wrote:
On Fri, 06 Jun 2014 20:11:27 +0900
Stephen J. Turnbull step...@xemacs.org wrote:
Paul Sokolovsky writes:
That kinda means
On Fri, Jun 6, 2014 at 8:15 PM, Paul Sokolovsky pmis...@gmail.com wrote:
I'm sorry if I was somehow related to that, my
bringing in the formal language spec was more a rhetorical figure, a
response to people claiming O(1) requirement.
This was exactly why this whole discussion came up, though.
On 2014-06-06 10:31, Victor Stinner wrote:
Hi,
I added a new BaseEventLoop.is_closed() method to Tulip and Python
3.5 to fix an issue (see Tulip issue 169 for the detail). The problem
is that I don't want to add this method to Python 3.4 because usually
we don't add new methods in minor
Hi all
I would like to propose moving Python 3.5 to use Visual C++ 14.0 as the main
compiler. The first CTP of Visual Studio 14 was released earlier this week:
http://blogs.msdn.com/b/vcblog/archive/2014/06/03/visual-studio-14-ctp.aspx
The major feature of interest in this version of MSVC is a
On 6/6/2014 4:53 AM, Hrvoje Niksic wrote:
On 06/04/2014 05:52 PM, Mark Lawrence wrote:
Out of idle curiosity is there anything that stops MicroPython, or any
other implementation for that matter, from providing views of a string
rather than copying every time? IIRC memoryviews in CPython
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com wrote:
What this means for Python is that C extensions for Python 3.5 and later can
be built using any version of MSVC from 14.0 and later.
Oh, if only this had been available for 2.7!! Actually... this means
that 14.0 would
Julian Taylor jtaylor.deb...@googlemail.com wrote:
The problem with this approach is that it is already difficult enough to
handle memory in numpy.
I would not do this in a way that complicates memory management in NumPy. I
would just replace malloc and free with temporarily cached versions.
On Jun 6, 2014, at 11:41 AM, Steve Dower steve.do...@microsoft.com wrote:
words
+1 from me.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
On Fri, Jun 6, 2014 at 8:47 AM, MRAB re...@mrabarnett.plus.com wrote:
On 2014-06-06 10:31, Victor Stinner wrote:
Hi,
I added a new BaseEventLoop.is_closed() method to Tulip and Python
3.5 to fix an issue (see Tulip issue 169 for the detail). The problem
is that I don't want to add this
ACTIVITY SUMMARY (2014-05-30 - 2014-06-06)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open4650 (+15)
closed 28802 (+52)
total 33452 (+67)
Open issues
On Jun 06, 2014, at 04:47 PM, MRAB wrote:
Isn't this a little like when bool, True and False were added to
Python 2.2.1, a bugfix release, an act that is, I believe, now regarded
as a mistake not to be repeated?
Yes, that was a mistake, but the case under discussion is different. With
On 06/06/2014 05:59 PM, Terry Reedy wrote:
The other problem is that a small slice view of a large object keeps the
large object alive, so a view user needs to think carefully about
whether to make a copy or create a view, and later to copy views to
delete the base object. This is not for
On 6 June 2014 16:41, Steve Dower steve.do...@microsoft.com wrote:
Basically, what I am offering to do is:
* Update the files in PCBuild to work with Visual Studio 14
* Make any code changes necessary to build with VC14
* Regularly test the latest Python source with the latest MSVC builds and
On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower steve.do...@microsoft.com wrote:
Thoughts/comments/concerns?
My only concern is support for elderly versions of Windows, in
particular: XP. I seem to recall the last let's update our MSVC
version discussion dying off because of XP support. Even
Hello,
On Fri, 06 Jun 2014 11:59:31 -0400
Terry Reedy tjre...@udel.edu wrote:
[]
The other problem is that a small slice view of a large object keeps
the large object alive, so a view user needs to think carefully about
whether to make a copy or create a view, and later to copy views to
On Fri, Jun 06, 2014 at 03:41:22PM +, Steve Dower wrote:
[snip]
Speaking as a third party who aims to provide binary distributions for
recent Python releases on Windows, every new compiler introduces a
licensing and configuration headache. So I guess the questions are:
* Does the ABI
After Glyph and Alex's email about their asks for assisting in writing
Python 2/3 code, it got me thinking about where in the toolchain various
warnings and such should go in order to help direct energy to help develop
whatever future toolchain to assist in porting.
There seems to be three places
dw+python-...@hmmz.org dw+python-...@hmmz.org wrote:
* Has Python ever hit a showstopper release issue as a result of a bug
in MSVC? (I guess probably not).
Yes, a PGO issue:
http://bugs.python.org/issue15993
To be fair, in that issue I did not look if there's some undefined behavior in
On Fri, 06 Jun 2014 16:37:01 -, dw+python-...@hmmz.org wrote:
On Fri, Jun 06, 2014 at 03:41:22PM +, Steve Dower wrote:
[snip]
Speaking as a third party who aims to provide binary distributions for
recent Python releases on Windows, every new compiler introduces a
licensing and
On 6 Jun 2014 17:07, Sturla Molden sturla.mol...@gmail.com wrote:
We would in total need two mutexes, one condition variable, a pthread, and
a heap.
The proposal in my initial email requires zero pthreads, and is
substantially more effective. (Your proposal reduces only the alloc
overhead for
Stefan Krah ste...@bytereef.org wrote:
* Will VS 14 be golden prior to Python 3.5's release? It would suck to
rely on a beta compiler.. :)
This is my only concern, too. Otherwise, +1 for the switch.
One more thing: Will the SDK 64-bit tools be available for the Express
Versions?
On 06.06.2014 04:26, Greg Ewing wrote:
Nathaniel Smith wrote:
I'd be a little nervous about whether anyone has implemented, say, an
iadd with side effects such that you can tell whether a copy was made,
even if the object being copied is immediately destroyed.
I can think of at least one
On Fri, Jun 6, 2014 at 8:22 PM, Zachary Ware
zachary.ware+py...@gmail.com wrote:
On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower steve.do...@microsoft.com
wrote:
Thoughts/comments/concerns?
My only concern is support for elderly versions of Windows, in
particular: XP. I seem to recall the
dw+python-...@hmmz.org wrote:
Speaking as a third party who aims to provide binary distributions for recent
Python releases on Windows, every new compiler introduces a licensing and
configuration headache. So I guess the questions are:
* Does the ABI stability address some historical real
Stefan Krah wrote:
Stefan Krah ste...@bytereef.org wrote:
* Will VS 14 be golden prior to Python 3.5's release? It would suck to
rely on a beta compiler.. :)
This is my only concern, too. Otherwise, +1 for the switch.
One more thing: Will the SDK 64-bit tools be available for the Express
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com wrote:
What this means for Python is that C extensions for Python 3.5 and later can
be built using any version of MSVC from 14.0 and later.
Oh, if only this had been available for 2.7!! Actually...
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com wrote:
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com
wrote:
What this means for Python is that C extensions for Python 3.5 and later
can be built using any version of MSVC
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com wrote:
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com
wrote:
What this means for Python is that C
On 6/6/2014 12:37 PM, Brett Cannon wrote:
After Glyph and Alex's email about their asks for assisting in writing
Python 2/3 code, it got me thinking about where in the toolchain various
warnings and such should go in order to help direct energy to help
develop whatever future toolchain to assist
On 06.06.2014 20:25, Brian Curtin wrote:
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com
wrote:
Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower steve.do...@microsoft.com
wrote:
On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg m...@egenix.com wrote:
On 06.06.2014 20:25, Brian Curtin wrote:
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com
wrote:
Chris Angelico wrote:
On Sat,
On 06.06.2014 20:49, Brian Curtin wrote:
On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg m...@egenix.com wrote:
On 06.06.2014 20:25, Brian Curtin wrote:
On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower steve.do...@microsoft.com
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
None of the options are particularly good, but yes, I think that's an
option we have to consider. We're supporting 2.7.x for 6 more years on
a compiler that is already 6 years old.
Surely that is infinitely less desirable than
On Fri Jun 06 2014 at 2:29:13 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/6/2014 12:37 PM, Brett Cannon wrote:
After Glyph and Alex's email about their asks for assisting in writing
Python 2/3 code, it got me thinking about where in the toolchain various
warnings and such should go in
On Fri, Jun 6, 2014 at 10:56 PM, dw+python-...@hmmz.org wrote:
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
None of the options are particularly good, but yes, I think that's an
option we have to consider. We're supporting 2.7.x for 6 more years on
a compiler that is already
On Fri Jun 06 2014 at 2:59:24 PM, dw+python-...@hmmz.org wrote:
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
None of the options are particularly good, but yes, I think that's an
option we have to consider. We're supporting 2.7.x for 6 more years on
a compiler that is
On Jun 6, 2014, at 3:04 PM, Brian Curtin br...@python.org wrote:
On Fri, Jun 6, 2014 at 10:56 PM, dw+python-...@hmmz.org wrote:
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
None of the options are particularly good, but yes, I think that's an
option we have to consider.
On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft don...@stufft.io wrote:
On Jun 6, 2014, at 3:04 PM, Brian Curtin br...@python.org wrote:
On Fri, Jun 6, 2014 at 10:56 PM, dw+python-...@hmmz.org wrote:
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
None of the options are
On Jun 6, 2014, at 3:09 PM, Brian Curtin br...@python.org wrote:
On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft don...@stufft.io wrote:
On Jun 6, 2014, at 3:04 PM, Brian Curtin br...@python.org wrote:
On Fri, Jun 6, 2014 at 10:56 PM, dw+python-...@hmmz.org wrote:
On Fri, Jun 06, 2014 at
Am 06.06.14 17:41, schrieb Steve Dower:
Hi all
I would like to propose moving Python 3.5 to use Visual C++ 14.0 as
the main compiler.
This is fine with me, but I'm worried about the precise timing of doing
so. I assume that you would plan to do this moving before VC++ 14 is
actually
Am 06.06.14 19:31, schrieb Brian Curtin:
If that's a non-issue, or if we can actually drop XP support, I'm all for it.
Extended support ended in April of this year, so I think we should put
XP as unsupported for 3.5 in PEP 11 -
http://legacy.python.org/dev/peps/pep-0011/
I seem to
On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft don...@stufft.io wrote:
Is it really any difference in maintenance if you just stop applying updates
to
2.7 and switch to 2.8? If 2.8 is really just 2.7 with a new compiler then
there
should be no functional difference between doing that and
On Jun 6, 2014, at 3:33 PM, Chris Angelico ros...@gmail.com wrote:
On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft don...@stufft.io wrote:
Is it really any difference in maintenance if you just stop applying updates
to
2.7 and switch to 2.8? If 2.8 is really just 2.7 with a new compiler then
Am 06.06.14 20:25, schrieb Brian Curtin:
We're going to have to change it at some point, otherwise we're going
to have people in 2018 scrambling to find VS2008, which will be 35
versions too old by then.
Not sure whether you picked 2018 deliberately: extended support for
VS2008 Professional
On Sat, Jun 7, 2014 at 5:36 AM, Donald Stufft don...@stufft.io wrote:
Well it’d contain bug fixes and whatever other sorts of things you’d put
into a 2.7.whatever release. So they’d still want to upgrade to 2.8 since
that’ll have bug fixes.
But it's not a potentially-breaking change. For
A reminder:
https://lh5.googleusercontent.com/-d4rF0qJPskQ/U0qpNjP5GoI/PW0/4RF_7zy3esY/w1118-h629-no/Python28.jpg
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
On 6 June 2014 20:20, Martin v. Löwis mar...@v.loewis.de wrote:
2. what is the risk of installing a beta compiler on what might
otherwise be a production developer system? In particular, could
it interfere with other VS installations, and could it require a
complete system reinstall
Am 06.06.14 21:20, schrieb Martin v. Löwis:
2. what is the risk of installing a beta compiler on what might
otherwise be a production developer system? In particular, could
it interfere with other VS installations, and could it require a
complete system reinstall when the final
On Sat, Jun 07, 2014 at 05:33:45AM +1000, Chris Angelico wrote:
Is it really any difference in maintenance if you just stop applying
updates to 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a
new compiler then there should be no functional difference between
doing that and doing a
On Sat, Jun 7, 2014 at 5:42 AM, dw+python-...@hmmz.org wrote:
Perhaps a final alternative is simply continuing
the 2.7 series with a stale compiler, as a kind of carrot on a stick to
encourage users to upgrade?
More likely, what would happen is that there'd be an alternate
distribution of
Am 06.06.14 22:13, schrieb Paul Moore:
From http://www.visualstudio.com/en-us/downloads/visual-studio-14-ctp-vs
Currently, Visual Studio 14 CTPs have known compatibility issues
with previous releases of Visual Studio and should not be installed
side-by-side on the same computer.
I also
Hi.
On 6.6.2014. 21:46, Guido van Rossum wrote:
A reminder:
https://lh5.googleusercontent.com/-d4rF0qJPskQ/U0qpNjP5GoI/PW0/4RF_7zy3esY/w1118-h629-no/Python28.jpg
*ROFL*
Subtle, ain't he? *gdr*
Best regards,
Jurko Gospodnetić
On Fri, Jun 6, 2014 at 11:42 PM, dw+python-...@hmmz.org wrote:
On Sat, Jun 07, 2014 at 05:33:45AM +1000, Chris Angelico wrote:
Is it really any difference in maintenance if you just stop applying
updates to 2.7 and switch to 2.8? If 2.8 is really just 2.7 with a
new compiler then there
On 7 June 2014 00:52, Paul Sokolovsky pmis...@gmail.com wrote:
At heart, this is exactly what the Python 3 str type is. The
universal convention is code points.
Yes. Except for one small detail - Python3 specifies these code points
to be Unicode code points. And Unicode is a very bloated
Nathaniel Smith n...@pobox.com wrote:
The proposal in my initial email requires zero pthreads, and is
substantially more effective. (Your proposal reduces only the alloc
overhead for large arrays; mine reduces both alloc and memory access
overhead for boyh large and small arrays.)
My
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the hassle of doing a Python 2.8 or not giving a
clear signal as to when Python 2.x will end as a language.
Why not just define Python 2.8 as Python 2.7
Brian Curtin br...@python.org wrote:
Adding features into 3.x is already not enough of a carrot on the
stick for many users. Intentionally leaving 2.7 on a dead compiler is
like beating them with the stick.
Those who want to build extensions on Windows will just use MinGW
(currently GCC
Martin v. Löwis wrote:
Am 06.06.14 22:13, schrieb Paul Moore:
From
http://www.visualstudio.com/en-us/downloads/visual-studio-14-ctp-vs
Currently, Visual Studio 14 CTPs have known compatibility issues
with previous releases of Visual Studio and should not be installed
side-by-side on the
On Jun 6, 2014 6:01 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brian Curtin br...@python.org wrote:
Adding features into 3.x is already not enough of a carrot on the
stick for many users. Intentionally leaving 2.7 on a dead compiler is
like beating them with the stick.
Those who
Brian Curtin br...@python.org wrote:
Well we're certainly not going to assume such a thing. I know people do
that, but many don't (I never have).
If Python 2.7 users are left with a dead compiler on Windows, they will
find a solution. For example, Enthought is already bundling their Python
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the hassle of doing a Python 2.8 or not giving a
clear signal as to when Python
On Fri, Jun 6, 2014 at 4:32 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Brian Curtin br...@python.org wrote:
Well we're certainly not going to assume such a thing. I know people do
that, but many don't (I never have).
If Python 2.7 users are left with a dead compiler on Windows, they
On Fri, Jun 6, 2014 at 11:33 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Nathaniel Smith n...@pobox.com wrote:
The proposal in my initial email requires zero pthreads, and is
substantially more effective. (Your proposal reduces only the alloc
overhead for large arrays; mine reduces both
Eli Bendersky eli...@gmail.com wrote:
While we're at it, Clang in nearing a stage where it can compile C and C++
on Windows *with ABI-compatibility to MSVC* (yes, even C++) -- see
a
href=http://clang.llvm.org/docs/MSVCCompatibility.html;http://clang.llvm.org/docs/MSVCCompatibility.html/a
for
Julian Taylor wrote:
tp_can_elide receives two objects and returns one of three values:
* can work inplace, operation is associative
* can work inplace but not associative
* cannot work inplace
Does it really need to be that complicated? Isn't it
sufficient just to ask the object potentially
On 7 Jun 2014 00:53, Paul Sokolovsky pmis...@gmail.com wrote:
Yes. Except for one small detail - Python3 specifies these code points
to be Unicode code points. And Unicode is a very bloated thing.
I rather suspect users of East Asian African scripts might have a
different notion of what
On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the hassle of doing a Python 2.8 or
On Jun 6, 2014 6:33 PM, Sturla Molden sturla.mol...@gmail.com wrote:
Brian Curtin br...@python.org wrote:
Well we're certainly not going to assume such a thing. I know people do
that, but many don't (I never have).
If Python 2.7 users are left with a dead compiler on Windows, they will
On Jun 6, 2014, at 9:05 PM, Terry Reedy tjre...@udel.edu wrote:
On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden sturla.mol...@gmail.com
wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking
Brian Curtin br...@python.org wrote:
If Python 2.7 users are left with a dead compiler on Windows, they will
find a solution. For example, Enthought is already bundling their Python
distribution with gcc 2.8.1 on Windows.
Again, not something I think we should depend on. A lot of people use
Greg Ewing greg.ew...@canterbury.ac.nz wrote:
Julian Taylor wrote:
tp_can_elide receives two objects and returns one of three values:
* can work inplace, operation is associative
* can work inplace but not associative
* cannot work inplace
Does it really need to be that complicated? Isn't
Nathaniel Smith n...@pobox.com wrote:
with numpy.accelerate:
x = expression
y = expression
z = expression
# evaluation of x,y,z happens here
Using an alternative evaluation engine is indeed another way to
optimize execution, which is why projects like numexpr, numba, theano,
On 6/6/2014 9:13 PM, Donald Stufft wrote:
On Jun 6, 2014, at 9:05 PM, Terry Reedy tjre...@udel.edu wrote:
If you are suggesting that a Windows compiler change should be
invisible to non-Windows users, I agree.
Let us assume that /pcbuild remains for those who have vc2008 and
that /pcbuild14
Why not just define Python 2.8 as Python 2.7 except with a newer compiler?
I cannot see why that would be massive undertaking, if changing compiler
for 2.7 is neccesary anyway.
A reminder that this was brought up a few months ago, as a proposal by the
stackless team, as they wanted to use a
On 7 June 2014 08:43, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the hassle of doing a Python 2.8 or not giving a
clear signal as to when Python 2.x will
On Jun 7, 2014, at 12:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 7 June 2014 08:43, Sturla Molden sturla.mol...@gmail.com wrote:
Brett Cannon bcan...@gmail.com wrote:
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the hassle of doing
On 7 June 2014 14:01, Chris Barker chris.bar...@noaa.gov wrote:
Why not just define Python 2.8 as Python 2.7 except with a newer compiler?
I cannot see why that would be massive undertaking, if changing compiler
for 2.7 is neccesary anyway.
A reminder that this was brought up a few months
On 7 June 2014 14:47, Donald Stufft don...@stufft.io wrote:
On Jun 7, 2014, at 12:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
Words like just, or simple, or easy really have no place being
applied to a task where the time required to fully execute it with *no
significant problems* is still
On Jun 7, 2014, at 12:58 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 7 June 2014 14:47, Donald Stufft don...@stufft.io wrote:
On Jun 7, 2014, at 12:41 AM, Nick Coghlan ncogh...@gmail.com wrote:
Words like just, or simple, or easy really have no place being
applied to a task where the
On 7 June 2014 15:05, Donald Stufft don...@stufft.io wrote:
I don’t particularly care too much though, I just think that bumping
the compiler in a 2.7.Z release is a really bad idea and that either
of the other two options are massively better.
It is *incredibly* unlikely that backwards
On 7 June 2014 01:41, Steve Dower steve.do...@microsoft.com wrote:
What this means for Python is that C extensions for Python 3.5 and later can
be built using any version of MSVC from 14.0 and later. Those who are aware
of the current state of affairs where you need to use a matching
100 matches
Mail list logo
