[Python-Dev] [GSoC] Porting on RPM3

Hello, My name is Prashant Kumar and I've worked on porting few python libraries(distutils2, configobj) and I've been looking at the ideas list for GSoC for a project related to porting. I came across [1] and found it interesting. It mentions that some of the work has already been done;

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

Guido van Rossum wrote: Cython feels much less mature than CPython; but the latter should only have dependencies that themselves change even slower than CPython. You might be slightly more amenable to Pyrex, then, which changes at a much more conservative pace! They appear superficially simila

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 21/03/2011 3:50 PM, Greg Ewing wrote: Martin v. Löwis wrote: Windows doesn't support exec. Hmmm. In that case, if the launcher works by loading a pythonXY.dll, I'd say that sys.executable should point to whatever version of python.exe corresponds to that dll. Generally, things should be m

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

s...@pobox.com writes: > Stephen> interactions across modules. That is, it's not that Subversion > Stephen> provided a simpler way of doing the work. Rather, it hid the > Stephen> fact that certain work was not being done at all. hg exposes > Stephen> this fact. > Can you

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

Martin v. Löwis wrote: Windows doesn't support exec. Hmmm. In that case, if the launcher works by loading a pythonXY.dll, I'd say that sys.executable should point to whatever version of python.exe corresponds to that dll. Generally, things should be made to look as much as possible as if that

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

In article <4d86be29.8070...@netwok.org>, Éric Araujo wrote: > Le 20/03/2011 02:59, Ned Deily a écrit : > > On a Unix-y system, here is one way to do it (no warranty on the > > installation instructions!): > With all due respect, the instructions are overly complicated, and may > also run afoul

[Python-Dev] Deprecating non-Py_ssize_t use of PyArg_ParseTuple

Since Python 2.5, we maintain two versions of PyArg_ParseTuple: one outputting int; the other one outputting Py_ssize_t. The former should have been removed in 3.0, but this was forgotten. Still, I would like people to move over to the new version, so that extension modules will typically support

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

