Brian Curtin writes:
> 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.
No, it's like a New Year's resolution to stop self-flagellating, and
handing the whip to the user
On 7 June 2014 01:41, Steve Dower 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 compiler
> will hopefully se
On 7 June 2014 15:05, Donald Stufft 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 compatibility with b
On Jun 7, 2014, at 12:58 AM, Nick Coghlan wrote:
> On 7 June 2014 14:47, Donald Stufft wrote:
>> On Jun 7, 2014, at 12:41 AM, Nick Coghlan 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
On 7 June 2014 14:47, Donald Stufft wrote:
> On Jun 7, 2014, at 12:41 AM, Nick Coghlan 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 measured in years.
>
On 7 June 2014 14:01, Chris Barker 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 ago, as a pr
On Jun 7, 2014, at 12:41 AM, Nick Coghlan wrote:
> On 7 June 2014 08:43, Sturla Molden wrote:
>> Brett Cannon 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 a
On 7 June 2014 08:43, Sturla Molden wrote:
> Brett Cannon 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 jus
>
>
> 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
On 6/6/2014 9:13 PM, Donald Stufft wrote:
On Jun 6, 2014, at 9:05 PM, Terry Reedy 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 is added (and ev
Nathaniel Smith wrote:
>> with numpy.accelerate:
>> x =
>> y =
>> z =
>> # 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,
> etc. exist. But this is basica
Greg Ewing 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 it
> sufficient j
Brian Curtin 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
> python
On Jun 6, 2014, at 9:05 PM, Terry Reedy wrote:
> On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
>> On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden
>> wrote:
>>> Brett Cannon wrote:
>>>
Nope. A new minor release of Python is a massive undertaking which is why
we have saved ourselves the
On Jun 6, 2014 6:33 PM, "Sturla Molden" wrote:
>
> Brian Curtin 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,
On 6/6/2014 6:47 PM, Nathaniel Smith wrote:
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden wrote:
Brett Cannon 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 Pyt
On 7 Jun 2014 00:53, "Paul Sokolovsky" 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 constitutes "bloa
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 be
Eli Bendersky 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
> href="http://clang.llvm.org/docs/MSVCCompatibility.html";>http://clang.llvm.org/docs/MSVCCompatibility.html
> for more details.
On Fri, Jun 6, 2014 at 4:32 PM, Sturla Molden
wrote:
> Brian Curtin 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 exa
On Fri, Jun 6, 2014 at 11:33 PM, Sturla Molden wrote:
> Nathaniel Smith 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
>> ove
On Fri, Jun 6, 2014 at 11:43 PM, Sturla Molden wrote:
> Brett Cannon 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.
>
>
Brian Curtin 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
distribution with
On Jun 6, 2014 6:01 PM, "Sturla Molden" wrote:
>
> Brian Curtin 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
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
>> si
Brian Curtin 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 2.8.2) instead.
N
Brett Cannon 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 except with a newer
Nathaniel Smith 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 suggestion prevent
On 7 June 2014 00:52, Paul Sokolovsky 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 thing.
>
On Fri, Jun 6, 2014 at 11:42 PM, 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 should be no f
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ć
_
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.
On Sat, Jun 7, 2014 at 5:42 AM, 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 Python 2.7 (eg ActiveSt
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
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 6 June 2014 20:20, "Martin v. Löwis" 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 when the fin
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
https://mail.python.org/mailman/listinf
On Sat, Jun 7, 2014 at 5:36 AM, Donald Stufft 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 example, on Debian
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 Jun 6, 2014, at 3:33 PM, Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft 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
On Sat, Jun 7, 2014 at 5:11 AM, Donald Stufft 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 2.7.wha
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
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 relea
On Jun 6, 2014, at 3:09 PM, Brian Curtin wrote:
> On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft wrote:
>>
>> On Jun 6, 2014, at 3:04 PM, Brian Curtin wrote:
>>
>>> On Fri, Jun 6, 2014 at 10:56 PM, wrote:
On Fri, Jun 06, 2014 at 10:49:24PM +0400, Brian Curtin wrote:
> None o
On Fri, Jun 6, 2014 at 11:08 PM, Donald Stufft wrote:
>
> On Jun 6, 2014, at 3:04 PM, Brian Curtin wrote:
>
>> On Fri, Jun 6, 2014 at 10:56 PM, 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
On Jun 6, 2014, at 3:04 PM, Brian Curtin wrote:
> On Fri, Jun 6, 2014 at 10:56 PM, 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
On Fri Jun 06 2014 at 2:59:24 PM, 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 6 years ol
On Fri, Jun 6, 2014 at 10:56 PM, 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 6 years old.
>
On Fri Jun 06 2014 at 2:29:13 PM, Terry Reedy 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 order to help
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 si
On 06.06.2014 20:49, Brian Curtin wrote:
> On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg wrote:
>> On 06.06.2014 20:25, Brian Curtin wrote:
>>> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote:
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower
wrote:
> Chris Angelico wrote:
>>
On Fri, Jun 6, 2014 at 10:41 PM, M.-A. Lemburg wrote:
> On 06.06.2014 20:25, Brian Curtin wrote:
>> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote:
>>> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower
>>> wrote:
Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower
>>
On 06.06.2014 20:25, Brian Curtin wrote:
> On Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote:
>> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower
>> wrote:
>>> Chris Angelico wrote:
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower
wrote:
> What this means for Python is that C extension
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 Fri, Jun 6, 2014 at 10:19 PM, Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower wrote:
>> Chris Angelico wrote:
>>> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower
>>> wrote:
What this means for Python is that C extensions for Python 3.5 and later
can be built using
On Sat, Jun 7, 2014 at 4:12 AM, Steve Dower wrote:
> Chris Angelico wrote:
>> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower
>> 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
Chris Angelico wrote:
> On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower 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
Stefan Krah wrote:
>Stefan Krah 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
>Vers
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 rea
On Fri, Jun 6, 2014 at 8:22 PM, Zachary Ware
wrote:
> On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower
> 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
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 l
Stefan Krah 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?
Stefan Krah
_
On 6 Jun 2014 17:07, "Sturla Molden" 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 large arrays; mine re
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
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
longobject.c.
> * Wil
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
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 stabi
Hello,
On Fri, 06 Jun 2014 11:59:31 -0400
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 bas
On Fri, Jun 6, 2014 at 10:41 AM, Steve Dower 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 though MS
has abandoned it,
On 6 June 2014 16:41, Steve Dower 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
> report issues/s
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 beginne
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
True/Fa
On Fri, Jun 6, 2014 at 8:47 AM, MRAB 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 method to Python
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 wit
On Jun 6, 2014, at 11:41 AM, Steve Dower 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
__
Julian Taylor 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. From
the perspective of NumP
On Sat, Jun 7, 2014 at 1:41 AM, Steve Dower 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 be a good target for 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 rely
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
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 versions
On Fri, Jun 6, 2014 at 8:15 PM, Paul Sokolovsky 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. We were
debati
Hello,
On Fri, 6 Jun 2014 21:48:41 +1000
Tim Delaney wrote:
> On 6 June 2014 21:34, Paul Sokolovsky wrote:
>
> >
> > On Fri, 06 Jun 2014 20:11:27 +0900
> > "Stephen J. Turnbull" wrote:
> >
> > > Paul Sokolovsky writes:
> > >
> > > > That kinda means "string is atomic", instead of your
> > >
On Fri, 06 Jun 2014 10:05:52 -0400, Antoine Pitrou 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) of an
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 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
Hello,
On Fri, 06 Jun 2014 09:32:25 +0100
Mark Lawrence 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 behaviour and
> >>
On 6 June 2014 21:34, Paul Sokolovsky wrote:
>
> On Fri, 06 Jun 2014 20:11:27 +0900
> "Stephen J. Turnbull" 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 be
On 6 June 2014 21:15, Paul Sokolovsky wrote:
> Hello,
>
> On Thu, 5 Jun 2014 23:15:54 +1000
> Nick Coghlan wrote:
>
>> On 5 June 2014 22:37, Paul Sokolovsky wrote:
>> > On Thu, 5 Jun 2014 22:20:04 +1000
>> > Nick Coghlan wrote:
>> >> problems caused by trusting the locale encoding to be correct
Hello,
On Fri, 06 Jun 2014 20:11:27 +0900
"Stephen J. Turnbull" 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 index
Hello,
On Thu, 5 Jun 2014 23:15:54 +1000
Nick Coghlan wrote:
> On 5 June 2014 22:37, Paul Sokolovsky wrote:
> > On Thu, 5 Jun 2014 22:20:04 +1000
> > Nick Coghlan wrote:
> >> problems caused by trusting the locale encoding to be correct, but
> >> the startup code will need non-trivial changes
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(), ...!
On 6 June 2014 19:31, Victor Stinner 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 not covered by the
On Fri, 06 Jun 2014 11:31:23 +0200, 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 ne
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" an
Hello,
On Thu, 5 Jun 2014 22:38:13 +1000
Nick Coghlan wrote:
> On 5 June 2014 22:10, Stefan Krah wrote:
> > Paul Sokolovsky wrote:
> >> In this regard, I'm glad to participate in mind-resetting
> >> discussion. So, let's reiterate - there's nothing like "the best",
> >> "the only right", "the
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 case
Hello,
On Thu, 5 Jun 2014 22:21:30 +1000
Tim Delaney wrote:
> On 5 June 2014 22:01, Paul Sokolovsky wrote:
>
> >
> > All these changes are what let me dream on and speculate on
> > possibility that Python4 could offer an encoding-neutral string type
> > (which means based on bytes)
> >
>
> To
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 idl
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 l
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 cur
100 matches
Mail list logo
