Re: [Python-Dev] Cannot set PYTHONPATH with big paths with Python 3.0 and 3.1

2009-06-09 Thread Antoine Pitrou
Martin v. Löwis martin at v.loewis.de writes:
 
  I've reported bug http://bugs.python.org/issue5924 some time ago and I
  think it's a release blocker -- it seems easy to fix, but I don't have
  time to actually submit a patch, so, I'd like to draw attention to it,
  especially as a release candidate is already out.
 
 In absence of a patch, it can't be a release blocker, IMO.

I think we've had lots of issues filed as release blockers while they still
didn't have a patch.
As for whether this particular bug deserves to be a blocker, I don't know. It is
certainly annoying, however.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Cannot set PYTHONPATH with big paths with Python 3.0 and 3.1

2009-06-09 Thread Amaury Forgeot d'Arc
Hi,

2009/6/9 Antoine Pitrou solip...@pitrou.net:
 Martin v. Löwis martin at v.loewis.de writes:
 In absence of a patch, it can't be a release blocker, IMO.

 I think we've had lots of issues filed as release blockers while they still
 didn't have a patch.
 As for whether this particular bug deserves to be a blocker, I don't know. It 
 is
 certainly annoying, however.

FYI, I just submitted a patch. It is simple enough to be considered
for inclusion for rc2.

-- 
Amaury Forgeot d'Arc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Status of 2.7 and 3.2

2009-06-09 Thread anatoly techtonik
On Mon, Jun 8, 2009 at 11:01 PM, Martin v. Löwis mar...@v.loewis.de wrote:

 I am not quite sure whether you are for new features or not. Your
 first sentence (vote for ... not adding new features) seems to
 suggest that you would not like to see new features, and your last
 sentence (absence of native curses/console/readline module)
 suggests that you *do* want to see new features (namely, a native
 curses module, and a native readline module).

 Which one is it?

I would like to see new features in Python, but only if they are
cross-platform. Unfortunately, I do not possess C skills to make this
happen, nor do I have deep understanding of Microsoft Visual Studio
.project files to port Makefiles and GCC options even when codebase is
available for windows.

The level to make a contribution in this case is too high. The lack of
free time makes it impossible to close the gap in one step leaving
remnants of work-in-process that will make it harder to continue in
future than to start from scratch.

Perhaps the necessity to make it in one huge step could be compensated
by incremental solution approach and development process if there was
obvious centralized place to organize efforts AND provide clear
visibility into progress made so far, initial plan, plan deviation and
current status. Mailing lists are good for discussions, but that's all
- information becomes outdated, text-too-much, no prompt reply often
stops the progress. Perhaps I shift my problem from lack-of-skill into
lack-of-tools direction, but being amazed by efforts people put into
supporting this mailing list I most of the time unable to reply to
emails I get mostly because replies require time for testing and
proving facts.

There is no definite proposal to solve problems of enabling OpenID or
SSO for python.org, of porting curses to windows, of testing
subprocessing etc., but there is an idea that some things could be
given more visibility AND priority to allow people to see the big
picture and focus on outstanding problems. Even though most people
here know about big-things-to-fix, these things doesn't standout from
the pile of issues in roundup.

The thing I miss the most is ability to gather all information
relevant to one problem in one place. This includes timeline with
commits, branches, relevant issues, issue updates, relevant wiki
edits, current focus URLs, _filtered_ threads and refactored comments.
The problem is to ensure that this information is up to date and
provide easy way/instruction how to bring it up to date in case
something is broken. It is not necessary to meet the bus to experience
the effect of bus factor.

-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Tags from closed branch heads?

2009-06-09 Thread Dirkjan Ochtman
So ca8d05e1f1d1 changed the default for repo.heads() to closed=False,
so that calls to heads() by default will not return closed heads.
Unfortunately, this also means that any tags from those heads will not
be considered anymore. That seems inadvertent at best, and may be
should be reverted. Conceptually, it seems wrong that deleting a
branch would also delete all the tags from it. I'd like to propose
this change:

diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -320,7 +320,7 @@
 def _hgtagsnodes(self):
 last = {}
 ret = []
-for node in reversed(self.heads()):
+for node in reversed(self.heads(closed=True)):
 c = self[node]
 rev = c.rev()
 try:

Is that something we can agree on?

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] python sendmsg()/recvmsg() implementation

2009-06-09 Thread Kálmán Gergely

Hello, my name is Greg.

I've just started using python after many years of C programming, and 
I'm also new to the list. I wanted to clarify this

first, so that maybe I will get a little less beating for my stupidity :)

I use python3 and Linux on arch x86 (production will be on x86_64, 
though this shouldn't matter much).


The application that I'm presently working on is a network server. It 
would use separate processes to accept the
connections, and to do the work (much like how apache prefork does). One 
process accept()s on the original socket and
the received socket (client socket) will be read for a request. After 
the request is received and parsed this process (the
controller) will choose one from its' children that is most capable of 
handling the said request. It would then pass the
file descriptor through a socketpair to the appropriate children and go 
handle the next client. All works fine and smooth,
but I realized that I need sendmsg()/recvmsg() to pass the FD. Since 
these are not implemented in the python socket
module, and Linux has no other way to do this, I'm stuck. Fell flat on 
my face, too :)


