Re: [Python-Dev] Cannot set PYTHONPATH with big paths with Python 3.0 and 3.1
Martin v. Löwis 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 [email protected] 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
Hi, 2009/6/9 Antoine Pitrou : > Martin v. Löwis 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 [email protected] 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
On Mon, Jun 8, 2009 at 11:01 PM, "Martin v. Löwis" 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] xmlrpc and http/1.1
Hello there. I've been doing some work on xmlrpc for CCP in the last weeks. I'm trying to communicate the results of this back to the python trunk. I've had the following issues open for a while now: http://bugs.python.org/issue6096 http://bugs.python.org/issue6099 I would appreciate some comments on this. Moving forward, I'd like to add support for the "gzip" content encoding for XMLRPC requests and responses. K ___ Python-Dev mailing list [email protected] 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?
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
[email protected]
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
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 [email protected] 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
On Tue, 09 Jun 2009 16:46:54 +0200, Kálmán Gergely 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 [email protected] 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?
Sorry about that, got dev-lists mixed up in my head somewhere...
On Tue, Jun 9, 2009 at 16:52, Dirkjan Ochtman 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
[email protected]
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?
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 [email protected] 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
On Tue, Jun 9, 2009 at 7:46 AM, Kálmán Gergely 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 > [email protected] > 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
