On 24/10/2011 11:46 AM, Nick Coghlan wrote:
On Mon, Oct 24, 2011 at 10:00 AM, Mark Hammond wrote:
* The "magic" symbol is somewhat self-documenting - it implies a question.
Using --which adds another special case that people would need to
understand isn't passed to Python. I
On 24/10/2011 12:56 PM, Michael Urman wrote:
On Sun, Oct 23, 2011 at 17:15, Mark Hammond wrote:
How about abusing the existing flags for this purpose - eg:
% py -3?
% py -2.7?
I would have expected that to launch an interactive python shell of
the appropriate version. Does it do something
+1 from me!
Mark
On 25/10/2011 9:57 AM, Victor Stinner wrote:
Hi,
I propose to raise Unicode errors if a filename cannot be decoded on Windows,
instead of creating a bogus filenames with questions marks. Because this change
is incompatible with Python 3.2, even if such filenames are unusable a
On 29/10/2011 9:52 AM, Victor Stinner wrote:
Hi,
I am not more conviced that raising a UnicodeEncodeError on unencodable
characters is the right fix for the issue #13247. The problem with this
solution is that you have to wait until an user get a UnicodeEncodeError.
I have yet another propositi
On 31/10/2011 8:39 AM, Victor Stinner wrote:
Le 29/10/2011 07:47, Mark Hammond a écrit :
When previously discussing this issue, I was under the impression that
the problem was unencodable bytes passed from the Python code to Windows
- but the reverse is true - only the data coming back from
FWIW, the most recent version of pywin32 has the following download
counts (rounded to the nearest thousand)
Version 32bit 64bit
-
3.2 - 75,000 9,000
3.1 - 4,000 1,000
2.7 - 126,000 16,000
2.6 - 46,000 6,000
2.5 - 21,000 n/a
2.4 -
On 17/02/2012 7:44 PM, Egon Smiwa wrote:
Hi all,
I'm an app developer with a CPython dll in the folder of that app.
In general, are there strict requirements about the dll name
(a preference would be "python.dll" (easy to update (simple replace) ).
I successfully used "python.dll" and a few stand
I'm wondering what thoughts are on PEP 397, the Python launcher for
Windows. I've been using the implementation for a number of months now
and I find it incredibly useful.
To my mind, the specific steps would be:
* Have someone pronounce it as accepted (or suggest steps to be taken
before su
On 18/02/2012 4:37 PM, Brian Curtin wrote:
On Fri, Feb 17, 2012 at 23:24, Mark Hammond wrote:
I'm wondering what thoughts are on PEP 397, the Python launcher for Windows.
I've been using the implementation for a number of months now and I find it
incredibly useful.
To my mind, th
On 18/02/2012 11:08 PM, mar...@v.loewis.de wrote:
Zitat von Mark Hammond :
I'm wondering what thoughts are on PEP 397, the Python launcher for
Windows. I've been using the implementation for a number of months now
and I find it incredibly useful.
I wonder what the rationale for t
On 21/02/2012 2:54 AM, Mark Lawrence wrote:
On 18/02/2012 05:24, Mark Hammond wrote:
...
* Write some user-oriented docs.
The section in the docs "Using Python on Windows" would need to be
updated, but would this have to happen for every current version of Python?
I'm not
On 22/02/2012 2:50 AM, Vinay Sajip wrote:
Mark Hammond gmail.com> writes:
think there is something that could be added to those docs - the use of
PATHEXT and the fact that once the shebang line is in place, a
command-prompt could do just "hello.py" rather than needing "
On 14/03/2012 6:43 AM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
Short version:
1) The layout for the python root directory for all pl
On 15/03/2012 3:03 AM, Lindberg, Van wrote:
On 3/14/2012 1:32 AM, Mark Hammond wrote:
As per comments later in the thread, I'm -1 on including
"python{py_version_short}" in the lib directories for a number of
reasons; one further reason not outlined is that it would potential
[resending - original reply went only to Van]
On 15/03/2012 10:15 AM, Lindberg, Van wrote:
> On 3/14/2012 5:39 PM, Mark Hammond wrote:
>> Can you offer any examples of 3rd party tools which could unify code
>> in this scheme, and particularly, where this scheme would cause them
On 16/03/2012 8:57 AM, VanL wrote:
On 3/14/2012 6:30 PM, Mark Hammond wrote:
So why not just standardize on that new layout for virtualenvs?
That sounds like the worst of all worlds - keep all the existing special
cases, and add one.
I'm not so sure. My concern is that this *will*
On 16/03/2012 10:48 AM, Carl Meyer wrote:
...
The implementation of virtualenv (and especially PEP 405 pyvenv) are
largely based around making sure that the internal layout of a
virtualenv is identical to the layout of an installed Python on that
same platform, to avoid any need to special-case
On 17/03/2012 7:22 AM, Carl Meyer wrote:
...
I don't want to make the internal layout of a virtualenv differ from the
system Python layout on the same platform, which (IIUC) was Mark's proposal.
Just to be clear, I made that suggestion in an effort to keep both
myself and Van - that the Pytho
On 14/03/2012 6:43 AM, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows,
with a side order of making the PATH work better.
...
For the sake of brain-storming, how about this:
* All executabl
On 17/03/2012 12:07 PM, Brian Curtin wrote:
On Fri, Mar 16, 2012 at 19:53, Mark Hammond wrote:
For the sake of brain-storming, how about this:
* All executables and scripts go into the root of the Python install. This
directory is largely empty now - it is mainly a container for other
On 17/03/2012 12:25 PM, Carl Meyer wrote:
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
* All executables and scripts go into the root of the Python install.
This directory is largely empty now - it is mainly a container for other
directories. This would solve the problem of needing 2
For those who missed it, in http://bugs.python.org/issue14302, Martin
recently commented:
"""
After more discussion, it appears that this change is too incompatible
to be done in a single release.
Therefore, I propose a long-term change into this direction, with the
actual change not happeni
On 21/03/2012 1:08 AM, Lindberg, Van wrote:
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
On 13 March 2012 20:43, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
As this is being co
On 21/03/2012 9:45 AM, R. David Murray wrote:
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond
wrote:
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues
On 22/03/2012 1:22 AM, Lindberg, Van wrote:
Mark, MAL, Martin, Tarek,
Could you comment on this?
Eric is correct - tools will be broken by this change. However, people
seem willing to push forward on this and accept such breakage as the
necessary cost.
MAL, in his followup, asks what the
e" above. What would the instructions above now say?
That the user should re-install Python ensuring to set that checkbox?
Cover both cases, including how the user can tell if it is on the PATH
and how to fix it otherwise? Something else?
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim
[snipped some CCs]
On 23/03/2012 2:20 PM, Brian Curtin wrote:
...
I get that tools could be affected. I had two IDE makers at PyCon
immediately throw up red flags to this change. I think one of them was
about to charge the stage during my talk. When it was mentioned that
we could point them to t
On 23/03/2012 7:10 PM, Paul Moore wrote:
On 23 March 2012 03:20, Brian Curtin wrote:
Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have
all expressed that they have existing tools that would break and would need
to be adjusted to match the new location of the python.exe
Vinay originally wrote:
PEP 397 (Python launcher for Windows) has not yet been accepted, so there still
needs to be some way of natively launching scripts in Windows which is
equivalent to /path/to/venv/bin/foo. The way setuptools (and hence Distribute)
does this is to shadow each script with an
Sorry, but I missed the announcement of an updated PEP.
It looks good to me! Also, I see no reason not to always use a 32bit
version of the launcher other than (a) the 64bit code already exists and
works and (b) it might mean it is no longer possible to do a complete
build of a 64bit Python w
On 22/06/2012 8:14 AM, Brian Curtin wrote:
On Wed, Jun 20, 2012 at 11:54 AM, Brian Curtin wrote:
As the PEP czar for 397, after Martin's final updates, I hereby
pronounce this PEP "accepted"!
Thanks to Mark Hammond for kicking it off, Vinay Sajip for writing up
the code, Martin
Sorry for the slightly off-topic post, but I thought it of interest that
Brendan Eich (the "father" of javascript) has blogged about the future of
js, and specifically how he will "borrow from Python for iteration,
generators, and comprehensions" and more generally why he is "standing on
Pythons s
> Roger on python-win32 had an answer which works for me:
>
> [Roger Upole wrote]
> > WMI can list sound devices.
> >
> > import win32com.client
> > wmi=win32com.client.GetObject('winmgmts:')
> > scs=wmi.InstancesOf('win32_sounddevice')
> > for sc in scs:
> > print
> So PythonWin needs to be installed on a Windows buildbot slave, right?
FWIW, we are having reasonable success with buildbot service packaged as a
py2exe application - just unzip into a directory and go! This has the
primary advantage (to me!) of not using the Python installed on the box,
thereb
Tim:
> [Martin]
> > on XP SP2: test_mailbox fails to
> > me, with permission denied in some (random) test. I believe this
> > is due to Tortoise SVN: test_mailbox creates a few directories,
> > then Tortoise detects them (thanks to file change notifications)
> > and tries to walk them, to find out
Bob writes:
> I don't know how JavaScript is doing it yet. The critical thing
> for me for this month was trying to come up with a security model.
I don't fully understand how JS does it either, certainly not in any detail.
I know that it uses the concept of a "principal" (the IDL file can be se
I wrote:
> Bob writes:
Ack - sorry about that - the HTML mail confused me :) It was Brett, of
course.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
> What happened to the CurrentVersion registry entry documented at
>
> http://www.python.org/windows/python/registry.html
>
> AFAICT, even the python15.wse file did not fill a value in this
> entry (perhaps I'm misinterpreting the wse file, though).
>
> So was this ever used? Why is it documented,
> Suppose we run script.py while playground/ is the current directory.
> I'm using 2.4.2 here, but doubt it matters much. No Python-related
> envars are set.
>
> Windows (and the PIL and pywin32 extensions are installed here):
>
> C:\playground>\python24\python.exe someother\script.py
> ['C:\\play
Michiel wrote:
> Guido van Rossum wrote:
>
> >On 11/9/05, Michiel Jan Laurens de Hoon
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >>My application doesn't need a toolkit at all. My problem is that because
> >>of Tkinter being the standard Python toolkit, we cannot have a decent
> >>event loop in Python.
> release. The main reason why I changed the import behavior was
> pythonservice.exe from the win32 extensions. pythonservice.exe imports
> the module that contains the service class, but because
> pythonservice.exe doesn't run in optimized mode, it will only import a
> .py or a .pyc file, not a .
Shane:
> Vinay Sajip wrote:
> > I'd be interested in your approach to solve this.
>
> To be compatible with an external tool like logrotate, all a daemon
> needs to do is close and reopen log files at about the same time log
> rotation happens. To handle this use case, I suggest the logging modul
Guido:
> What a mess. :-(
>
> WindowsError should have used a different name for the Windows-native
> error code, so we could have defined both separately without
> confusion.
>
> Is it too late to change WindowsError in that way?
I guess "too late" is purely a judgement call about breaking existi
201 - 244 of 244 matches
Mail list logo