Browsing the net I've found a patch to the python core 
(http://bugs.python.org/issue1194378), dated 2005.


First of all, I would like to ask you guys, whether you know of any way 
of doing this FD passing magic, or that you know

of any 3rd party module / patch / anything that can do this for me.

Since I'm fairly familiar with C and (not that much, but I feel the 
power) python, I would take the challenge of writing
it, given that the above code is still somewhat usable. If all else 
fails I would like to have your help to guide me through

this process.

Thanks

Kalman Gergely
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] python sendmsg()/recvmsg() implementation

2009-06-09 Thread Jean-Paul Calderone

On Tue, 09 Jun 2009 16:46:54 +0200, Kálmán Gergely kalman.gerg...@duodecad.hu 
wrote:

Hello, my name is Greg.

I've just started using python after many years of C programming, and I'm 
also new to the list. I wanted to clarify this

first, so that maybe I will get a little less beating for my stupidity :)



Welcome!



[snip]

Browsing the net I've found a patch to the python core 
(http://bugs.python.org/issue1194378), dated 2005.


First of all, I would like to ask you guys, whether you know of any way of 
doing this FD passing magic, or that you know

of any 3rd party module / patch / anything that can do this for me.


Aside from the patch in the tracker, there are several implementations of
these APIs as third-party extension modules.



Since I'm fairly familiar with C and (not that much, but I feel the power) 
python, I would take the challenge of writing
it, given that the above code is still somewhat usable. If all else fails I 
would like to have your help to guide me through

this process.



What would be great is if you could take the patch in the tracker and get
it into shape so that it is suitable for inclusion.  This would involve
three things, I think:

 1. Write unit tests for the functionality (since the patch itself provides
none)
 2. Update the patch so that it again applies cleanly against trunk
 3. Add documentation for the new APIs

Once this is done, you can get a committer to look at it and either provide
more specific feedback or apply it.

Thanks,

Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] Tags from closed branch heads?

2009-06-09 Thread Dirkjan Ochtman
Sorry about that, got dev-lists mixed up in my head somewhere...

On Tue, Jun 9, 2009 at 16:52, Dirkjan Ochtmandirk...@ochtman.nl wrote:
 So ca8d05e1f1d1 changed the default for repo.heads() to closed=False,
 so that calls to heads() by default will not return closed heads.
 Unfortunately, this also means that any tags from those heads will not
 be considered anymore. That seems inadvertent at best, and may be
 should be reverted. Conceptually, it seems wrong that deleting a
 branch would also delete all the tags from it. I'd like to propose
 this change:

 diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
 --- a/mercurial/localrepo.py
 +++ b/mercurial/localrepo.py
 @@ -320,7 +320,7 @@
     def _hgtagsnodes(self):
         last = {}
         ret = []
 -        for node in reversed(self.heads()):
 +        for node in reversed(self.heads(closed=True)):
             c = self[node]
             rev = c.rev()
             try:

 Is that something we can agree on?

 Cheers,

 Dirkjan

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


[Python-Dev] Rewrite os.popen using subprocess.Popen?

2009-06-09 Thread Nestor
pydoc.py uses os.popen once on line 1359. According to the
documentation that function is deprecated since Python 2.6. Does it
make sense to rewrite that line using the newer subprocess instead?

I am asking because os.popen stopped working for me in Python 3.1 but
I don't know if it is worth investing time in a module that is
deprecated when the newer one does work.

http://bugs.python.org/issue6236
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com


Re: [Python-Dev] python sendmsg()/recvmsg() implementation

2009-06-09 Thread Josiah Carlson
On Tue, Jun 9, 2009 at 7:46 AM, Kálmán
Gergelykalman.gerg...@duodecad.hu wrote:
 Hello, my name is Greg.

 I've just started using python after many years of C programming, and I'm
 also new to the list. I wanted to clarify this
 first, so that maybe I will get a little less beating for my stupidity :)

 I use python3 and Linux on arch x86 (production will be on x86_64, though
 this shouldn't matter much).

 The application that I'm presently working on is a network server. It would
 use separate processes to accept the
 connections, and to do the work (much like how apache prefork does). One
 process accept()s on the original socket and
 the received socket (client socket) will be read for a request. After the
 request is received and parsed this process (the
 controller) will choose one from its' children that is most capable of
 handling the said request. It would then pass the
 file descriptor through a socketpair to the appropriate children and go
 handle the next client. All works fine and smooth,
 but I realized that I need sendmsg()/recvmsg() to pass the FD. Since these
 are not implemented in the python socket
 module, and Linux has no other way to do this, I'm stuck. Fell flat on my
 face, too :)

 Browsing the net I've found a patch to the python core
 (http://bugs.python.org/issue1194378), dated 2005.

 First of all, I would like to ask you guys, whether you know of any way of
 doing this FD passing magic, or that you know
 of any 3rd party module / patch / anything that can do this for me.

IIRC, this is already implemented in the multiprocessing package,
which comes standard with Python 2.6 and 3.0 .

It looks like the test is disabled in test/test_multiprocessing.py ,
and re-enabling it (on Windows) produces errors that make me think
it's more an issue with the tests than with multiprocessing itself.

Dig into it, see if you can get the tests to pass :)

 - Josiah

 Since I'm fairly familiar with C and (not that much, but I feel the power)
 python, I would take the challenge of writing
 it, given that the above code is still somewhat usable. If all else fails I
 would like to have your help to guide me through
 this process.

 Thanks

 Kalman Gergely
 ___
 Python-Dev mailing list
 Python-Dev@python.org
 http://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe:
 http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com