Hello,
On Thu, Oct 30, 2008 at 07:35, Sonia [EMAIL PROTECTED] wrote:
I m using fileDialog(self, message, path, filename, filter,
aStyle(opotional)) to save the file.
In my code, i used fileDialog to show save dialog box and when we click on
save button, it should save that file which is of
Hi,
Since some months, I'm trying to improve Python but it's difficult because I'm
not allowed to push patches and I have to wait for some reviews and then for
someone interrested by my patches. Sometimes I just get a good reaction
like nice patch and then nothing. Should I stop sending new
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 30, 2008, at 11:08 AM, Victor Stinner wrote:
Since some months, I'm trying to improve Python but it's difficult because
I'm not allowed to push patches and I have to wait for some reviews and then
for someone interrested by my patches.
Let me remind you though that I've been mostly unavailable for the past two
weeks at a work conference.
Cool, you're back :-) But my email was not against you.
That's why I set the 3.0 schedule the way I did.
Personnaly, I don't want to get python 3.0 final with some broken modules or
some
On Thursday 30 October 2008, Victor Stinner wrote:
One of the reasons why I'm very keen on us moving to a distributed
version control system is to help break the logjam on core developers.
Yeah, exactly :-) Does anyone already maintain a distributed tree?
Mercurial, GIT, anything else?
Ulrich Eckhardt wrote:
On Thursday 30 October 2008, Victor Stinner wrote:
One of the reasons why I'm very keen on us moving to a distributed
version control system is to help break the logjam on core developers.
Yeah, exactly :-) Does anyone already maintain a distributed tree?
Mercurial,
Barry Warsaw wrote:
or even decided that we're moving to one. Brett as the head of the
infrastructure committee will have more to say about that.
While it is indeed the infrastructure committee's call (since they'll
shoulder the bulk of the effort in organising further investigation into
the
I like to raise attention for a problem revealed by
http://bugs.python.org/issue4237
---
The bug was caused by a design flaw -- which was partly my fault. Some
elements of the PyFileIOObject struct were initialized in __new__ while
other parts were initialized in __init__. I've moved the
Ulrich Eckhardt wrote:
On Thursday 30 October 2008, Victor Stinner wrote:
One of the reasons why I'm very keen on us moving to a distributed
version control system is to help break the logjam on core developers.
Yeah, exactly :-) Does anyone already maintain a distributed tree?
Mercurial, GIT,
On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote:
One of the reasons why I'm very keen on us moving to a distributed version
control system is to help break the logjam on core developers. True, your
code will still not be able to land in the official branch without core
developer
2008-10-30 16:04 A.M. Kuchling [EMAIL PROTECTED] napisał(a):
On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote:
One of the reasons why I'm very keen on us moving to a distributed version
control system is to help break the logjam on core developers. True, your
code will still not
On Oct 30, 2008, at 11:11 AM, Arfrever Frehtes Taifersar Arahesis wrote:
SVN supports path-based authorization.
http://svnbook.red-bean.com/nightly/en/svn.serverconfig.pathbasedauthz.html
This has worked well for us with contractors and partners, and isn't
problematic or tedious to
Arfrever Frehtes Taifersar Arahesis wrote:
2008-10-30 16:04 A.M. Kuchling [EMAIL PROTECTED] napisał(a):
On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote:
One of the reasons why I'm very keen on us moving to a distributed version
control system is to help break the logjam on core
On Thu, Oct 30, 2008 at 8:50 AM, Barry Warsaw [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote:
If Python would be more reactive, more developer will be attracted. The
communication is very important in an open source
2008/10/30 A.M. Kuchling [EMAIL PROTECTED]:
On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote:
One of the reasons why I'm very keen on us moving to a distributed version
control system is to help break the logjam on core developers. True, your
code will still not be able to land in
On Thu, Oct 30, 2008 at 11:55 AM, Paul Moore [EMAIL PROTECTED] wrote:
I just did a quick experiment, checking for trivial documentation
patches I could review, and some things became obvious:
1. There is no way of telling which issues have a patch.
There is a patch keyword that is usually
On Thu, Oct 30, 2008 at 4:55 PM, Paul Moore [EMAIL PROTECTED] wrote:
I don't see how a DVCS will fix anything. The bottleneck is in
assessing patches for inclusion in the master tree; not enough people
are doing that. We'd just end up with lots of proposed branches
waiting to be merged,
On Thu, Oct 30, 2008 at 12:09 PM, Tarek Ziadé [EMAIL PROTECTED] wrote:
On Thu, Oct 30, 2008 at 4:55 PM, Paul Moore [EMAIL PROTECTED] wrote:
I don't see how a DVCS will fix anything. The bottleneck is in
assessing patches for inclusion in the master tree; not enough people
are doing that.
Hi to all Python developers
For a student project in a course on virtual machines, we are
evaluating the possibility to
experiment with removing the GIL from CPython
We have read the arguments against doing this at
Yes, that's what __new__ / tp_new is for! Thanks for finding this.
On Thu, Oct 30, 2008 at 7:20 AM, Christian Heimes [EMAIL PROTECTED] wrote:
I like to raise attention for a problem revealed by
http://bugs.python.org/issue4237
---
The bug was caused by a design flaw -- which was partly my
On Thu, Oct 30, 2008 at 12:13 PM, Sigurd Torkel Meldgaard
[EMAIL PROTECTED] wrote:
Hi to all Python developers
For a student project in a course on virtual machines, we are
evaluating the possibility to
experiment with removing the GIL from CPython
We have read the arguments against doing
It's not that I have any love for the GIL, it just is the best
compromise I could find. I expect that you won't be able to do better,
but I wish you luck anyway.
On Thu, Oct 30, 2008 at 9:13 AM, Sigurd Torkel Meldgaard
[EMAIL PROTECTED] wrote:
Hi to all Python developers
For a student project
Sigurd Torkel Meldgaard wrote:
Hi to all Python developers
For a student project in a course on virtual machines, we are
evaluating the possibility to
experiment with removing the GIL from CPython...
Just an FYI, these two particular students already introduced themselves
on the PyPy list.
On Oct 30, 2008, at 10:20 AM, Christian Heimes wrote:
I like to establish a rule that *all* struct members must be
initialized properly in the type's tp_new function.
I think this has always been a requirement. The result of the new
operation must conform to all the requirements that the
VanL wrote:
Just an FYI,
...and the FYI was to no one in particular, just interesting information
from the PyPy list. It is just unfortunate timing that made it look like
a cheeky reply to Guido.
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Oct 30, 2008 at 1:07 PM, VanL [EMAIL PROTECTED] wrote:
Just an FYI, these two particular students already introduced themselves
on the PyPy list. Paolo is a masters student with experience in the
Linux kernel; Sigurd is a PhD candidate.
Their professor is Lars Bak, the lead architect
On Thu, Oct 30, 2008 at 10:20 AM, VanL [EMAIL PROTECTED] wrote:
VanL wrote:
Just an FYI,
...and the FYI was to no one in particular, just interesting information
from the PyPy list. It is just unfortunate timing that made it look like
a cheeky reply to Guido.
No offense taken. The V8
Guido van Rossum wrote:
No offense taken. The V8 experience makes me feel much more optimistic
that they might actually pull this off. (I'm still skeptical about
support for extension modules, withougt which CPython is pretty lame.)
The need to modify all extension modules is the usual
On Thu, Oct 30, 2008 at 10:31 AM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
No offense taken. The V8 experience makes me feel much more optimistic
that they might actually pull this off. (I'm still skeptical about
support for extension modules, withougt which CPython is
Hi all,
Here is a first step towards classifying the Python test suite into
real language tests and implementation details:
http://bugs.python.org/issue4242
If the general approach seems acceptable to people, I would be willing
to port more of PyPy's test suite patches. The net result
On Thu, Oct 30, 2008 at 06:14, Nick Coghlan [EMAIL PROTECTED] wrote:
Ulrich Eckhardt wrote:
On Thursday 30 October 2008, Victor Stinner wrote:
One of the reasons why I'm very keen on us moving to a distributed
version control system is to help break the logjam on core developers.
Yeah,
Guido van Rossum wrote:
On Thu, Oct 30, 2008 at 10:31 AM, Eric Smith [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
No offense taken. The V8 experience makes me feel much more optimistic
that they might actually pull this off. (I'm still skeptical about
support for extension modules,
On Thu, Oct 30, 2008 at 05:50, Barry Warsaw [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 30, 2008, at 01:02 PM, Victor Stinner wrote:
[SNIP]
If Python would be more reactive, more developer will be attracted. The
communication is very important in an open
Question - is there anything Roundup can do to help triage? Extra
status or keyword values (has patch,
There is patch keyword already, and a public query Patches
(as well as My Patches)
ready to go, ...)?
We could give more people the right to set the resolution to Accepted.
This is a matter
What about having two level of devs ?
+ core developers
+ standard library developers
We effectively have that already. Many of the committers will
only ever commit to a single module (+docs and tests), as they
volunteered to maintain that very module (e.g. Lars Gustäbel
for the tarfile
Interestingly enough, I consider myself in the standard library
developers RE: the multiprocessing package. I just thought that's how
things broke down unofficially.
It's actually fairly official (see my other message) - you know who you
are. It has been working that way fine for the last few
I have a fix for a modulefinder crash that I'm going to commit
into the trunk. Since the bug is also in release26-maint I will
also backport it. While preparing this I noticed that in the
release26-maint branch 'svnmerge init' has not yet been done.
I assume that we will use svnmerge to merge
Thomas Heller wrote:
I have a fix for a modulefinder crash that I'm going to commit
into the trunk. Since the bug is also in release26-maint I will
also backport it. While preparing this I noticed that in the
release26-maint branch 'svnmerge init' has not yet been done.
Are you sure? I did a
Christian Heimes schrieb:
Thomas Heller wrote:
I have a fix for a modulefinder crash that I'm going to commit
into the trunk. Since the bug is also in release26-maint I will
also backport it. While preparing this I noticed that in the
release26-maint branch 'svnmerge init' has not yet been
AFAICS there are no buildbots for the release26-maint branch.
Thomas
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
AFAICS there are no buildbots for the release26-maint branch.
That's correct. I'm waiting to create them until after we retire the
2.5 ones.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Thu, Oct 30, 2008 at 12:16 PM, Armin Rigo [EMAIL PROTECTED] wrote:
Hi all,
Here is a first step towards classifying the Python test suite into
real language tests and implementation details:
http://bugs.python.org/issue4242
I've actually implemented something like this along with more
On Thu, Oct 30, 2008 at 3:38 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
AFAICS there are no buildbots for the release26-maint branch.
That's correct. I'm waiting to create them until after we retire the
2.5 ones.
That reminds me: Do we have a final release date for 2.5.3 set?
--
Cheers,
Benjamin Peterson wrote:
On Thu, Oct 30, 2008 at 3:38 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
AFAICS there are no buildbots for the release26-maint branch.
That's correct. I'm waiting to create them until after we retire the
2.5 ones.
That reminds me: Do we have a final release date
On Thu, Oct 30, 2008 at 03:55:38PM +, Paul Moore wrote:
2. Some patches marked as documentation are doc fixes, others seem
to be issues where it has been decided that the behaviour is correct
as is, but needs to be documented. Fair enough, but it's much harder
to assess the latter, and
Arfrever Frehtes Taifersar Arahesis schrieb:
2008-10-30 16:04 A.M. Kuchling [EMAIL PROTECTED] napisał(a):
On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote:
One of the reasons why I'm very keen on us moving to a distributed version
control system is to help break the logjam on core
On Thu, 30 Oct 2008 17:17:02 -0400, A.M. Kuchling [EMAIL PROTECTED] wrote:
[snip]
On some of my issues (esp. ones relating to curses and mailbox.py), I
feel paralyzed because problems are occurring on platforms I don't
have access to (e.g. FreeBSD). The buildbots will report problems,
but then
On Thu, Oct 30, 2008 at 22:17, A.M. Kuchling [EMAIL PROTECTED] wrote:
On some of my issues (esp. ones relating to curses and mailbox.py), I
feel paralyzed because problems are occurring on platforms I don't
have access to (e.g. FreeBSD). The buildbots will report problems,
but then you have
On Thu, Oct 30, 2008 at 1:00 PM, Fred Drake [EMAIL PROTECTED] wrote:
It's good to move work into __init__ where reasonable, so that it can be
avoided if a subclass wants it done in a completely different way, but new
can't work that way.
And that is exactly the reason why, the _pickle module
Alexandre Vassalotti wrote:
On Thu, Oct 30, 2008 at 1:00 PM, Fred Drake [EMAIL PROTECTED] wrote:
It's good to move work into __init__ where reasonable, so that it can be
avoided if a subclass wants it done in a completely different way, but new
can't work that way.
And that is exactly the
On Oct 30, 2008, at 1:31 PM, Eric Smith wrote:
Guido van Rossum wrote:
No offense taken. The V8 experience makes me feel much more
optimistic
that they might actually pull this off. (I'm still skeptical about
support for extension modules, withougt which CPython is pretty
lame.)
The
On some of my issues (esp. ones relating to curses and mailbox.py), I
feel paralyzed because problems are occurring on platforms I don't
have access to (e.g. FreeBSD). The buildbots will report problems,
but then you have to debug them by committing changes, triggering a
build, and observing
By the way, it seems that this python-checkins mailing list did not
archive the recent commits:
http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end
I miss them... Can someone fix it?
Which ones are you missing specifically?
Regards,
Martin
On Thu, Oct 30, 2008 at 6:25 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
By the way, it seems that this python-checkins mailing list did not
archive the recent commits:
http://mail.python.org/pipermail/python-checkins/2008-October/date.html#end
I miss them... Can someone fix it?
Which ones
2008/10/30 Martin v. Löwis [EMAIL PROTECTED]:
Question - is there anything Roundup can do to help triage? Extra
status or keyword values (has patch,
There is patch keyword already, and a public query Patches
(as well as My Patches)
Sorry, I checked the keywords but missed it.
ready to go,
Alexandre Vassalotti wrote:
And that is exactly the reason why, the _pickle module doesn't use
__new__ for initialization. Doing any kind of argument parsing in
__new__ prevents subclasses from customizing the arguments for their
__init__.
Although, I agree that __new__ should be used,
I haven't seen any of the ones today.
OK, I've respooled them.
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
[oops, I forgot to cc the list]
On Thu, Oct 30, 2008 at 7:43 PM, Christian Heimes [EMAIL PROTECTED] wrote:
Alexandre Vassalotti wrote:
And that is exactly the reason why, the _pickle module doesn't use
__new__ for initialization. Doing any kind of argument parsing in
__new__ prevents
On Thu, Oct 30, 2008 at 12:09 PM, Tarek Ziadé [EMAIL PROTECTED] wrote:
What about having two level of devs ?
+ core developers
+ standard library developers
I was also thinking about two levels of developers, but structured a
little differently. We have the same core developers with
Le Friday 31 October 2008 00:34:32 Paul Moore, vous avez écrit :
Agreed. I was thinking vaguely in terms of a type of voting - rather
than a status or resolution, it might be more like the nosy list - a
list of people who have said they think the patch is OK. The more
people on the list, the
Sigurd Torkel Meldgaard [EMAIL PROTECTED] wrote:
For a student project in a course on virtual machines, we are
evaluating the possibility to experiment with removing the GIL
from CPython
Hi,
It's great to hear of this kind of project. I think what you want
to do is difficult but possible.
On Thu, Oct 30, 2008 at 17:27, Victor Stinner
[EMAIL PROTECTED] wrote:
Le Friday 31 October 2008 00:34:32 Paul Moore, vous avez écrit :
Agreed. I was thinking vaguely in terms of a type of voting - rather
than a status or resolution, it might be more like the nosy list - a
list of people who
I just tried to update my 3.0 branch in hg from
http://code.python.org/hg/branches/py3k/ and hg is telling me it's a
404. Anyone else having trouble?
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
63 matches
Mail list logo
