Hi all,
I'm not sure if the following is a bug I should report or simply an
artifact of the implementation and/or simply the way things work on py3k:
% py30 -c "str(memoryview(bytearray((1,2,3"
Traceback (most recent call last):
File "", line 1, in
TypeError: __str__ returned non-strin
On 8/02/2009 10:21 AM, Antoine Pitrou wrote:
Mark Hammond gmail.com> writes:
I'm not sure if the following is a bug I should report or simply an
artifact of the implementation and/or simply the way things work on py3k:
[...]
It's a bug.
http://bugs.python.org/issue5182
On 11/03/2009 1:55 PM, Guido van Rossum wrote:
On Tue, Mar 10, 2009 at 7:45 PM, Christian Heimes wrote:
Antoine Pitrou wrote:
Christian Heimes cheimes.de> writes:
...
Let's not think too Unix-specific. If we add such an API it should do
something on Windows too -- the app shouldn't have to
On 25/03/2009 6:51 AM, "Martin v. Löwis" wrote:
Mike Driscoll did some work providing Windows installers for various
Python packages and extension modules, and people were amused that he
provided executable installers for pure Python libraries. But I saw that
as a sensible decision, since it mean
On 25/03/2009 7:34 AM, "Martin v. Löwis" wrote:
I don't quite remember the -n flag, but I believe that Kristjan
just removed all that stuff, ie. there is now no way to block
CRT assertions anymore.
I
wasn't paying close attention, so maybe there's some other mechanism
in place at this point?
On 25/03/2009 10:05 AM, David Bolen wrote:
Kristján Valur Jónsson writes:
Now, I know that this msvc behaviour can be disabled, but it was
decided that it was not appropriate to meddle with runtime flags of
the whole process for python.
I must have missed that discussion, but I can't see wha
On 25/03/2009 7:58 PM, David Bolen wrote:
Mark Hammond writes:
The issue was that Python unconditionally changed the behaviour of the
CRT, not only during the test suite.
Hmm... I was more or less referring to the state of the py3k tree as
of, say, r57823 back in 2007.
I was referring to
I'm going to poke my contacts at Microsoft and ask them if there is a way to
disable popups like this for a process that runs unattended and/or is running
as a windows service.
There is, and Curt pointed out one strategy for achieving this without
losing the checks it provides...
> Curt's
On 28/03/2009 7:49 AM, gl...@divmod.com wrote:
Perhaps bdist_wininst/_msi could be donated to the
py2exe project if they would be willing to maintain it, and the new
project for _deb and _rpm could be called "py2packman" or something.
As mentioned, it isn't really a natural fit - but regardless
On 29/03/2009 1:41 AM, andrew cooke wrote:
Mark Hammond wrote:
On 28/03/2009 9:50 PM, andrew cooke wrote:
Tim Roberts wrote:
[...] IronPython has certainly shown that Python can be successfully
implemented in a JIT compiled VM in a performant way, but it has issues
running C extension
On 6/04/2009 12:13 AM, Dirkjan Ochtman wrote:
I have a stab at an author map at http://dirkjan.ochtman.nl/author-map.
Could use some review, but it seems like a good start.
Just to be clear, what input would you like on that map?
I'm listed twice:
mark.hammond = Mark Hammond
mha
[Dropping email sig]
On 11/04/2009 1:06 PM, "Martin v. Löwis" wrote:
However, I really think that this question cannot be answered by
reading the RFC. It should be answered by verifying how people use
the json library in 2.x.
In the absence of anything more formal, here are 2 anecdotes:
* Th
On 11/04/2009 6:12 PM, Antoine Pitrou wrote:
Martin v. Löwis v.loewis.de> writes:
Not sure whether it would be *significantly* faster, but yes, Bob wrote
an accelerator for parsing out of a byte string to make it really fast;
IIRC, he claims that it is faster than pickling.
Isn't premature o
Larry Hastings wrote:
Counting the votes for http://bugs.python.org/issue5799 :
+1 from Mark Hammond (via private mail)
+1 from Paul Moore (via the tracker)
+1 from Tim Golden (in Python-ideas, though what he literally said
was "I'm up for it")
+1 from Michael F
Eric Smith wrote:
Mark: I've reviewed this and it looks okay to me.
Thanks Eric - I've now applied that patch. As you mentioned in a
followup to the bug:
| Thanks for looking at this, Mark. If we could only assign issues to
| Python 3.2 and 3.3 to change the pending deprecation warning to a
Paul Moore wrote:
2009/6/5 Nick Coghlan :
Dirkjan Ochtman wrote:
Essentially, pcbuild.sln is a binary file, and should be treated as
such. Maybe it's an error in the Subversion setup that it's treated as
text at all...
Yes, it certainly seems that way.
Except it isn't a binary file - it's a t
On 3/07/2009 6:42 AM, Dirkjan Ochtman wrote:
In response to some rumblings on python-committers and just to request
more feedback, a progress report. I know it's long, I've tried to put
to keep it concise and chunked, though.
Although this has come up in the past, I don't recall a resolution.
On 3/07/2009 9:28 PM, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 01:01, Mark Hammond wrote:
Although this has come up in the past, I don't recall a resolution.
What is your plan to handle svn:eol-style? We have some files in the tree
which need that support and it isn't c
On 4/07/2009 12:04 AM, Nick Coghlan wrote:
However, I expect that would still be painful to work with for Windows
developers, even if it prevented any line ending problems from making
their way into the main repository. I believe that is where the
win32text extensions can help. Looking at the Wi
On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote:
On Fri, Jul 3, 2009 at 15:31, Mark Hammond wrote:
So we must work without effective EOL support? I fear we will end up like
the mozilla hg repo with some files in windows line endings and some with
linux. While my editing tools are good enough to
On 3/07/2009 11:43 PM, Dirkjan Ochtman wrote:
As long as the difference between \r\n- and \n-based files is clear
and can be reasoned about, I don't see why having some of both (I'm
assuming an overwhelming majority will have one, and only a few the
other) is a big problem. But feel free to enli
On 4/07/2009 11:20 AM, Nick Coghlan wrote:
I didn't realise Mercurial didn't have a way for a repository to provide
versioned extension settings, but in this case I think using our own
server side hook can deal with the problem (either adding it to the
existing whitespace hook that checks for ta
On 4/07/2009 12:30 PM, Nick Coghlan wrote:
...
I think there needs to be a solid answer in place for these use cases
before the actual migration to Mercurial takes place. A hand-waving "use
win32text" isn't enough - it needs to be "use win32text with these exact
settings" (with server side hook s
Sorry Dirkjan - I just noticed I didn't CC you on this mail originally.
I'm wondering if you have any more thoughts on these EOL issues and if
there is anything I can do to help?
Cheers,
Mark
On 4/07/2009 2:03 PM, Mark Hammond wrote:
On 4/07/2009 12:30 PM, Nick Coghlan wrote:
..
On 4/08/2009 7:20 PM, Nick Coghlan wrote:
Dirkjan Ochtman wrote:
* commit hooks be implemented to enforce this - but this should not be
necessary if the above was implemented and socially enforced.
You seem to advocate a two-step approach: enforce line endings through
win32text, catch any erro
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammond writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of the early commits on that clone introduced "bad" line
end
On 5/08/2009 4:50 PM, Ben Finney wrote:
Mark Hammond writes:
On 5/08/2009 3:56 PM, Ben Finney wrote:
Mark Hammond writes:
Let's say I make a branch of the hg repo, myself and a few others work
on it committing as we go, then attempt to merge back upstream. Let's
say some of
On 5/08/2009 5:35 PM, "Martin v. Löwis" wrote:
Now, the specific outcome of the process means that more work needs to
be done. So we have a *second* PEP, and we have a lack of volunteers
that help implementing it. The second PEP hasn't been approved yet
(as it isn't complete, yet), so migration
On 5/08/2009 6:00 PM, Ben Finney wrote:
Mark Hammond writes:
As already mentioned in this thread, a capability similar to what svn
or cvs offers would be sufficient.
That capability presented by centralised VCSen is entirely dependent on
the fact that they *are* centralised. Using a
On 5/08/2009 6:25 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 01:43, Mark Hammond wrote:
Thanks Nick; I didn't want to be the only one saying that. There is a fine
line between asserting reasonable requirements for Windows users and being
obstructionist and unhelpful, and I'm
On 5/08/2009 7:09 PM, Dirkjan Ochtman wrote:
I'm not sure how win32text will provide anything other than
performance degradation for non-Windows developers, but if there's
functionality to be had, I'm happy to mandate its use on every
platform.
I see two practical outcomes of such a mandate:
*
On 5/08/2009 8:04 PM, Paul Moore wrote:
2009/8/5 "Martin v. Löwis":
With such a setup, using the hook would be truly optional on Unix,
as it only ever checks and never converts. So if you manage to mess
up, and don't have the hook installed on Unix, you lose when trying
to push. That will teac
On 5/08/2009 8:14 PM, Dirkjan Ochtman wrote:
endings. Typically, in my case, that was either Notepad2 (an awesomely
light-weight Notepad replacement) or Komodo (Edit). That solved all of
my issues, so I haven't had a need for win32text so far.
FWIW, I use komodo and scite as my primary editors,
On 5/08/2009 9:28 PM, Dirkjan Ochtman wrote:
On Wed, Aug 5, 2009 at 13:19, Mark Hammond wrote:
Configuring on each clone would certainly be sub-optimal, so the proposal is
this configuration be stored in a versioned file in the repo.
Even if we do that, enabling hg extensions will still need
On 6/08/2009 12:28 AM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> I'm not sure what point you are trying to make, but I believe it *is*
> possible for a solution to be found here which will keep Windows users
> happy. I'm guessing you haven't had much p
nt item here is currently the win32text stuff.
Mark Hammond said he would work on this; Mark, when do you have time
for this? Then I could set apart some time for it as well.
I can make time, somewhat spasmodically, starting fairly soon. Might I
suggest that as a first task I can resurrect my old stale
[Adjusted the CCs...]
On 19/08/2009 8:21 AM, Dj Gilcrease wrote:
On Tue, Aug 18, 2009 at 2:12 AM, "Martin v. Löwis" wrote:
The second item is line conversion hooks. Dj Gilcrease has posted a
solution which he considers a hack himself. Mark Hammond has also
volunteered, but it
On 22/08/2009 12:19 AM, Dirkjan Ochtman wrote:
On Fri, Aug 21, 2009 at 16:10, Dj Gilcrease wrote:
I like this, though maybe .hgextensions since it would contain
versioned rules and the actual required extension. The extra sub
directories are not really required IMHO, you just have a hgrc file
t
On 22/08/2009 12:10 AM, Dj Gilcrease wrote:
On Fri, Aug 21, 2009 at 1:16 AM, Mark Hammond wrote:
Maybe you can enumerate what you think needs to change in mercurial, then
once we have a plan in place it will be clearer who can do what.
The encode/decode hooks need to be passed the filename
On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> Something like ~/.hgrules having:
Surely you mean $PROJECTROOT/.hgrules?
Indeed.
> [config] # or maybe [rules] ?
> required_extensions = win32text, some_pydev_specific_extension
[e
On 22/08/2009 6:52 PM, Stephen J. Turnbull wrote:
Mark Hammond writes:
> On 22/08/2009 2:46 PM, Stephen J. Turnbull wrote:
> Possibly - although I would expect the existing section names be reused
> when applied to a versioned file, I'd be more than happy for the h
On 22/08/2009 7:09 PM, "Martin v. Löwis" wrote:
From my POV, this would be required in some form or another before such
a scheme could actually work. Without it we end up with an improved
win32text (good!)
I still think this would be actually bad.
Instead, a new extension should be written,
On 23/08/2009 5:25 PM, "Martin v. Löwis" wrote:
If this becomes seen as 'my' cause, I suspect it will run out of steam
very quickly. I truly hope python-dev, as a community, takes some
ownership of this issue
That certainly won't happen. python-dev, as a community, has never ever
taken ownersh
nt item here is currently the win32text stuff.
Mark Hammond said he would work on this; Mark, when do you have time
for this? Then I could set apart some time for it as well.
Have stalled a bit on the fine-grained branch processing, hope to move
that forward tomorrow.
I'm afraid I've also s
On 30/08/2009 9:37 PM, Martin Geisler wrote:
Mark Hammond writes:
1) I've stalled on the 'none:' patch I promised to resurrect. While
doing this, I re-discovered that the tests for win32text appear to
check win32 line endings are used by win32text on *all* platforms, not
ju
back to r7713
(1997-04-02). The original implementation checked by Guido and
attributed to Mark Hammond. So, we should ask Mark why he did that.
The thread seems to be at
http://groups.google.com/group/comp.lang.python/browse_frm/thread/be32478a4b8e77b6/816d6228119a3474
(although I do seem to
my flawed reasoning.
For reference:
#if defined(MS_WINDOWS) && !defined(__BORLANDC__)
/* Due to Mark Hammond and Tim Peters */
static PyObject *
time_clock(PyObject *self, PyObject *unused)
{
static LARGE_INTEGER ctrStart;
static double divisor = 0.0;
LARGE_INTEGER n
On 22/10/2009 3:45 PM, Robert Collins wrote:
On Thu, 2009-10-22 at 15:21 +1100, Mark Hammond wrote:
I'd be very surprised if any applications rely on
the fact that each process starts counting at zero, so if someone can
come up with a high-res counter which avoids that artifact I'd
On 4/11/2009 4:35 AM, Guido van Rossum wrote:
I've checked draft (!) PEP 3003, "Python Language Moratorium", into
SVN. As authors I've listed Jesse, Brett and myself.
Good move, +1.
Cheers,
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http
On 15/12/2009 2:07 PM, David Lyon wrote:
Hi Tarek,
Is there anything in this proposal for windows developers ?
Just that I can't see anything that would help us...
So I understand - help doing what?
For me, the terminology isn't anything a windows developer could
really understand. It pres
On 15/12/2009 2:42 PM, David Lyon wrote:
On Tue, 15 Dec 2009 14:40:56 +1100, Mark Hammond
wrote:
I think it is fine. If you are really looking for properties specific
to the operating system (eg, the location of the start menu, desktop,
appdata folders etc)
But under windows, an application
On 15/12/2009 3:09 PM, David Lyon wrote:
On Tue, 15 Dec 2009 15:05:18 +1100, Mark Hammond
wrote:
But under windows, an application developer might (as in probably
would) like to install an application in \Program Files\someapp
rather than hidden in the bowels of the python interpretor.
I
Hi Dirkjan,
On 8/02/2010 8:35 AM, Dirkjan Ochtman wrote:
...
In fact, a few weeks ago I talked to Brett and we figured that we
should probably pin down a deadline. We discussed aiming at May 1, and
at this time I think that should be feasible. That also seems to
coincide with the release of 2.7
On 2/06/2010 11:32 AM, Farshid Lashkari wrote:
Hello,
I noticed that if Py_IgnoreEnvironmentFlag is enabled, the Windows
registry is still used to initialize sys.path during startup. Is this an
oversight or intentional?
I guess it falls somewhere in the middle - the flag refers to the
'enviro
On 4/08/2010 11:08 AM, Steve Holden wrote:
It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.
I wonder if anyone c
On 31/08/2010 7:54 AM, Nick Coghlan wrote:
On Tue, Aug 31, 2010 at 12:47 AM, Michael Foord
wrote:
An extension compiled for one version of Python will be linked against the
version of the C runtime used by that version of Python (if it is compiled
with the same version of Visual Studio of cour
Guido writes:
> As Phillip understood, I meant the environment to include the
> filesystem (and on Windows, the registry -- in fact, Python on Windows
> *has* exactly such a mechanism in the registry, although I believe
> it's rarely used these days -- it was done by Mark Hammond
> Has anyone heard the Python+XUL community cry "I'm not dead
> yet!" or are
> they really dead? I haven't seen mentions of new work in these areas
> lately. XUL in general seems to have died (so many broken
> links on XUL
> pages). Was this just a fad? If not, and if there's some
> really usef
Please add my -1 to the chorus here, for the same reasons already expressed.
Cheers,
Mark
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> ]On Behalf
> Of Jim Jewett
> Sent: Monday, 30 April 2007 1:29 PM
> To: Python 3000; Python Dev
> Subject: [Python-Dev] PE
On 5/03/2011 8:21 AM, "Martin v. Löwis" wrote:
...
As for Windows support: we currently don't install a python3.exe binary,
let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
adjust the installer if the PEP asks me to. For the reasons discussed,
I'm -0 on the change (i.e. doub
On 6/03/2011 12:37 AM, Michael Foord wrote:
On 05/03/2011 07:02, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 10:47 AM, Mark
Hammond wrote:
I think this discussion should be divorced from this PEP and taken up
with
the discussion about the PATH and the "last installed wins" issue Marti
On 6/03/2011 11:51 PM, Dj Gilcrease wrote:
> Why not modify the windows installers to install into C:\Python\X.Y
> and have the .bat files generated in C:\Python which is what I have
> been doing manually since py25. I just add C:\Python to the system
> Path then create/modify the bat files for ne
On 7/03/2011 1:55 AM, Paul Moore wrote:
On 6 March 2011 02:33, Mark Hammond wrote:
IIUC, the PEP language is referring to links which point to a specific
version of Python and that there is no suggestion a 'python3' will live in
the Python 3 binary tree. If that is correct and a
On 7/03/2011 10:04 AM, Michael Foord wrote:
Paul Moore was +1 on Windows being included. Mark did accept that some
of the changes were "desirable", but was also concerned they didn't
address all the issues on Windows. I *would* like to see all the issues
addressed but I think that is outside the
On 7/03/2011 3:30 PM, Glenn Linderman wrote:
I'm only against the overhead of a helper written in Python, since it
would have to launch Python (some explicit version) to run the helper
script, and then launch the "right" version of Python to execute the
real script. You mention a thin executable
On 7/03/2011 4:34 PM, Nick Coghlan wrote:
On Mon, Mar 7, 2011 at 3:19 PM, Mark Hammond wrote:
Without putting too much thought into it, I think a simple scheme could work
where the path must either be "/usr/bin/python[23]?" or a fully-qualified
path to a Python executable. IIUC, t
On 7/03/2011 9:33 PM, Paul Moore wrote:
That sounds like a fairly cool idea. So if I follow what you're
suggesting, we'd have a single python.exe, probably installed in
system32, which did the necessary command line juggling and shebang
parsing, then simply redirected to the appropriate Python in
On 8/03/2011 7:33 AM, Michael Foord wrote:
A python launcher as you describe is a *great* idea.
A few concerns:
* we're missing an opportunity to do something easy (Martin is happy to
modify the installer and says it is easy) for something that may or may
not happen
Don't let my -0 stop anyon
On 8/03/2011 10:15 AM, Greg Ewing wrote:
Mark Hammond wrote:
Yup - although I think a pythonw.exe launcher would be needed too
Couldn't the launcher look at the extension of the file being
launched to decide about this?
Nope - the launcher itself must be marked as "console&qu
On 9/03/2011 1:43 PM, Glenn Linderman wrote:
I'm of the opinion that attempting to parse a Unix #! line, and intuit
what would be the equivalent on Windows is unnecessarily complex and
error prone, and assumes that the variant systems are configured using
the same guidelines (which the Python com
On 9/03/2011 5:05 PM, Glenn Linderman wrote:
Standard installation paths are accepted by about 99% of the users, so
embedding standard installation paths can work well for that batch of
users. Of course, Windows changes the standard path periodically, so
that it different from versions prior to
These issues are best put in the tracker so they don't get lost -
especially at the moment with lots of regulars at pycon.
It would also be good to know if there is an actual behaviour bug caused
by this (ie, what problems can be observed which are caused by the
current code?)
Cheers,
Mark
ions to reference it).
Thanks,
Mark
PEP: ??
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond
Status: Draft
Type: Standards Track or Informational ?
Content-Type: text/x-rst
Created: 15-Mar-2011
Abstract
This PEP describes a Python lau
Thanks for the feedback!
On 19/03/2011 7:44 PM, Glenn Linderman wrote:
Not all of the ideas below are complementary to each other, some are
either or, to allow different thoughts to be inspired or different
directions to be taken.
Thanks for starting a PEP.
On 3/18/2011 11:02 PM, Mark Hammond
On 20/03/2011 4:15 AM, Dj Gilcrease wrote:
On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman wrote:
2) If the launcher provides command line options for the "benefit" of
launching interactive Python interpreters, those command line options can
have data puns with script names, or can conflict
On 20/03/2011 5:49 AM, "Martin v. Löwis" wrote:
* Is this really PEP material, or will turning the PEP into a regular
spec be suitable?
It's PEP material if it is contentious, which I believe it is.
Of course it is - this is python-dev .
I, for example, will find issues with it if the imple
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
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'.
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
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 spec
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
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
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 i
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 t
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
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
On 21/03/2011 1:04 PM, "Martin v. Löwis" wrote:
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?)
OK, I'll check it in once I get a PEP number allocated as per PEP1,
updated to reflect some of the discussions in this th
On 22/03/2011 12:04 AM, Paul Moore wrote:
I haven't had time to read the PEP yet, so my apologies if this is
made explicit there, but is the launcher expected to be solely for
implementing file associations? I thought there had been discussions
of using it to start the interactive interpreter, an
On 22/03/2011 8:09 AM, Barry Warsaw wrote:
I started an Informational PEP on this at Pycon, and will try to finish a
draft of it this week. (I'm claiming 396 for it.)
We nearly had a race for that number! FYI, I just checked in pep-0397
leaving 396 for you :)
Cheers,
Mark
_
think and what objections/comments/etc remain.
Thanks,
Mark
PEP: 397
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond
Status: Draft
Type: Standards Track or Informational ?
Content-Type: text/x-rst
Created: 15-Mar-2011
Abstract
This PEP describ
On 23/03/2011 6:12 AM, Michael Foord wrote:
On 22/03/2011 07:21, Mark Hammond wrote:
Hi all,
I've made some changes to the draft PEP and checked it into the PEP
repository as PEP397. The reference implementation is currently being
tracked at http://bugs.python.org/issue11629.
Hey Mark,
On 24/03/2011 4:34 AM, Ethan Furman wrote:
Michael Foord wrote:
To be honest I would be happy with registry entries instead as the
alternative implementations can then add to their installers (or
provide a script) to add the right registry entry.
I'm partial to the config file method myself. I
On 24/03/2011 1:20 PM, Michael Foord wrote:
On 24/03/2011 00:44, Dj Gilcrease wrote:
On Wed, Mar 23, 2011 at 8:14 PM, Mark
Hammond wrote:
If you guys (or anyone) would like to agree on some precise rules for
both
the location of the config file and its contents and express this as
a patch
to
I'm wondering if it is a reasonable idea to have .hgignore exclude all
files from 'Lib/site-packages' and 'Scripts'? As I install packages
into my source builds, a 'hg status' lists *many* files in both those
directories forcing me to scroll up a number of pages to see files which
have actuall
On 30/03/2011 12:09 PM, R. David Murray wrote:
On Wed, 30 Mar 2011 11:11:45 +1100, Mark Hammond
wrote:
I'm wondering if it is a reasonable idea to have .hgignore exclude all
files from 'Lib/site-packages' and 'Scripts'? As I install packages
into my source builds,
On 30/03/2011 1:37 PM, R. David Murray wrote:
On Wed, 30 Mar 2011 12:17:05 +1100, Mark Hammond
wrote:
On 30/03/2011 12:09 PM, R. David Murray wrote:
The solution is to add such
directories and/or files to your personal ignore list See the 'ignore'
entry under 'ui' in th
Hi,
There are a couple of changes I'd like to make and would like some
guidance on policy:
http://bugs.python.org/issue6498 is a documentation bug which exists in
Python 2.6 and later. The patch in that bug touches the docs and a
comment in one source file. Is it acceptable to push that c
On 2/05/2011 9:27 PM, Ned Batchelder wrote:
...
Maybe the fact no one noticed the docs
were wrong proves that no one ever tried returning None from a local
trace function.
Or if they did, they should have complained by now. IMO, if the
behaviour regresses from how it is documented and how it
: 397
Title: Python launcher for Windows
Version: $Revision$
Last-Modified: $Date$
Author: Mark Hammond
Status: Draft
Type: Standards Track
Content-Type: text/plain
Created: 15-Mar-2011
Post-History: 17-May-2011, 15-Mar-2011
Abstract
This PEP describes a Python launcher for the Windows platf
On 30/06/2011 3:00 AM, Vinay Sajip wrote:
PEP 397 (Python launcher for Windows) has a reference implementation in Python.
Does anyone know of a C implementation, or is planning/working on one? I realise
this is the final objective, so such implementation might be premature, but
perhaps someone ha
1 - 100 of 244 matches
Mail list logo
