Paul Moore wrote:
> On 23/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> I really like to throw out the old junk to have a clean script. Maybe I
>> could leave the old msvccompiler alone and put the new code into
>> distutils.msvc9compiler?
>
> That might work. I'm not sure if throwing th
Paul Moore wrote:
> I have just built the current trunk version of Python on Windows,
> using the new PCBuild9 directory, and Visual Studio 2008 Express
> Edition.
>
> Everything went extremely well. I include below my notes on what I
> did, for reference. To be honest, there's nothing in here tha
Neil Toronto wrote:
> Aside:
>
> Nick Coghlan wrote:
>> My main concern is that the import lock is something Python users
>> typically don't have to worry about (aside from the 'don't spawn a
>> thread as a side effect of importing' guideline)...
>
> I've never heard of this and I can't get Goo
Christian Heimes wrote:
> I'll justify why I view Python as a roaming app. All
> company and university Linux boxes I've used in the past had exported
> $HOME via NFS. So ~/.local is roamed.
I think there is a slight subtlety here: the exported NFS
$HOME is more equivalent to the HOMEDRIVE/HOMEPAT
Christian Heimes wrote:
> Tim Golden wrote:
>> The difference therefore is that installing large quantities
>> of Python modules into a roaming profile path will involve
>> their being copied to-and-fro on logon/logoff which, historically
>> at least, was a known cau
Paul Moore wrote:
> On 17/01/2008, Tim Golden <[EMAIL PROTECTED]> wrote:
>>> Is %USERPROFILE% not equal to %HOMEDRIVE%%HOMEPATH%?
>> No. On my machine, for example:
>>
>> HOMEDRIVE=H:
>> HOMEPATH=\
>> HOMESHARE=\\vogbs022\it\goldent
>>
>>
Paul Moore wrote:
>> The best we can hope for is to point to HOMEDRIVE/PATH as
>> Paul suggested (*possibly* rewiring os.path.expanduser to
>> try that first, depending on Win2K stuff)
>
> os.path.expanduser uses HOMEDRIVE/HOMEPATH. It checks for an explicit
> HOME (set manually by the user, this
Christian Heimes wrote:
> Paul Moore wrote:
>> I'd recommend that this change be reverted. To correctly get another
>> user's home directory would involve reading (via the registry, or
>> maybe some utility function I couldn't find at a quick glance) the
>> value of HOMEDRIVE/HOMEPATH which is set
Christian Heimes wrote:
> I can provide some guidance for the poor Windows souls. :] The VS 2008
> Express Edition makes it easy to compile Python on Windows. There is no
> need to install any extra SDK packages, additional compilers or whatsoever.
[... snip loads of useful info ...]
> The PCbuil
Christian Heimes wrote:
> Tim Golden wrote:
>> Just a note for those using the Express Edition: the build.bat file
>> which builds the Python project on the command line assumes that the
>> name of the executable is devenv.exe. In fact, for "Visual Studio Express
>>
Tim Golden wrote:
> Christian Heimes wrote:
>> Does the VS Express Edition have the "vcbuild" command? The build bots
>> are using vcbuild instead of devenv. The professional edition has it.
>>
>> c:\dev\python\trunk\PCbuild>vcbuild /useenv pcbuild.sln &
Tim Golden wrote:
> Christian Heimes wrote:
>> Does the VS Express Edition have the "vcbuild" command? The build bots
>> are using vcbuild instead of devenv. The professional edition has it.
>>
>> c:\dev\python\trunk\PCbuild>vcbuild /useenv pcbuild.sln &
Georg Brandl wrote:
> For one thing, releases generate "news", meaning that people will be made
> aware that things are moving, that Python is well underway to its next
> major versions, and maybe will be more inclined to look at what's new,
> or check out a release.
I'd like to second that point
Trent Nelson wrote:
>>> Sounds like a challenge if ever I've heard one -- care to wager a beer on
>>> it?
>>> (Only applies to buildbots that are connected/online.)
>
>> Make sure you get a screen shot for OnYourDesktop if/when they *do* go
>> green!
>
> Screenshot? I'm going to buy a pack of i
Bob Kline wrote:
> Are things really that different in the non-Windows worlds? If I want
> python-nose, I run "sudo apt-get install python-nose" (and that means I
> can always remove it with "sudo apt-get remove ..."). Seems more
> similar than different (ignoring the silliness of Microsoft's
Steven Bethard wrote:
> At the sprints, I ran into a bunch of similar errors running the test
> suite on my Windows Vista box, even on tests that were properly
> cleaning up after themselves in tearDown(). I even tried putting in
> sleeps as long as 1 second, to no avail. The only way to get the te
Tim Golden wrote:
> Steven Bethard wrote:
>> At the sprints, I ran into a bunch of similar errors running the test
>> suite on my Windows Vista box, even on tests that were properly
>> cleaning up after themselves in tearDown(). I even tried putting in
>> sleeps as lo
Giampaolo Rodola' wrote:
>
> On 1 Apr, 18:27, "Steven Bethard" <[EMAIL PROTECTED]> wrote:
>> On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
>>
>> <[EMAIL PROTECTED]> wrote:
>>> 2008/4/1, Tim Golden <[EMAIL PROTECTED]>:
os.rename(filename, filename + ".deleted")
>>> filename = filename + ".deleted"
>>> os.unlink(filename)
>>> except OSError:
>>> pass
Tim Golden
>> Funnily enough, that's exactly what the patch I&#x
Tim Golden wrote:
> Giampaolo Rodola' wrote:
>> On 1 Apr, 18:27, "Steven Bethard" <[EMAIL PROTECTED]> wrote:
>>> On Tue, Apr 1, 2008 at 10:20 AM, Facundo Batista
>>>
>>> <[EMAIL PROTECTED]> wrote:
>>>> 2008/4/1, Tim
Gregory P. Smith wrote:
> On Tue, Apr 1, 2008 at 9:13 AM, Tim Golden <[EMAIL PROTECTED]> wrote:
>
>> Tim Golden wrote:
>>
>> import os, sys
>> import win32file
>>
>> FILENAME = "test"
>>
>> def rename_and_remove (file
Nick Coghlan wrote:
> Tim Golden wrote:
>> I admit: this did occur to me on the train this am. While I
>> try to think of a robust way to handle this, other people have
>> proposed variations on pid-based / tempdir based filenames instead
>> of the same name for each tes
Tim Golden wrote:
> Gregory P. Smith wrote:
>> On Tue, Apr 1, 2008 at 9:13 AM, Tim Golden <[EMAIL PROTECTED]> wrote:
>>
>>> Tim Golden wrote:
>
>>>
>>> import os, sys
>>> import win32file
>>>
>>> FILENAME = "
[re tests which fail because something's holding a file
open with SHARE_DELETE]
Well I've tried my best, but I can't come up with a solution
which guarantees to overcome this obstacle. I set up a fairly
aggressive directory watcher which, when it sees a test file
being created, takes a SHARE_DELET
Terry Reedy wrote:
> "Tim Golden" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> | [re tests which fail because something's holding a file
> | open with SHARE_DELETE]
>
> There are a couple of things one can do in a directory'
Terry Reedy wrote:
> If the testdir disallows the search indexer, then there should be no need
> to disable Windows Search Service. If privatizing the dir kept other
> programs out, then likewise.
>
> | Or were you suggesting that there is some programmatic way for the
> | test suite to create
Trent Nelson wrote:
> 1. For a given python[_d].exe, always use the same test directory,
> but hash it against the entire python process path such that it's
> unique only for a given python instance.
This is to guard against several build runs in parallel, presumably?
> 2. Make sure every tim
Trent Nelson wrote:
>
>> -Original Message-
>> From: Tim Golden [mailto:[EMAIL PROTECTED]
>> Sent: 04 April 2008 09:30
>> To: Trent Nelson
>> Cc: Python-Dev
>> Subject: Re: [Python-Dev] fixing tests on windows
>
>> Yes. I'm trying desp
This problem was raised on the comtypes-users list
as it prevents comtypes from being imported on Python 2.6
at the moment.
http://bugs.python.org/issue3258
I'll try to find the time to step through to code to work out
what's going on, but it's inside the innards of ctypes which
I've never looke
Paul Moore wrote:
On 03/09/2008, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Perhaps we could have an option to place a "python.bat"
> into C:\Windows\ or C:\Windows\System\.
Except you still have the "last in wins" issue, and you have to make a
decision on whether or not to delete the file.
On 10/10/2011 12:58, Paul Moore wrote:
I've now installed VS Pro 2010. We'll see how that goes. I'd rather
avoid downgrading to VS2008 (or having both at once) just for personal
builds. But will if I have to.
Fairly sure VS2010 won't work, Paul.
At least it didn't when I was in the same situat
On 13/10/2011 19:36, Paul Moore wrote:
I don't really understand the benefits of bdist_msi over
bdist_wininst
Just commenting on this particular issue: in essence, the .MSI
format is the Microsoft standard, something which is especially
important for corporate rollouts. We're not particularly b
http://bugs.python.org/issue13524
Someone raised issue13524 yesterday to illustrate that a
subprocess will crash immediately if an environment block is
passed which does not contain a valid SystemRoot environment
variable.
Note that the calling (Python) process is unaffected; this
isn't - strict
On 04/12/2011 11:42, Nick Coghlan wrote:
There's actually two questions to be answered:
1. What should we do in 3.2 and 2.7?
2. Should we do anything more in 3.3?
Agreed.
1. Unset 'SystemRoot' in a windows shell
2. Run the test suite and observe the scale of the breakage
Sorry; something I
On 04/12/2011 12:41, Paul Moore wrote:
I'm not 100% clear on the problem here. From how I'm reading things,
the problem is that not supplying SystemRoot will cause (some or all)
invocations of subprocess.Popen to fail - it's not specific to
starting Python.
That's basically the situation.
My
On 05/12/2011 08:10, "Martin v. Löwis" wrote:
I agree with Nick that we shouldn't do anything except perhaps
for documentation changes. There are many other environment variables
whose absence could also cause failures to run the executable,
such as PATH, LD_LIBRARY_PATH, etc. Even not passing DI
On 20/01/2012 19:14, Georg Brandl wrote:
Am 20.01.2012 00:54, schrieb "Martin v. Löwis":
I can't help noticing that so far, worries about the workload came mostly from
people who don't actually bear that load (this is no accusation!), while those
that do are the proponents of the PEP...
Ok, so
On 20/03/2012 14:08, VanL 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 the latest
discussion.
A
On 21/03/2012 23:03, Paul Moore wrote:
On 21 March 2012 22:43, Mark Hammond wrote:
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
On 25/03/2012 16:26, Ned Batchelder wrote:
Georg, thanks so much for taking on this thankless task with grace and
skill. It can't be easy dealing with the death by a thousand tweaks
Seconded. I'm constantly edified by the way in which people
in the community respond to even quite abrupt critici
On 02/04/2012 07:03, "Martin v. Löwis" wrote:
Am 02.04.2012 00:31, schrieb Matěj Cepl:
On 1.4.2012 23:46, Brian Curtin wrote:
For what reason? Are the git or bzr files causing issues on HG?
No, but wrong .gitignore causes issues with git repo obtained via
hg-fast-import. If it is meant as an
On 22/06/2012 13:14, Barry Warsaw wrote:
> On Jun 22, 2012, at 12:27 PM, Paul Moore wrote:
>
>> And what I am trying to say is that no matter how much effort gets put
>> into trying to make build from source easy, it'll pretty much always
>> not be even remotely trivial on Windows.
>
> It seems t
On 26/06/2012 11:51, Devin Jeanpierre wrote:
> Hi guys,
>
> I just wanted to bring some more attention to issue #1677 , because I
> feel it's important and misunderstood. See:
> http://bugs.python.org/issue1677
>
> The issue is that sometimes, if you press ctrl-c on Windows, instead
> of raising
On 26/06/2012 11:59, Tim Golden wrote:
> On 26/06/2012 11:51, Devin Jeanpierre wrote:
>> Hi guys,
>>
>> I just wanted to bring some more attention to issue #1677 , because I
>> feel it's important and misunderstood. See:
>> http://bugs.python.org/issue1677
>
On 26/06/2012 20:02, Terry Reedy wrote:
> On 6/26/2012 6:51 AM, Devin Jeanpierre wrote:
>
>> The issue is that sometimes, if you press ctrl-c on Windows, instead
>> of raising a KeyboardInterrupt, Python will exit completely. Because
>> of this, any program that relies on ctrl-c/KeyboardInterrupt
I can confirm that there is a race condition between the code in
myreadline.c and the signal_handler. I have a patch in readiness which
basically loops until the signal has been tripped.
But what I don't know is: what to do if the signal *still* doesn't trip
(after 100 millisecond-retries)? At
Just recently I'm sure I saw a post saying that the main Python repo was
mirrored on bitbucket.org for the convenience of developers who could
then fork to their own accounts.
For the life of me I can't find it now. Can someone confirm and/or nudge
me in the right direction, please?
TJG
On 28/06/2012 19:10, Brian Curtin wrote:
Atlassian setup https://bitbucket.org/python_mirrors to mirror the
entire hg.python.org setup.
http://blog.python.org/2012/06/mercurial-mirrors-provided-by-atlassian.html
Thanks, Brian. That's obviously where I read about it, too.
TJG
___
I've been working on issue 1677 which concerns a race condition in
the interactive interpreter on Windows where a Ctrl-C can in some
circumstances cause the interpreter to exit as though a Ctrl-Z had
been pressed. I've added patches to the issue for 2.7, 3.2 & default.
I can't see any realistic wa
> Speaking of which - I find this bikeshed disgusting.
Disgusting? Irritating, perhaps, but why should a PEP -- even one whose
purpose is to codify existing practice -- not result in discussions
about its subject matter?
The final P stands for Proposal, not for Pronouncement.
TJG
__
On 08/11/2012 20:43, Georg Brandl wrote:
On 11/06/2012 02:56 PM, tim.golden wrote:
http://hg.python.org/cpython/rev/dafca4714298
changeset: 80273:dafca4714298
user:Tim Golden
date:Tue Nov 06 13:50:42 2012 +
summary:
issue9584: Add {} list expansion to glob. Original
101 - 151 of 151 matches
Mail list logo