Le 20/03/2011 02:59, Ned Deily a écrit : > On a Unix-y system, here is one way to do it (no warranty on the > installation instructions!): With all due respect, the instructions are overly complicated, and may also run afoul of the system conventions (sudo will put files in directories that shoul

Re: [Python-Dev] Hg: inter-branch workflow

> I have been avoiding hg import because my understanding is that it > defaults to commit, and I don't see that it has any advantage over patch > itself. “hg import” understands the extended diff format, which patch does not. (That format has been described a number of times already, see http://me

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On Sun, Mar 20, 2011 at 1:59 PM, Stefan Behnel wrote: > [warning, long post ahead] [all snipped] Thanks for the clarifications. I now have a much better understanding of what Cython is. But I'm not sold. For one, your attitude about strict language compatibility worries me when it comes to the st

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

On Sun, Mar 20, 2011 at 12:40 PM, R. David Murray wrote: > On Mon, 21 Mar 2011 03:44:34 +0900, "Stephen J. Turnbull" > wrote: >> I'm coming to the conclusion that those who say that Mercurial >> documentation should be found at the Mercurial project are wrong.  I > > +1.  I think the dev docs sh

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On Sun, Mar 20, 2011 at 6:27 PM, "Martin v. Löwis" wrote: > > I'm primarily bothered about the failure to implement TerminateProcess > correctly. I don't actually know what use cases would be affected, other > then saying that anything launching py.exe could be affect, in > particular applications

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

> I personally would conclude that the last option is the least worst > scenario by a wide margin. Ok, I let this rest. Can you please add a summary of this discussion to the PEP? (also, can you please check in the PEP, and give it a number?) Thanks, Martin ___

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 21/03/2011 12:27 PM, "Martin v. Löwis" wrote: I remain -1 on any proposal that uses subprocesses. It absolutely must be the launcher that is running Python. In fact, I'd call it "python.exe". For clarity, could you please tell us which scenarios you have in mind that cause you to take that p

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

>> I remain -1 on any proposal that uses subprocesses. It absolutely must >> be the launcher that is running Python. In fact, I'd call it >> "python.exe". > > For clarity, could you please tell us which scenarios you have in mind > that cause you to take that position, and why those scenarios coul

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 21/03/2011 11:15 AM, "Martin v. Löwis" wrote: Am 21.03.2011 00:43, schrieb Greg Ewing: Mark Hammond wrote: The above raises an interesting question - if the launcher executed Python in-process, what would sys.executable be? I think it should be the actual Python executing at that moment,

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 3/20/2011 6:35 PM, Westley Martínez wrote: On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote: As both a writer and reader, I would like to just add, for instance, #! python3 (or 3.3 or whatever) and have the launcher do the 'right thing'. It seems to me that that really should be enoug

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

>> In addition to Martin's point, this approach would mean the exit code >> of the child process probably isn't available to whoever started the >> launcher. > > Maybe I've missed something in this discussion, but is there > any reason the launcher can't just exec the relevant python? Windows doe

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 21/03/2011 11:10 AM, "Martin v. Löwis" wrote: Am 21.03.2011 00:52, schrieb Mark Hammond: On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote: The above raises an interesting question - if the launcher executed Python in-process, what would sys.executable be? I can imagine there are few scenario

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

Mark Hammond wrote: In addition to Martin's point, this approach would mean the exit code of the child process probably isn't available to whoever started the launcher. Maybe I've missed something in this discussion, but is there any reason the launcher can't just exec the relevant python? Th

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

Am 21.03.2011 00:43, schrieb Greg Ewing: > Mark Hammond wrote: > >> The above raises an interesting question - if the launcher executed >> Python in-process, what would sys.executable be? > > I think it should be the actual Python executing at that > moment, not the launcher. This is the least ch

Re: [Python-Dev] Hg: inter-branch workflow

On 21 March 2011 08:16, Tim Delaney wrote: > > For the second and later merges: > > hg update 1234_merged_with_3.2 > hg merge 3.2 > hg commit -m "Merged 3.2 to 1234_merged_with_3.2" > hg merge 1234 > hg commit -m "Merged 1234 to 1234_merged_with_3.2" > Of course, you should probably do the "hg m

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

Am 21.03.2011 00:52, schrieb Mark Hammond: > On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote: >>> The above raises an interesting question - if the launcher executed >>> Python in-process, what would sys.executable be? I can imagine there >>> are few scenarios where it would be desirable to have i

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

>> #! python3 [...] > That would break the whole point of platform-independence. a) the PEP makes no point about platform-independence. it is a pure Windows thing, and has no stated objective to being platform-independent. So loss of platform-independence may not be deliberate, but is cer

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 21/03/2011 10:32 AM, "Martin v. Löwis" wrote: The above raises an interesting question - if the launcher executed Python in-process, what would sys.executable be? I can imagine there are few scenarios where it would be desirable to have it refer to the launcher and a number of scenarios where

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

Mark Hammond wrote: The above raises an interesting question - if the launcher executed Python in-process, what would sys.executable be? I think it should be the actual Python executing at that moment, not the launcher. This is the least change from current behaviour and therefore least likely

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On Sun, 20 Mar 2011 15:35:02 -0700, Westley =?ISO-8859-1?Q?Mart=EDnez?= wrote: > On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote: > > On 3/20/2011 3:22 AM, Glenn Linderman wrote: > > On 3/19/2011 7:38 PM, Mark Hammond wrote: > > [snip] > > > > As both a writer and reader, I would like to ju

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

> The above raises an interesting question - if the launcher executed > Python in-process, what would sys.executable be? I can imagine there > are few scenarios where it would be desirable to have it refer to the > launcher and a number of scenarios where it would be undesirable and > possibly bre

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On Sun, 2011-03-20 at 05:36 -0400, Terry Reedy wrote: > On 3/20/2011 3:22 AM, Glenn Linderman wrote: > On 3/19/2011 7:38 PM, Mark Hammond wrote: > [snip] > > As both a writer and reader, I would like to just add, for instance, > > #! python3 > > (or 3.3 or whatever) and have the launcher do the

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On Sun, Mar 20, 2011 at 1:56 PM, "Martin v. Löwis" wrote: > So if somebody would launch a python script with py.exe, they would > think it was completed even though it would still be running. Yes py.exe exits way before the python script, but the console stays open, though now that I test it by r

Re: [Python-Dev] Hg: inter-branch workflow

On 20.03.2011 18:32, Thomas Wouters wrote: > > > On Sun, Mar 20, 2011 at 17:59, Georg Brandl > wrote: > > On 20.03.2011 16:50, Thomas Wouters wrote: > > > > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > >

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 20/03/2011 11:56 PM, Dj Gilcrease wrote: ... Before Mark wrote up this pep I had started experimenting with how to make the launcher and I was able to get it to launch python while exiting py.exe and as far as I could tell it behaved just as if I had launched the app directly by double clickin

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

Following up myself here... On 20/03/2011 9:25 PM, Mark Hammond wrote: On 20/03/2011 8:37 PM, "Martin v. Löwis" wrote: ... Some of these uses probably shouldn't use the launcher directly - eg, ISAPI apps and COM objects which have a separate registration step could register a specific python.exe

Re: [Python-Dev] Hg: inter-branch workflow

On Mon, Mar 21, 2011 at 2:59 AM, Georg Brandl wrote: > Well, YMMV.  But instead of spreading FUD you might want to state *why*. David isn't the only one this kind of thing blew up on during the sprints (although in my case, it may have been "hg rollback" rather than rebasing). Essentially, if us

Re: [Python-Dev] Hg: inter-branch workflow

Thomas Wouters writes: > On Sun, Mar 20, 2011 at 17:59, Georg Brandl wrote: > > On 20.03.2011 16:50, Thomas Wouters wrote: > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > > > wrote: > > > > > > The reason why rebasing is not universally applied is that the >

Re: [Python-Dev] Hg: inter-branch workflow

On 21 March 2011 04:32, Thomas Wouters wrote: > > Merging and merge changesets are a fact of DVCSes, and while I (as a grumpy > luddite misanthrope) greatly prefer the automatic (and mostly silent) merge > as BitKeeper does it, in the long run the actual merging and the merge > changesets are una

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

[warning, long post ahead] Guido van Rossum, 20.03.2011 17:17: Hi Stefan, Hi! I'm glad to see Cython picking up steam and trying to compete with CPython, PyPy, and possibly others. We do, although our main focus is much more on targeted manual optimisation rather than whole applications.

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

Terry> What you felt like doing after doing the rest;-? I still f*cked everything up. R. David Murray came to my rescue. Even he muffed it and had to backtrack I think, at least based on one of the comments I saw on one of the involved tracker issues. Skip _

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

Stephen> Subversion merges create new versions in the repository that Stephen> *never existed in any developer's workspace* and therefore was Stephen> never tested before committing. This is somewhat mitigated by Stephen> buildbot testing, but that is mostly unit testing and S

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

On Mon, 21 Mar 2011 03:44:34 +0900, "Stephen J. Turnbull" wrote: > I'm coming to the conclusion that those who say that Mercurial > documentation should be found at the Mercurial project are wrong. I +1. I think the dev docs should explain anything needed to do the basic Python workflow, even

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

Jesus Cea writes: > I think we are doing some antipatterns with our current approach, > battling the tools instead of "joining them". Yes. That is deliberate; see PEP 0374. I admit I personally didn't foresee the issues Nick describes with the flow of patches from one branch to another. Also

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

What you felt like doing after doing the rest;-? I believe your question and its answers have helped me understand hg better for when I dive in. Thanks. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mail

Re: [Python-Dev] Hg: inter-branch workflow

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/20/2011 5:06 AM, R. David Murray wrote: > On Thu, 17 Mar 2011 14:33:00 +0100, wrote: >> On Thu, 17 Mar 2011 09:24:26 -0400 >> "R. David Murray" wrote: >>> >>> It would be great if rebase did work with share, that would make a >>> push race basic

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 20/03/2011 09:58, Mark Hammond wrote: On 20/03/2011 8:36 PM, Terry Reedy wrote: On 3/20/2011 3:22 AM, Glenn Linderman wrote: On 3/19/2011 7:38 PM, Mark Hammond wrote: [snip] As both a writer and reader, I would like to just add, for instance, #! python3 (or 3.3 or whatever) and have the la

Re: [Python-Dev] Avoiding whitespace conflicts

On 20.03.2011 18:05, s...@pobox.com wrote: > > Ben> Ned Deily writes: > >> As a side note, if you are prone to accidentally adding extra > >> whitespace (like I am), you can add the whitespace check hook into > >> your local copy of Mercurial so that you will be warned about >

Re: [Python-Dev] Avoiding whitespace conflicts (was: I am now lost - committed, pulled, merged, what is "collapse"?)

Ben> Ned Deily writes: >> As a side note, if you are prone to accidentally adding extra >> whitespace (like I am), you can add the whitespace check hook into >> your local copy of Mercurial so that you will be warned about >> whitespace problems immediately when you commit thi

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

> Before Mark wrote up this pep I had started experimenting with how to > make the launcher and I was able to get it to launch python while > exiting py.exe and as far as I could tell it behaved just as if I had > launched the app directly by double clicking it. In this code, py.exe terminates way

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

Antoine Pitrou, 20.03.2011 15:51: On Sun, 20 Mar 2011 14:39:20 +0100, Stefan Behnel wrote: If anyone knows about a good benchmark for a currently pure Python standard library module, preferably a smaller, self-contained one that's somewhat computationally intensive, I'd be happy to hear about i

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, Mar 20, 2011 at 17:59, Georg Brandl wrote: > On 20.03.2011 16:50, Thomas Wouters wrote: > > > > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > > wrote: > > > > The reason why rebasing is not universally applied is that the > > rebased changesets are di

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On 3/20/2011 10:51 AM, Antoine Pitrou wrote: On Sun, 20 Mar 2011 14:39:20 +0100 Stefan Behnel wrote: If anyone knows about a good benchmark for a currently pure Python standard library module, preferably a smaller, self-contained one that's somewhat computationally intensive, I'd be happy to h

Re: [Python-Dev] Hg: inter-branch workflow

On 20.03.2011 16:50, Thomas Wouters wrote: > > > On Sun, Mar 20, 2011 at 17:39, Georg Brandl > wrote: > > The reason why rebasing is not universally applied is that the > rebased changesets are different from the original ones (therefore > I wrote A' and B')

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, Mar 20, 2011 at 17:39, Georg Brandl wrote: > The reason why rebasing is not universally applied is that the > rebased changesets are different from the original ones (therefore > I wrote A' and B') -- even if the diff is the same, the parents > are not, and therefore the changeset id (has

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, 20 Mar 2011 16:39:50 -, Georg Brandl wrote: > The reason why rebasing is not universally applied is that the > rebased changesets are different from the original ones (therefore > I wrote A' and B') -- even if the diff is the same, the parents > are not, and therefore the changeset id

Re: [Python-Dev] Hg: inter-branch workflow

On 20.03.2011 16:39, Georg Brandl wrote: > The reason why rebasing is not universally applied is that the > rebased changesets are different from the original ones (therefore > I wrote A' and B') -- even if the diff is the same, the parents > are not, and therefore the changeset id (hash) changes.

Re: [Python-Dev] Hg: inter-branch workflow

On 20.03.2011 16:21, Guido van Rossum wrote: > What is "rebase"? Why does everyone want it and hate it at the same time? Basically, rebase is a way to avoid having pointless merge commits on the same branch. Let's say you have the following history in your local repository: ... --- X --- A --- B

Re: [Python-Dev] [Python-checkins] Would someone please help me merge these changes to other branches?

On Sun, 20 Mar 2011 10:10:02 -0500, s...@pobox.com wrote: > > I pushed two changes to cpython yesterday and today. I don't know how to > > merge them to the 2.7 and 3.2 branches, and don't want to even try for > > fear of screwing something up. If what I read in python-dev yesterday is > > correc

Re: [Python-Dev] Hg: inter-branch workflow

What is "rebase"? Why does everyone want it and hate it at the same time? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.or

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

Hi Stefan, I'm glad to see Cython picking up steam and trying to compete with CPython, PyPy, and possibly others. It's true that few in the core development group know much about Cython -- essentially my own understanding is still that it's like Pyrex, which was a mostly-Python-compatible syntax f

Re: [Python-Dev] Hg: inter-branch workflow

Le dimanche 20 mars 2011 à 11:52 -0400, R. David Murray a écrit : > On Sun, 20 Mar 2011 00:06:01 -0400, "R. David Murray" > wrote: > > It would have been nice if rebase had refused to run given that > > there were merges, since it clearly doesn't work in that case. > > To clarify, that should ha

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, 20 Mar 2011 00:06:01 -0400, "R. David Murray" wrote: > It would have been nice if rebase had refused to run given that > there were merges, since it clearly doesn't work in that case. To clarify, that should have read "given that there were merges *between branches*". Cleaning merges on

Re: [Python-Dev] Hg: inter-branch workflow

On Sun, 20 Mar 2011 12:17:25 +0100, Antoine Pitrou wrote: > Le dimanche 20 mars 2011 à 00:06 -0400, R. David Murray a écrit : > > On Thu, 17 Mar 2011 14:33:00 +0100, wrote: > > > On Thu, 17 Mar 2011 09:24:26 -0400 > > > "R. David Murray" wrote: > > > > > > > > It would be great if rebase did w

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 20 March 2011 09:58, Mark Hammond wrote: > On 20/03/2011 8:36 PM, Terry Reedy wrote: >> >> On 3/20/2011 3:22 AM, Glenn Linderman wrote: >> On 3/19/2011 7:38 PM, Mark Hammond wrote: >> [snip] >> >> As both a writer and reader, I would like to just add, for instance, >> >> #! python3 >> >> (or 3.

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On Sun, 20 Mar 2011 14:39:20 +0100 Stefan Behnel wrote: > > If anyone knows about a good benchmark for a currently pure Python standard > library module, preferably a smaller, self-contained one that's somewhat > computationally intensive, I'd be happy to hear about it. You can take a look at

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On Sun, Mar 20, 2011 at 9:39 AM, Stefan Behnel wrote: > Jesse Noller, 20.03.2011 13:51: >> >> ...snip >> >>> IMHO, taking modules that currently only have a C implementation due to >>> performance constraints and rewriting them in Cython is a much more >>> worthwhile thing to do than adding an alt

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

Jesse Noller, 20.03.2011 13:51: ...snip IMHO, taking modules that currently only have a C implementation due to performance constraints and rewriting them in Cython is a much more worthwhile thing to do than adding an alternative pure Python implementation that other Python runtimes wouldn't us

Re: [Python-Dev] I am now lost - committed, pulled, merged, what is "collapse"?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19/03/11 19:59, Raymond Hettinger wrote: > I think if we're going to require a complex workflow, then we're > going to have to expect a lot of questions. And those questions > shouldn't be brushed-off with "go read the tutorial, we have no time > f

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On Sun, Mar 20, 2011 at 5:37 AM, "Martin v. Löwis" wrote: > I see three problems with creating child processes: > - WaitForSingleObject and GetExitProcessCode must work correctly. I >  think this is possible to achieve > - applications using the debug API, PSAPI, etc. will be confused if >  the ac

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

...snip > IMHO, taking modules that currently only have a C implementation due to > performance constraints and rewriting them in Cython is a much more > worthwhile thing to do than adding an alternative pure Python implementation > that other Python runtimes wouldn't use anyway. And at least Iron

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On Sun, Mar 20, 2011 at 7:40 AM, Antoine Pitrou wrote: > On Sun, 20 Mar 2011 07:32:34 -0400 > Jesse Noller wrote: >> >> The reason why there was no mention is probably because no one >> intimately familiar with Cython was there, and if they were - it was >> not brought up. If Cython supports PyPy

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

Antoine Pitrou, 20.03.2011 12:40: On Sun, 20 Mar 2011 07:32:34 -0400 Jesse Noller wrote: The reason why there was no mention is probably because no one intimately familiar with Cython was there, and if they were - it was not brought up. If Cython supports PyPy - and Jython, and IronPython, your

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

Jesse Noller, 20.03.2011 12:32: On Sun, Mar 20, 2011 at 7:19 AM, Stefan Behnel wrote: It appears that there has been little mention of Cython at the summit, despite of the speed of CPython being a major topic, according to the notes. I can see several areas where Cython could help in speeding up

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On Sun, 20 Mar 2011 07:32:34 -0400 Jesse Noller wrote: > > The reason why there was no mention is probably because no one > intimately familiar with Cython was there, and if they were - it was > not brought up. If Cython supports PyPy - and Jython, and IronPython, > your proposal makes sense. The

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

On Sun, Mar 20, 2011 at 7:19 AM, Stefan Behnel wrote: > Nick Coghlan, 12.03.2011 12:43: >> >> I posted my rough notes and additional write-ups for Wednesday's VM >> summit and Thursday's language summit: >> >> >> http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html >> >> htt

Re: [Python-Dev] VM and Language summit info for those not at Pycon (and those that are!)

Nick Coghlan, 12.03.2011 12:43: I posted my rough notes and additional write-ups for Wednesday's VM summit and Thursday's language summit: http://www.boredomandlaziness.org/2011/03/python-vm-summit-rough-notes.html http://www.boredomandlaziness.org/2011/03/python-vm-summit-somewhat-coherent.html

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

Terry Reedy writes: > As both a writer and reader, I would like to just add, for instance, > > #! python3 > > (or 3.3 or whatever) and have the launcher do the 'right thing'. It > seems to me that that really should be enough info for *nix, For clarity: the reason it's not enough information is

Re: [Python-Dev] Hg: inter-branch workflow

Le dimanche 20 mars 2011 à 00:06 -0400, R. David Murray a écrit : > On Thu, 17 Mar 2011 14:33:00 +0100, wrote: > > On Thu, 17 Mar 2011 09:24:26 -0400 > > "R. David Murray" wrote: > > > > > > It would be great if rebase did work with share, that would make a > > > push race basically a non-issue

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 20/03/2011 8:37 PM, "Martin v. Löwis" wrote: ... ... problems with creating child processes: - applications using the debug API, PSAPI, etc. will be confused if the action all happens in a child process. I can accept that they have to adjust, though. Some of these uses probably shouldn

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 20/03/2011 8:36 PM, Terry Reedy wrote: On 3/20/2011 3:22 AM, Glenn Linderman wrote: On 3/19/2011 7:38 PM, Mark Hammond wrote: [snip] As both a writer and reader, I would like to just add, for instance, #! python3 (or 3.3 or whatever) and have the launcher do the 'right thing'. If there wa

Re: [Python-Dev] PyLongObject "safe" changes?

> Is it thread / interpreter safe or something dirty can happen? It is safe, thanks to the global interpreter lock (a.k.a. GIL). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubsc

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

>>> Does it also support loading a different interpreter version than the >>> one it is running? >> >> Ouch, no. I guess you're right, any Python based solution will need to >> create a child process. > > Why would that be true? Shouldn't this launcher just be a basic wrapper > that cobbles togeth

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

> Out of curiosity, what is your objection to having the child process? I > guess it must be the system resources needed for the parent process > while it waits for the child to terminate so the exit code can be > reflected correctly "up stream"? I see three problems with creating child processes

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 3/20/2011 3:22 AM, Glenn Linderman wrote: On 3/19/2011 7:38 PM, Mark Hammond wrote: [snip] As both a writer and reader, I would like to just add, for instance, #! python3 (or 3.3 or whatever) and have the launcher do the 'right thing'. It seems to me that that really should be enough info fo

[Python-Dev] PyLongObject "safe" changes?

Hi I have little knowledge of some Python (3.2) internals on objects' internal structure handling. Suppose that I have any PyLongObject object (even internal / shared ones) and that - I need to change some or all of its internal values (size, sign, digits) in a "critical section"; - the critical

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 20/03/2011 6:22 PM, Glenn Linderman wrote: On 3/19/2011 7:38 PM, Mark Hammond wrote: ... A Windows user who has only learned Python 2.x programming would not necessarily have ever heard of execve, would not realize execve(2) means it is from the 2nd chapter of the Unix man pages, meaning an

Re: [Python-Dev] Draft PEP and reference implementation of a Python launcher for Windows

On 3/19/2011 7:38 PM, Mark Hammond wrote: Thanks for the feedback! And thanks for more complete explanations. Sadly I was offline when writing my first response, and couldn't view the man page for execve you referred to. Having just read it, I think it would be total gibberish to a Windows