On Thu, Nov 5, 2009 at 11:43 PM, "Martin v. Löwis" wrote:
> I read Raymond's suggestion rather as a question: why bother with a
> tedious, multi-year process, when a three-line function will achieve
> exactly the same?
Because it doesn't achieve exactly the same. What I want is a
sane, ration
On Fri, 6 Nov 2009 10:52:54 am Yuvgoog Greenle wrote:
> On Fri, Nov 6, 2009 at 1:17 AM, James Y Knight wrote:
> > Is this thread over yet?
>
> Sorry, I just had to point out that pop/add has a side effect that
> would be apparent on a set that multiple threads access - it loses an
> item and then
On Thu, Nov 5, 2009 at 19:23, Guido van Rossum wrote:
> On Thu, Nov 5, 2009 at 3:35 PM, Brett Cannon wrote:
>> On Thu, Nov 5, 2009 at 15:26, Guido van Rossum wrote:
>>> I have come to the conclusion that there are better ways to
>>> pre-announce that a module is going to disappear instead of
>>>
> On Thu, Nov 5, 2009 at 5:02 PM, Raymond Hettinger wrote:
>> Forgot to post the code. It is short, fast, and easy. It is explicit about
>> handing the case with an empty input. And it is specific about which value
>> it returns (always the first iterated value; not an arbitrary one). There's
On Thu, 5 Nov 2009 08:13:55 pm Michael Foord wrote:
> There are several partial implementations, including Python inspired
> languages, but if we are looking at 'major complete implementations'
> then the current list seems to be: CPython, Jython, IronPython and
> PyPy. Even Unladen Swallow is a f
On Thu, Nov 5, 2009 at 11:21 PM, John Arbash Meinel
wrote:
> geremy condra wrote:
>> On Thu, Nov 5, 2009 at 4:09 PM, Alexander Belopolsky
>> wrote:
>>> On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser
>>> wrote:
.. and "x = iter(s).next()" raises a StopIteration
exception.
>>> And t
geremy condra wrote:
> On Thu, Nov 5, 2009 at 4:09 PM, Alexander Belopolsky
> wrote:
>> On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser
>> wrote:
>>> .. and "x = iter(s).next()" raises a StopIteration
>>> exception.
>> And that's why the documented recipe should probably recommend
>> next(ite
On Thu, Nov 5, 2009 at 1:08 PM, "Martin v. Löwis" wrote:
> > Mike Krell wrote:
> >> Well, 3to2 would then be an option for you: use Python 3 as the
> source
> >> language.
> >
> > Making life easier for 3to2 is an *excellent* rationale for backports.
>
Clarifying a bit of potentially misl
The buildbot waterfall is much greener now. Thanks to all who have
contributed to making it so (and it hasn't just been Mark and Antoine
and I, though we've been the most directly active (and yes, Mark, you
did contribute several fixes!)).
The 'stable builders' fleet is green now except for:
On Thu, Nov 5, 2009 at 3:35 PM, Brett Cannon wrote:
> On Thu, Nov 5, 2009 at 15:26, Guido van Rossum wrote:
>> I have come to the conclusion that there are better ways to
>> pre-announce that a module is going to disappear instead of
>> deprecation warnings.
>
> What exactly are those better ways
On Thu, Nov 5, 2009 at 6:30 PM, geremy condra wrote:
> I'm testing the speed because the claim was made that the pop/add
> approach was inefficient. Here's the full quote:
>
>> The obvious way, for newcomers, of achieving the effect is:
>>
>> x = s.pop()
>> s.add(x)
>>
>> ... and that's simpl
On Thu, Nov 5, 2009 at 5:02 PM, Raymond Hettinger wrote:
> Forgot to post the code. It is short, fast, and easy. It is explicit about
> handing the case with an empty input. And it is specific about which value
> it returns (always the first iterated value; not an arbitrary one). There's
> no
Tarek,
> Your proposal is a partial alternative to PEP 390, and is a quite
> interesting work to dig in, and the SIG is discussing it,
> but a very important point about it is that it does a lot more. It's a
> new *building* system on its own, and does not limit itself to
> describing metadata fi
On Thu, Nov 5, 2009 at 15:55, David Lyon wrote:
>
> Tarek, Guido,
>
> Forgive my grumpy tone..
>
> Looking positive, if we now have a rough consensus that the PEPS might
> represent some 300+ lines of code... then good - lets get started, that's
> all that I meant. I'm glad above all, that you not
2009/11/6 David Lyon :
[..]
> Here are the references to the discussions from distutils-sig. In these
> references you'll see that my interaction with the list was not grumpy
> but was entirely positive. I feel that I got a fair hearing on distutils
> list and I had a number of supporters to my pro
Guido van Rossum wrote:
On Tue, Nov 3, 2009 at 9:35 AM, Guido van Rossum wrote:
I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.
I haven't seen substantial opposition against the PEP -- in fact I
can't recall any, and man
On Thu, Nov 5, 2009 at 6:17 PM, James Y Knight wrote:
> On Nov 5, 2009, at 6:04 PM, geremy condra wrote:
>>
>> Perhaps my test is flawed in some way?
>
> Yes: you're testing the speed of something that makes absolutely no sense to
> do in a tight loop, so *who the heck cares how fast any way of do
On 5 Nov, 11:55 pm, bobbyrw...@gmail.com wrote:
What exactly are those better ways? Document as deprecated only?
-Brett
A switch to ENABLE those warnings?
Lord knows I'm sick of filtering them out of logs.
A switch to enable deprecation warnings would give developers a
chance to see them w
On Fri, Nov 6, 2009 at 1:55 AM, Bobby R. Ward wrote:
>
> A switch to ENABLE those warnings?
>
>
I think a few people I know would still be raising strings like exceptions
if not for the deprecation warnings. Most people won't turn on the switch
with the extra warnings.
--yuv
Tarek, Guido,
Forgive my grumpy tone..
Looking positive, if we now have a rough consensus that the PEPS might
represent some 300+ lines of code... then good - lets get started, that's
all that I meant. I'm glad above all, that you noticed that part foremost.
If it's a simple case that alternati
> What exactly are those better ways? Document as deprecated only?
>
> -Brett
A switch to ENABLE those warnings?
Lord knows I'm sick of filtering them out of logs.
A switch to enable deprecation warnings would give developers a
chance to see them when migrating to a new version of python. And
On Fri, Nov 6, 2009 at 1:17 AM, James Y Knight wrote:
>
> Is this thread over yet?
>
>
Sorry, I just had to point out that pop/add has a side effect that would be
apparent on a set that multiple threads access - it loses an item and then
gets it back. Sounds like a sleeper race condition that's g
On Thu, Nov 5, 2009 at 15:26, Guido van Rossum wrote:
> On Thu, Nov 5, 2009 at 3:21 PM, Jesse Noller wrote:
>> On Thu, Nov 5, 2009 at 5:53 PM, Dirkjan Ochtman wrote:
>>> On Thu, Nov 5, 2009 at 23:05, Guido van Rossum wrote:
I haven't seen substantial opposition against the PEP -- in fact I
On Thu, Nov 5, 2009 at 6:26 PM, Guido van Rossum wrote:
>>
>> I'm against restricting deprecation warnings within the stdlib as part
>> of this. I actually want more things cleaned up and possibly
>> deprecated. That being said, a deprecation warning just means we will
>> remove it One Day - anyt
On Thu, Nov 5, 2009 at 3:21 PM, Jesse Noller wrote:
> On Thu, Nov 5, 2009 at 5:53 PM, Dirkjan Ochtman wrote:
>> On Thu, Nov 5, 2009 at 23:05, Guido van Rossum wrote:
>>> I haven't seen substantial opposition against the PEP -- in fact I
>>> can't recall any, and many people have explicitly poste
On Thu, Nov 5, 2009 at 14:53, Dirkjan Ochtman wrote:
> On Thu, Nov 5, 2009 at 23:05, Guido van Rossum wrote:
>> I haven't seen substantial opposition against the PEP -- in fact I
>> can't recall any, and many people have explicitly posted in support of
>> it. So unless opposition suddenly appears
On Thu, Nov 5, 2009 at 5:53 PM, Dirkjan Ochtman wrote:
> On Thu, Nov 5, 2009 at 23:05, Guido van Rossum wrote:
>> I haven't seen substantial opposition against the PEP -- in fact I
>> can't recall any, and many people have explicitly posted in support of
>> it. So unless opposition suddenly appea
David, you have an attitude problem. Your contributions (the post
below is just an example) don't sound healthy to me -- you just
complain and whine and denigrate Tarek's work. In a previous post you
claimed to have had a particular idea first (it doesn't matter which
idea) and you managed to make
On Nov 5, 2009, at 6:04 PM, geremy condra wrote:
Perhaps my test is flawed in some way?
Yes: you're testing the speed of something that makes absolutely no
sense to do in a tight loop, so *who the heck cares how fast any way
of doing it is*!
Is this thread over yet?
James
___
On Thu, Nov 5, 2009 at 4:09 PM, Alexander Belopolsky
wrote:
> On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser wrote:
>> .. and "x = iter(s).next()" raises a StopIteration
>> exception.
>
> And that's why the documented recipe should probably recommend
> next(iter(s), default) instead. Especia
On Thu, Nov 5, 2009 at 11:29 PM, David Lyon wrote:
[...]
>
> But if you put all these PEPs together, implementing all the new features
> can't come to more than 300 lines of code...
>
> Since we hardly got anywhere on them in 2009, it will be interesting to
> see how much of it gets done in 2010.
[me]
Why not write a short, fast get_first() function for your utils directory and
be done with it?
That could work with sets, mappings, generators, and other containers and
iterators.
No need to fatten the set/frozenset API for something so trivial and so rarely
needed.
Forgot to post the c
On 2009-11-05 16:29 PM, David Lyon wrote:
But I've been on the list for some twelve months asking for work
to help out with, and haven't been assigned a single task to do
yet.
Seriously, if you won't allocate work out to people then how can
it get done?
With rare exceptions, open source proje
On Thu, Nov 5, 2009 at 23:05, Guido van Rossum wrote:
> I haven't seen substantial opposition against the PEP -- in fact I
> can't recall any, and many people have explicitly posted in support of
> it. So unless opposition suddenly appears in the next few days, I'll
> move it to the Accepted state
On Thu, 5 Nov 2009 11:35:41 +0100, Tarek Ziadé
wrote:
> PEP 376 is working on a default, unified, *installation* format, that
> tries to gather the good ideas of Pip, Setuptools etc.. and propose a
> unified format for our site-packages. This new standard will come with
> APIs in pkgutil to be abl
[Chris Bergstresser]
> Clearly, I'll need to write up the PEP.
Why not write a short, fast get_first() function for your utils directory and
be done with it?
That could work with sets, mappings, generators, and other containers and
iterators.
No need to fatten the set/frozenset API for somethi
On Thu, Nov 5, 2009 at 3:21 PM, "Martin v. Löwis" wrote:
> There are two ways
>
> a) write a library that provides what you want, publish it on PyPI,
> and report back in a few years of how many users your library has,
> what they use it for, and why it should become builtin
This clearly
On Thu, Nov 5, 2009 at 14:20, Arfrever Frehtes Taifersar Arahesis
wrote:
> 2009-11-03 18:35:10 Guido van Rossum napisał(a):
>> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
>> SVN. As authors I've listed Jesse, Brett and myself.
>>
>> On python-ideas the moratorium idea got f
2009-11-03 18:35:10 Guido van Rossum napisał(a):
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
>
> On python-ideas the moratorium idea got fairly positive responses
> (more positive than I'd expected, in fact) but I'm b
[GvR]
I haven't seen substantial opposition against the PEP -- in fact I
can't recall any, and many people have explicitly posted in support of
it. So unless opposition suddenly appears in the next few days, I'll
move it to the Accepted state next Monday.
But it would have been so much fun to
On Tue, Nov 3, 2009 at 9:35 AM, Guido van Rossum wrote:
> I've checked draft (!) PEP 3003, "Python Language Moratorium", into
> SVN. As authors I've listed Jesse, Brett and myself.
I haven't seen substantial opposition against the PEP -- in fact I
can't recall any, and many people have explicitly
Stefan wrote:
> I assume that this is artificially exaggerated to make a point, as this
> behaviour is obviously not a technical requirement but an optimisation,
> which could potentially be disabled.
>
If there's a way to disable this then that's fine and IMO when it was disabled
you'd still be
>> I would certainly agree to setup two slaves on mine. There are ample
>> resources available.
>
> I could do so as well. Gentoo is one of the distributions that uses
> the wide build by default, so that would make it a good test candidate
> as well.
I have now setup two slaves, murray-gentoo-w
Michael Foord voidspace.org.uk> writes:
>
> I would love to see nonlocal backported to 2.7 as it cleans up a simple
> pattern that I use relatively often for testing.
Well you know I'm sure that if someone proposes a proper patch it will
eventually get accepted ;)
Regards
Antoine.
_
>I feel pretty strongly that it's a wart in the language, and a
> sufficiently strong one that it should be remedied. I'm happy to
> champion it, but haven't the faintest idea what that entails.
There are two ways
a) write a library that provides what you want, publish it on PyPI,
and rep
On Thu, Nov 5, 2009 at 3:43 PM, Chris Bergstresser wrote:
> .. and "x = iter(s).next()" raises a StopIteration
> exception.
And that's why the documented recipe should probably recommend
next(iter(s), default) instead. Especially because iter(s).next() is
not even valid code in 3.0.
On Wed, Nov 4, 2009 at 7:07 PM, Raymond Hettinger wrote:
> [Steven D'Aprano]
>>> Anyway, given the level of opposition to the suggestion, I'm no longer
>>> willing to carry the flag for it. If anyone else -- perhaps the OP --
>>> feels they want to take it any further, be my guest.
I feel pret
Dino Viehland, 05.11.2009 19:35:
> Stefan wrote:
>> It /does/ make some static assumptions in that it considers builtins
>> true
>> builtins. However, it does not prevent you from replacing them in your
>> code, as long as you do it inside the module. Certainly a restriction
>> compared to Python,
On Thu, Nov 5, 2009 at 09:34, Yuvgoog Greenle wrote:
> On Thu, Nov 5, 2009 at 2:31 PM, Nick Coghlan wrote:
>>
>> While it may be hard to tell without knowing who is and isn't a core
>> developer
>
> Maybe there should be badges or something, hmmm, sounds like making an
> svn-commits-hall-of-fame
2009/11/4 Nick Coghlan :
> Lennart Regebro wrote:
>> I also would really like to see a real port of the bytes class to 2.6,
>> but I have a vague memory that there was some reason that wouldn't
>> work.
>
> Not so much that it wouldn't work, but that the interfaces to support
> using it effectively
2009/11/4 Nick Coghlan :
> In writing it up, it occurred to me that having that kind of thing in a
> "py3_compat" compatibility module (to be used as, e.g., "from py3_compat
> import str, bytes") would not only make it easier to use in multiple
> modules, but also easier for 2to3 to remove when for
2009/11/4 sstein...@gmail.com :
> Maybe the 3.x line should just be put out of our misery, merged back to 2.7,
> 2.8, 2.9, and proceed as Glyph suggested in passing with increasing levels
> of deprecation until it just turns into 3.x on its own by running out of
> numbers.
Yeah, maybe. If people h
Martin v. Löwis wrote:
Mike Krell wrote:
Well, 3to2 would then be an option for you: use Python 3 as the source
language.
Making life easier for 3to2 is an *excellent* rationale for backports.
I'm skeptical. If new features get added to 2.7: why would that simplify
3to2? It couldn't
Martin v. Löwis wrote:
Mike Krell wrote:
Well, 3to2 would then be an option for you: use Python 3 as the source
language.
Making life easier for 3to2 is an *excellent* rationale for backports.
I'm skeptical. If new features get added to 2.7: why would that simplify
3
2009/11/4 "Martin v. Löwis" :
>> Keep in mind also that the 2.x translation process is extremely slow and
>> results in a clunky development process. There's no '2to3
>> --interactive' commandline that lets me type python 2 at a >>> prompt
>> and get python 3 results out so that I can try experime
> Mike Krell wrote:
>> Well, 3to2 would then be an option for you: use Python 3 as the source
>> language.
>
> Making life easier for 3to2 is an *excellent* rationale for backports.
>
I'm skeptical. If new features get added to 2.7: why would that simplify
3to2? It couldn't *use* these f
Stefan,
I think your attempts to see Cython accepted as one of the major
Python implementations is misguided. It is not self-contained, it is
an add-on tool for CPython (like its ancestor PyRex).
I think Cython is incredibly useful (and I spoke to many very happy
users yesterday at UCB) but tryin
At 11:27 PM 11/4/2009 +, Floris Bruynooghe wrote:
You have time to read this thread but no time to read "What's New In
Python 3"?
Given that the average developer using tons of existing libraries on
2.x is unlikely to see any killer benefits in moving to 3.x, it's a
natural attitude t
Maciej Fijalkowski, 05.11.2009 19:01:
>> Most Python implementations do not reimplement the stdlib, or at most a
>> minor part of it, so that's right out of the discussion.
>
> Did you actually check?
Well, I know that Jython uses the original stdlib modules through
svn:externals in the build, la
On Thu, Nov 5, 2009 at 10:35 AM, Dino Viehland wrote:
> Stefan wrote:
>> It /does/ make some static assumptions in that it considers builtins
>> true
>> builtins. However, it does not prevent you from replacing them in your
>> code, as long as you do it inside the module. Certainly a restriction
>
60 matches
Mail list logo
