Hello,
Quite an interesting question recently popped up in pygame community
that I'd like to ask to Python developers.
How many of you use IDLE?
What's wrong with it?
>From my side I like the idea of having default Python editor that is
small, fast, convenient and extensible/embeddable. IDLE is small and
fast, but I feel really uncomfortable with its. The worst thing - I
can't change it. Does anybody else feel the same to think if we could
replace IDLE with something more maintainable by providing Scintilla
bindings, for example?
Regards,
--
anatoly t.
On Sat, Oct 10, 2009 at 8:15 PM, RB[0] <roebros(a)gmail.com> wrote:
> Most? people just don't like it - personally it's all I use, Windows or
> otherwise...
>
> On Sat, Oct 10, 2009 at 12:23 PM, Kris Schnee <kschnee(a)xepher.net> wrote:
>>
>> What's wrong with the built-in editor, IDLE?
>
>
Hi,
I think http://www.python.org/dev/peps/pep-3101/ is too liberal with the
choice of fill characters for numerical values. As far as I can see, this
is quite legal:
Python 2.7a0 (trunk:76132M, Nov 6 2009, 15:20:35)
[GCC 4.1.3 20080623 (prerelease) (Ubuntu 4.1.2-23ubuntu3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import *
>>> format(Decimal(4), "9<10")
'4999999999'
>>> format(Decimal(4), "9>10")
'9999999994'
>>> format(Decimal(4), "->2")
'-4'
>>>
I propose to disallow digits and '+-' fill characters for numerical values,
except for the combination '0, left-padding'. Actually, I'd prefer to allow
only whitespace and '0, left-padding'.
See also:
http://bugs.python.org/issue6871http://bugs.python.org/issue6902
Stefan Krah
On Tue, Nov 10, 2009 at 12:10 AM, "Martin v. Löwis" <martin(a)v.loewis.de> wrote:
>>
>> Anatoly's question is actually a fair one for python-dev - we're the
>> ones that *ship* Idle, so it is legitimate to ask our reasons for
>> continuing to do so.
>
> OTOH, the second (or, rather, third) question (does anybody think it
> should be replaced) is indeed on-topic for python-dev.
That is the exact question I have in my mind. Sorry for not being able
to state it clearly. I'll be more straightforward next time.
> I didn't really answer that question before, so I do now: I have not
> personally plans to replace it, and I'm skeptical wrt. anybody else's
> plans unless there is specific code in existence that IDLE could be
> replaced *with*.
There are a lot of Python editors. It is unlikely that they implement
all IDLE features, but I believe that 20% of IDLE features that is
used by 80% of users are guaranteed by any editor out of the box.
Assuming that they are more extensible than IDLE anyway. (I would say
"perfection is achieved when there is nothing more to add...", but I
promised to be straightforward).
If we filter list of http://wiki.python.org/moin/PythonEditors by
language/license/framework, we will be able to see if there is any
suitable open source Python code to replace IDLE's.
Then there will be another issue - all editors are based upon some
frameworks - I didn't see any popular cross-platform GUI toolkits in
Python, so we will inevitably face the need to replace Tkinter with
other default GUI toolkit.
Should we place an editor first and combine the list a of unique
features of IDLE that we (as developers) will surely miss OR should
we think what GUI framework will be more beneficial for Python users
if shipped by default (keeping in mind that we might have to add
missing features to whatever editor we choose later)?
--
anatoly t.
Stop email
Sent from my BlackBerry®
powered by Sinyal Kuat INDOSAT
-----Original Message-----
From: python-dev-request(a)python.org
Date: Tue, 10 Nov 2009 23:09:45
To: <python-dev(a)python.org>
Subject: Python-Dev Digest, Vol 76, Issue 87
Send Python-Dev mailing list submissions to
python-dev(a)python.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help' to
python-dev-request(a)python.org
You can reach the person managing the list at
python-dev-owner(a)python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-Dev digest..."
Today's Topics:
1. Re: 2.7/3.2 release schedule (Martin v. L?wis)
2. Re: 2.7/3.2 release schedule (Nick Coghlan)
3. Re: Reworking the GIL (Antoine Pitrou)
4. Re: Status of the Buildbot fleet and related bugs (Antoine Pitrou)
5. Re: Status of the Buildbot fleet and related bugs
(Martin v. L?wis)
6. Re: 2.7/3.2 release schedule (Benjamin Peterson)
7. Re: 2.7/3.2 release schedule (Martin v. L?wis)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Nov 2009 22:05:41 +0100
From: "Martin v. L?wis" <martin(a)v.loewis.de>
To: Nick Coghlan <ncoghlan(a)gmail.com>
Cc: Python Development <python-dev(a)python.org>
Subject: Re: [Python-Dev] 2.7/3.2 release schedule
Message-ID: <4AF9D5A5.5000707(a)v.loewis.de>
Content-Type: text/plain; charset=UTF-8
>> PEP 3003 states that Python 3.2 will be released 18-24 months after
>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
>> theoretically Python 3.2 should be released not before 2010-12-19 [2].
>
> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
> should have been", so the starting point for the 18-24 month rule of
> thumb is actually back when 3.0 was released in Dec 2008. This was
> discussed a fair bit back when the decision was made to do the short
> release cycle between 3.0 and 3.1 in order to address some of the more
> glaring shortcomings of the 3.0 release.
I agree with everybody else who said that
a) there was *no* consensus that the release cycle for 3.2 should be
shortened because of 3.1 being released early. I also remember the
opposite.
b) whatever past discussion may have been, it would be a mistake to
release 3.2 earlier than 18 months after 3.1.
Of course, 2.7 *could* be released by the proposed schedule; it just
would have to be decoupled from 3.2 (just as 2.6 eventually got
decoupled from 3.0).
I personally think that decoupling the releases would be best, i.e.
not start thinking about 3.2 for another 6 months.
Regards,
Martin
------------------------------
Message: 2
Date: Wed, 11 Nov 2009 07:16:50 +1000
From: Nick Coghlan <ncoghlan(a)gmail.com>
To: "Martin v. L?wis" <martin(a)v.loewis.de>
Cc: Python Development <python-dev(a)python.org>
Subject: Re: [Python-Dev] 2.7/3.2 release schedule
Message-ID: <4AF9D842.5000808(a)gmail.com>
Content-Type: text/plain; charset=UTF-8
Martin v. L?wis wrote:
>>> PEP 3003 states that Python 3.2 will be released 18-24 months after
>>> Python 3.1. Python 3.1 was released on June 2009-06-27 [1], so
>>> theoretically Python 3.2 should be released not before 2010-12-19 [2].
>> The PEP 3003 text isn't allowing for the fact that 3.1 is "3.0 as it
>> should have been", so the starting point for the 18-24 month rule of
>> thumb is actually back when 3.0 was released in Dec 2008. This was
>> discussed a fair bit back when the decision was made to do the short
>> release cycle between 3.0 and 3.1 in order to address some of the more
>> glaring shortcomings of the 3.0 release.
>
> I agree with everybody else who said that
>
> a) there was *no* consensus that the release cycle for 3.2 should be
> shortened because of 3.1 being released early. I also remember the
> opposite.
>
> b) whatever past discussion may have been, it would be a mistake to
> release 3.2 earlier than 18 months after 3.1.
Fair enough - I didn't remember that discussion all that well, but
assumed it had reached that consensus due to the lack of comment when
Benjamin originally posted his proposed schedule. Your response and
Guido's clearly indicate otherwise :)
If that wasn't the consensus, then all the dates should slide back 6
months (i.e. no alphas until June 2010). (I actually prefer that since
it gives me a chance to find a cleaner approach to the runpy.run_path
problem, but didn't want to rehash a discussion I thought we had already
had)
> Of course, 2.7 *could* be released by the proposed schedule; it just
> would have to be decoupled from 3.2 (just as 2.6 eventually got
> decoupled from 3.0).
That leads to a 2.x version with features that aren't yet available in a
3.x version though. I thought we weren't planning on doing that anymore.
> I personally think that decoupling the releases would be best, i.e.
> not start thinking about 3.2 for another 6 months.
Or just have the timing be 18 months for 3.2 and 24 months for 2.7 (i.e.
push the first alpha of both back to June next year).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
---------------------------------------------------------------
------------------------------
Message: 3
Date: Tue, 10 Nov 2009 21:26:24 +0000 (UTC)
From: Antoine Pitrou <solipsis(a)pitrou.net>
To: python-dev(a)python.org
Subject: Re: [Python-Dev] Reworking the GIL
Message-ID: <hdclq0$tov$1(a)ger.gmane.org>
Content-Type: text/plain; charset=UTF-8
Hello again,
I've now removed priority requests, tried to improve the internal doc a
bit, and merged the changes into py3k.
Afterwards, the new Windows 7 buildbot has hung in test_multiprocessing,
but I don't know whether it's related.
Regards
Antoine.
Guido van Rossum <guido <at> python.org> writes:
>
>
> I would remove them -- if and when we find there's a need for
> something like them I suspect it won't look like what you currently
> have, so it's better not to complexificate your current patch with
> them. (I would remove all traces, including the conditions passed into
> the end macros.)
>
> >> My only suggestion so far: the description could use more explicit
> >> documentation on the various variables and macros and how they
> >> combine.
> >
> > Is it before or after
> > http://mail.python.org/pipermail/python-checkins/2009-
November/087482.html ?
>
> After. While that is already really helpful, not all the code is
> easily linked back to paragraphs in that comment block, and some
> variables are not mentioned by name in the block.
>
------------------------------
Message: 4
Date: Tue, 10 Nov 2009 21:50:26 +0000 (UTC)
From: Antoine Pitrou <solipsis(a)pitrou.net>
To: python-dev(a)python.org
Subject: Re: [Python-Dev] Status of the Buildbot fleet and related
bugs
Message-ID: <hdcn72$2rl$1(a)ger.gmane.org>
Content-Type: text/plain; charset=UTF-8
Le Thu, 05 Nov 2009 22:53:27 -0500, R. David Murray a ?crit?:
> 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 buildbots still show occasional oddities. For example, right now in
the page "http://www.python.org/dev/buildbot/3.x/", some results have
disappeared (the columns for "AMD64 Ubuntu" builders have become empty).
Moreover, some buildslaves have gone back in time (they are building
r76188 after having built and tested r76195)... I swear the new GIL
doesn't include a time machine.
Regards
Antoine.
------------------------------
Message: 5
Date: Tue, 10 Nov 2009 23:06:14 +0100
From: "Martin v. L?wis" <martin(a)v.loewis.de>
To: Antoine Pitrou <solipsis(a)pitrou.net>
Cc: python-dev(a)python.org
Subject: Re: [Python-Dev] Status of the Buildbot fleet and related
bugs
Message-ID: <4AF9E3D6.2000807(a)v.loewis.de>
Content-Type: text/plain; charset=UTF-8
>> 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 buildbots still show occasional oddities. For example, right now in
> the page "http://www.python.org/dev/buildbot/3.x/", some results have
> disappeared (the columns for "AMD64 Ubuntu" builders have become empty).
Yes, I noticed it too. It will go away after some page reloads.
> Moreover, some buildslaves have gone back in time (they are building
> r76188 after having built and tested r76195)... I swear the new GIL
> doesn't include a time machine.
That's because I resubmitted these changes after restarting the master.
Regards,
Martin
------------------------------
Message: 6
Date: Tue, 10 Nov 2009 16:06:46 -0600
From: Benjamin Peterson <benjamin(a)python.org>
To: Martin v. L?wis <martin(a)v.loewis.de>
Cc: Nick Coghlan <ncoghlan(a)gmail.com>, Python Development
<python-dev(a)python.org>
Subject: Re: [Python-Dev] 2.7/3.2 release schedule
Message-ID:
<1afaf6160911101406t6da78accq8918eb4ceb1adca5(a)mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
2009/11/10 "Martin v. L?wis" <martin(a)v.loewis.de>:
> I personally think that decoupling the releases would be best, i.e.
> not start thinking about 3.2 for another 6 months.
The problem with that is that there is a period of time where 2.x has
features which 3.x doesn't. My preference is to move back the whole
schedule 6 months.
--
Regards,
Benjamin
------------------------------
Message: 7
Date: Tue, 10 Nov 2009 23:09:42 +0100
From: "Martin v. L?wis" <martin(a)v.loewis.de>
To: Benjamin Peterson <benjamin(a)python.org>
Cc: Nick Coghlan <ncoghlan(a)gmail.com>, Python Development
<python-dev(a)python.org>
Subject: Re: [Python-Dev] 2.7/3.2 release schedule
Message-ID: <4AF9E4A6.8070304(a)v.loewis.de>
Content-Type: text/plain; charset=UTF-8
Benjamin Peterson wrote:
> 2009/11/10 "Martin v. L?wis" <martin(a)v.loewis.de>:
>> I personally think that decoupling the releases would be best, i.e.
>> not start thinking about 3.2 for another 6 months.
>
> The problem with that is that there is a period of time where 2.x has
> features which 3.x doesn't. My preference is to move back the whole
> schedule 6 months.
Ok, fine with me as well. FWIW, I don't see that (2.7 released before
3.2) as a problem (but I understand that others might, for what I would
consider formal reasons).
Regards,
Martin
------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev(a)python.org
http://mail.python.org/mailman/listinfo/python-dev
End of Python-Dev Digest, Vol 76, Issue 87
******************************************
Unreg
------Pesan Asli------
Dari:python-dev-request@python.org
Pengirim:python-dev-bounces+wa2n39=gmail.com@python.org
Ke:python-dev@python.org
Balas Ke:python-dev@python.org
Perihal:Python-Dev Digest, Vol 76, Issue 83
Terkirim:10 Nov 2009 03:00
Send Python-Dev mailing list submissions to
python-dev(a)python.org
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/python-dev
or, via email, send a message with subject or body 'help' to
python-dev-request(a)python.org
You can reach the person managing the list at
python-dev-owner(a)python.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Python-Dev digest..."
Today's Topics:
1. Re: Retrieve an arbitrary element from asetwithoutremoving it
(Nick Coghlan)
----------------------------------------------------------------------
Message: 1
Date: Tue, 10 Nov 2009 20:51:19 +1000
From: Nick Coghlan <ncoghlan(a)gmail.com>
To: "Martin v. L?wis" <martin(a)v.loewis.de>
Cc: python-dev(a)python.org
Subject: Re: [Python-Dev] Retrieve an arbitrary element from
asetwithoutremoving it
Message-ID: <4AF945A7.5090904(a)gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Martin v. L?wis wrote:
>> I'm not sure, but isn't that thread-unsafe?
>
> You are right; it's thread-unsafe.
>
> I would fix it by catching the RuntimeError, and retrying. Given the
> current GIL strategy (including proposed changes to it), it won't happen
> two times in a row, so the number of retries would be bounded.
It's also one of the major reasons for not sharing mutable containers
between threads if you can avoid it (and serialising access to them if
you can't)
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
---------------------------------------------------------------
------------------------------
_______________________________________________
Python-Dev mailing list
Python-Dev(a)python.org
http://mail.python.org/mailman/listinfo/python-dev
End of Python-Dev Digest, Vol 76, Issue 83
******************************************
Sent from my BlackBerry®
powered by Sinyal Kuat INDOSAT
SpamBayes has several files which contain raw 8-bit data embedded in
string literals. Before I do manual work to make them parseable by 2to3
I thought I would ask if there was either a fixer available which I'm
not getting by default or if there is an opportunity to add a new fixer
to 2to3.
The usage is pretty straightforward. For example, a string literal
might contain the bytes for a GIF image:
data = "GIF89a(..."
Is there a potentially automated path from where the code is today to
something Python 3 (and 2to3) will like?
Skip
Now that a new SSL vulnerability is out
(http://extendedsubset.com/?p=8) should we regenerate binary
distributions that include copies of openssl (I think only the Windows
MSIs) ?
Does it affect any of our ssl APIs?
--
--Guido van Rossum (python.org/~guido)
Hi,
recently I wrote an algorithm, in which very often I had to get an arbitrary
element from a set without removing it.
Three possibilities came to mind:
1.
x = some_set.pop()
some_set.add(x)
2.
for x in some_set:
break
3.
x = iter(some_set).next()
Of course, the third should be the fastest. It nevertheless goes through all
the iterator creation stuff, which costs some time. I wondered, why the builtin
set does not provide a more direct and efficient way for retrieving some element
without removing it. Is there any reason for this?
I imagine something like
x = some_set.get()
or
x = some_set.pop(False)
and am thinking about providing a patch against setobject.c (preferring the
.get() solution being a stripped down pop()).
Before, I would like to know whether I have overlooked something or whether
this can be done in an already existing way.
Thanks,
wr
On Nov 7, 2009, at 3:20 AM, Ben Finney wrote:
> Guido van Rossum <guido(a)python.org> writes:
>
>> On Fri, Nov 6, 2009 at 2:52 PM, David Lyon
>> <david.lyon(a)preisshare.net> wrote:
>>>
> I think buildbot-style test runs for PyPI packages would raise average
> package quality on PyPI.
Please excuse the cross-post but I wanted to make sure that all these
"CPAN for Python" discussions got this message and I've lost track of
which list which part of what discussion had occurred on.
We are currently extending our distutils/Distribute test system to
include installation of a broad range of packages as part of the pre-
release process for a future release of Distribute and as part of our
"smoke" test for distutils/Distribute. Eventually, the goal is to
integrate this with our buildbot system but that's a ways off.
Our goal is to install a range of packages and, where practicable,
actually run and record any errors with the packages' individual test
suites.
Right now, our "smoke" test only does Twisted and numpy. We've
discussed how to collect test results from Twisted trial and we'll be
working on similar things for other test runners (nose et al.). For
Twisted, we're going to install and test both the current release
version and an svn checkout from trunk.
It would be an extension of that concept to install and test *all*
packages from PyPI but would, obviously, take considerable horsepower
(and time) to run such an exhaustive test (especially if we're talking
about 2.4?, 2.5, 2.6, 2.7, and 3.1+.
Right now I'm extending the configuration file for our smoke test to
allow for various test runners (e.g. nose, twisted trial, etc.) so we
can "smoke out" more installation problems and/or failed tests after
installation.
For the first pass, I'm just focusing on Twisted and trial, then
numpy, then finding packages that support nose so that I can collect
the data on what ran, what passed, and what didn't. I'm planning on
collecting this all in a database and making some simple API so that
it can be mined by very simple apps later.
At the point where that infrastructure is in place, we could pretty
easily mine the data to do all kinds of crazy things people have
mentioned like:
* A ranking system of test coverage
* Complexity analysis
* Test coverage
* Run pylint, pyflakes, 2to3, whatever automated measurement tools
over the code
* Send test failure messages to maintainers (maybe with opt-in in the
new meta-data).
* Whatever!
We're actively working on this right now; anyone who wants to lend a
hand is welcome to contact me off-list and we can talk about what
types of things we are needing and where we could use a hand.
All in all, I think this could be a big leap forward for the Python
distribution ecosystem whether or not we eventually write the PyPan I
wished for as a new Perl refugee.
Thanks,
S