[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Tim Golden]

[... snip explanation of key sticking points ...]

Thank you for an excellent write-up combining background context with 
possible solutions. Now I need to actually read the PEP ;)


TJG

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LFURYGIGZUNV6S2YU4KR5LPVRW43NZTT/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] Adding test.support.safe_rmpath()

[Tim Golden]

On 14/02/2019 15:24, Giampaolo Rodola' wrote:



On Thu, Feb 14, 2019 at 4:03 PM Tim Golden <mailto:m...@timgolden.me.uk>> wrote:


On 14/02/2019 14:56, Giampaolo Rodola' wrote:
 >
 >
 > On Thu, Feb 14, 2019 at 3:25 PM Eric Snow
mailto:ericsnowcurren...@gmail.com>
 > <mailto:ericsnowcurren...@gmail.com
<mailto:ericsnowcurren...@gmail.com>>> wrote:
 >
 >     On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev
 >     mailto:python-dev@python.org>
<mailto:python-dev@python.org <mailto:python-dev@python.org>> wrote:
 >
 >
 >         I usually use shutil.rmtree for tests that need to create
 >         temporary files, and create a temporary directory for those
 >         files (that is, use tempfile.mkdtemp in setUp() and use
 >         shutil.rmtree in tearDown()). That way I don’t have to adjust
 >         house-keeping code when I make changes to test code.
 >
 >
 >     Same here.
 >
 >     -eric
 >
 >
 > What I generally do is avoid relying on tempfile.mkdtemp() and
always
 > use TESTFN instead. I think it's cleaner as a pradigm because
it's an
 > incentive to not pollute the single unit tests with 
`self.addCleanup()`

 > instructions (the whole cleanup logic is always supposed to occur in
 > setUp/tearDown):

Must chime in here because I've been pushing (variously months & years
ago) to move *away* from TESTFN because it generates numerous
intermittent errors on my Windows setup. I've had several goes at
starting to do that but a combination of my own lack of time plus some
people's reluctance to go that route altogether has stalled the thing.

I'm not sure I understand the difference in cleanup/teardown terms
between using tempfile and using TESTFN. The objections I've seen from
people (apart, obviously, from test churn) are to do with building up
testing temp artefacts on a possibly low-sized disk.

TJG


I suppose you mean the intermittent failures are usually due to "file is 
already in use by another process" correct? test.support's unlink(), 


Occasionally (and those are usually down to a poorly-handled cleanup).

More commonly it's due to residual share-delete handles on those files, 
probably from indexing & virus checkers or TortoiseXXX cache handlers. 
Obviously I can (and to some extent do) try to mitigate those issues.


In short: reusing the same filepath over and over for tests which are 
run in quick succession doesn't seem like a good idea usually. That's 
commonly what TESTFN-based tests do (some do; some don't).


I'm 100% with you on strict clean-up, not leaving testing turds behind, 
not over-complicating simple tests with lost of framework. All that. But 
-- however it's done -- I'd prefer to move away from the test-global 
TESTFN approach.


I'm not at my dev box atm so can't pick out examples but I definitely 
have some :) I have no issue with your proposal here: better and simpler 
cleanup is A Good Thing. But it won't solve the problem of re-using the 
same test filepath again and again.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Adding test.support.safe_rmpath()

[Tim Golden]

On 14/02/2019 14:56, Giampaolo Rodola' wrote:



On Thu, Feb 14, 2019 at 3:25 PM Eric Snow > wrote:


On Thu, Feb 14, 2019, 02:47 Ronald Oussoren via Python-Dev
mailto:python-dev@python.org> wrote:


I usually use shutil.rmtree for tests that need to create
temporary files, and create a temporary directory for those
files (that is, use tempfile.mkdtemp in setUp() and use
shutil.rmtree in tearDown()). That way I don’t have to adjust
house-keeping code when I make changes to test code.


Same here.

-eric


What I generally do is avoid relying on tempfile.mkdtemp() and always 
use TESTFN instead. I think it's cleaner as a pradigm because it's an 
incentive to not pollute the single unit tests with  `self.addCleanup()` 
instructions (the whole cleanup logic is always supposed to occur in 
setUp/tearDown):


Must chime in here because I've been pushing (variously months & years 
ago) to move *away* from TESTFN because it generates numerous 
intermittent errors on my Windows setup. I've had several goes at 
starting to do that but a combination of my own lack of time plus some 
people's reluctance to go that route altogether has stalled the thing.


I'm not sure I understand the difference in cleanup/teardown terms 
between using tempfile and using TESTFN. The objections I've seen from 
people (apart, obviously, from test churn) are to do with building up 
testing temp artefacts on a possibly low-sized disk.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

On 30/07/2018 16:41, Nick Coghlan wrote:

On 29 July 2018 at 03:20, Tim Golden  wrote:

I think that was my starting point: rather than develop increasingly
involved and still somewhat brittle mechanisms, why not do what you'd
naturally do with a new test and use tempfile? I was expecting someone to
come forward to highlight some particular reason why the TESTFN approach is
superior, but apart from a reference to the possibly cost of creating a new
temporary file per test, no-one really has.


For higher level modules, "just use tempfile to create a new temporary
directory, then unlink it at the end" is typically going to be a good
answer (modulo the current cleanup issues that Jeremy is reporting,
but ideally those will be fixed rather than avoided, either by
improving the way the module is being used, or fixing any underlying
defects).

For lower level modules though, adding a test suite dependency on
tempfile introduces a non-trivial chance of adding an operational
dependency from a module's test suite back to the module itself. When
that happens, module regressions may show up as secondary failures in
tempfile that then need to be debugged, rather than as specific unit
test failures that point you towards exactly what you broke.

Cheers,
Nick.



Thanks Nick; I hadn't thought about the possible interdependency issue.

I think for the moment my approach will be to switch to support.unlink 
wherever possible to start with. Before introducing other (eg tempfile) 
changes, this should at least narrow the issues down. I've made a start 
on that (before inadvertently blowing away all the changes since my 
hours-previous commit!)


If further changes are necessary then I'll probably look case-by-case to 
see whether a tempfile or some other solution would help.


That said, that's potentially quite a lot of change -- at least in terms 
of files changed if not strictly of functionality. So I'm thinking of 
trickle-feeding the changes through as people will understandably baulk 
at a patchbomb (PR-bomb?) hitting the codebase all at once.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

On 29/07/2018 15:21, Jeremy Kloth wrote:

On Sun, Jul 29, 2018 at 3:13 AM Tim Golden  wrote:

For an example:

http://tjg.org.uk/test.log


Thank you!  After inspecting all the errors, it does seem that they
are ALL caused by "bare" os.unlink/rmdir calls.  So it seems that a
massive undertaking of ferreting out these locations and replacing
them with their support equivalents would be needed to have a passing
test suite for you.


Thanks for checking. As I mentioned elsewhere in this thread, I propose 
to go through and apply support.unlink where necessary. It won't make 
things any worse and will hopefully improve in some areas.


For test_mailbox I've experimentally implemented a hybrid tempfile / 
local directory solution. ie I've created a new file on each run, but 
only within the python_ folder which already exists. As long as the 
directory cleans up there should be no leftovers. That's certainly 
helped although my re-run harness has provoked at least one error.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

On 28/07/2018 22:17, Jeremy Kloth wrote:

On Sat, Jul 28, 2018 at 11:20 AM Tim Golden  wrote:

Although things have moved on since that discussion and
test.support.unlink has grown some extra legs, all it's done really is
to push the bump along the carpet for a bit. I've got a newly-installed
Win10 machine with the typical MS Antivirus & TortoiseGitCache vying for
locks with every other process. I've just done a full test run:

python -mtest -j0 -v > test.log


I, for one, would like to see that log.  The issues you are have are
fairly unique.  Just check out the buildbot status page.  I know that
some of the workers are somewhat limited, but my worker
(https://buildbot.python.org/all/#/workers/12) is running on dedicated
hardware.  Before https://bugs.python.org/issue15496 was applied, the
errors you describe were indeed happening, but no longer.


For an example:

http://tjg.org.uk/test.log

Thinkpad T420, 4Gb, i5, SSD

Recently rebuilt and reinstalled: Win10, VS2017, TortoiseGit, standard 
Windows Antimalware, usual developer tools. That particular run was done 
with the laptop unattended (ie nothing else going on at the front end).

But the problem is certainly not specific to this laptop.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

On 29/07/2018 02:04, Jeremy Kloth wrote:

On Sat, Jul 28, 2018 at 6:43 PM Brett Cannon 
wrote:

If Windows doesn't clean up its temp directory on a regular basis
then that doesn't suggest to me not to use tempfile, but instead
that the use of tempfile still needs to clean up after itself. And
if there is a lacking feature in tempfile then we should add it
instead of a avoiding the module.


Mind you, this is mentioned in the confines of the test harness
where just about anything can happen (and usually does!).  Something
that cannot be coded against using just tempfile is cleanup on
process abort.  The per-process-directory approach handles this
case.

I would think it is desired to have no leftovers after running the 
test harness (especially in regards to the buildbots).


Now, I'm not sure the exact cause of all of the leftovers in the
TEMP directory, but it is definitely something that is currently
happening (and shouldn't be).  It is not exactly the easiest of tasks
to track the file usage of every test in the test suite.  It is
certainly easier to replace usages of os.unlink with
test.support.unlink within the test suite.


In the interests of trying to keep a focus to the changes I'm making, I 
propose to start again by, as you suggest, making use of 
test.support.unlink where it's not currently used. From the evidence I 
don't believe that will solve every problem I'm seeing but it should 
certainly reduce them.


I do there there's mileage in a wider change to revamp the test suite's 
naming and cleanup of temporary files but I'm very wary of trying to 
undertake what would undoubtedly be a sprawling and probably contentious 
change.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] bpo-34239: Convert test_bz2 to use tempfile (#8485)

[Tim Golden]

On 28/07/2018 23:54, Chris Jerdonek wrote:

On Thu, Jul 26, 2018 at 2:05 PM, Tim Golden  wrote:

https://github.com/python/cpython/commit/6a62e1d365934de82ff7c634981b3fbf218b4d5f
commit: 6a62e1d365934de82ff7c634981b3fbf218b4d5f
branch: master
author: Tim Golden 
committer: GitHub 
date: 2018-07-26T22:05:00+01:00
summary:

bpo-34239: Convert test_bz2 to use tempfile (#8485)

* bpo-34239: Convert test_bz2 to use tempfile

test_bz2 currently uses the test.support.TESTFN functionality which creates a 
temporary file local to the test directory named around the pid.

This can give rise to race conditions where tests are competing with each other 
to delete and recreate the file.


Per the other thread--
https://mail.python.org/pipermail/python-dev/2018-July/154762.html
this seems like a wrong statement of the problem as tests are properly
cleaning up after themselves. The leading hypothesis is that unrelated
Windows processes are delaying the deletion (e.g. virus scanners).


Thanks, Chris. I'm tracking the other thread and, if needs be, I'll 
revert this change in favour of whatever other approach is preferred



TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

On 28/07/2018 17:27, Jeremy Kloth wrote:

On Sat, Jul 28, 2018 at 8:41 AM Tim Golden  wrote:

1) Why are these errors occurring? ie are we dodging a root cause issue


The root cause is how Windows handles file deletions.  When a file is
removed, it is not immediately removed from the directory, instead, it
is simply marked for deletion.  Only once all open handles to the file
are closed, is it removed from the directory.  The most common cause
of additional open handles to a file is a antivirus scanner.


Thanks, Jeremy. I'm already aware of that. (If you look back at 
https://bugs.python.org/issue7443 you'll find me explaining the same to 
MvL some years ago). [In case the tone isn't clear, there's absolutely 
no sarcasm implied here. I just wanted to make it clear that I'm at 
least partly au fait with the situation :)].


Although things have moved on since that discussion and 
test.support.unlink has grown some extra legs, all it's done really is 
to push the bump along the carpet for a bit. I've got a newly-installed 
Win10 machine with the typical MS Antivirus & TortoiseGitCache vying for 
locks with every other process. I've just done a full test run:


python -mtest -j0 -v > test.log

and I've got a mixture of Permission (winerror 13) & Access errors 
(winerror 5). The former are usually attempting to open a TESTFN file; 
the latter are attempting to unlink one. Most of the Error 5 are 
os.unlink, but at least one is from test.support.unlink.


I understand the unable-to-recreate (virus checkers with share-delete 
handles) but I'm not so clear on what's blocking the unlink. IOW I think 
we have more than one issue.


Here's the thing. The TESTFN approach creates a directory per process 
test_python_ and some variant of @test__tmp inside that 
directory. But the same filename in the same directory is used for every 
test in that process. Now, leaving aside the particular mechanism by 
which Windows processes might be holding locks which prevent removal or 
re-addition, that already seems like an odd choice.


I think that was my starting point: rather than develop increasingly 
involved and still somewhat brittle mechanisms, why not do what you'd 
naturally do with a new test and use tempfile? I was expecting someone 
to come forward to highlight some particular reason why the TESTFN 
approach is superior, but apart from a reference to the possibly cost of 
creating a new temporary file per test, no-one really has.



If you are not seeing the RuntimeWarnings, then something else is amiss.


I think I've seen one RuntimeWarning in the many, many times I've been 
running through tests today.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

On 25/07/2018 16:07, Tim Golden wrote:
One problem is that certain tests use support.TESTFN (a local directory 
constructed from the pid) for output files etc. However this can cause 
issues on Windows when recreating the folders / files for multiple 
tests, especially when running in parallel.


Here's an example on my laptop deliberately running 3 tests with -j0 
which I know will generate an error about one time in three:


C:\work-in-progress\cpython>python -mtest -j0 test_urllib2 test_bz2 
test_importlib




[... snip ...]


[...] I wanted to ask first
whether there was any objection to my converting tests to using tempfile 
functions which should avoid the problem?


Thanks to those who responded here and/or on the two bpo issues I've 
already raised:


https://bugs.python.org/issue34239 -- test_bz2
https://bugs.python.org/issue34240 -- test_mmap

Two key questions have been posed in different ways:

1) Why are these errors occurring? ie are we dodging a root cause issue

2) Isn't this what test.support.unlink is there to solve?

For (1) I'm putting together a test run using code which I originally 
wrote for https://bugs.python.org/issue7443 to force the issues out into 
the open.


For (2), yes: test.support.unlink is supposed to solve that. But it's 
either not doing enough retries etc. or it's missing a trick.


To be clear: my motivation here isn't some housekeeping or modernisation 
exercise. I want to get a clear test run on a fresh build on Windows. At 
present I never get that. I'd be interested to hear from other Windows 
devs whether they have the same experience?


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

[trying again; sorry if it shows up twice]

I'm just easing back into core development work by trying to get a 
stable testing environment for Python development on Windows.


One problem is that certain tests use support.TESTFN (a local directory 
constructed from the pid) for output files etc. However this can cause 
issues on Windows when recreating the folders / files for multiple 
tests, especially when running in parallel.


Here's an example on my laptop deliberately running 3 tests with -j0 
which I know will generate an error about one time in three:


C:\work-in-progress\cpython>python -mtest -j0 test_urllib2 test_bz2 
test_importlib


Running Debug|Win32 interpreter...
Run tests in parallel using 6 child processes
0:00:23 [1/3/1] test_urllib2 failed
test test_urllib2 failed -- Traceback (most recent call last):
  File "C:\work-in-progress\cpython\lib\test\test_urllib2.py", line 
821, in test_file

f = open(TESTFN, "wb")
PermissionError: [Errno 13] Permission denied: '@test_15564_tmp'

Although these errors are both intermittent and fairly easily spotted, 
the effect is that I rarely get a clean test run when I'm applying a patch.


I started to address this years ago but things stalled. I'm happy to 
pick this up again and have another go, but I wanted to ask first 
whether there was any objection to my converting tests to using tempfile 
functions which should avoid the problem?


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Tests failing on Windows with TESTFN

[Tim Golden]

I'm just easing back into core development work by trying to get a 
stable testing environment for Python development on Windows.


One problem is that certain tests use support.TESTFN (a local directory 
constructed from the pid) for output files etc. However this can cause 
issues on Windows when recreating the folders / files for multiple 
tests, especially when running in parallel.


Here's an example on my laptop deliberately running 3 tests with -j0 
which I know will generate an error about one time in three:


C:\work-in-progress\cpython>python -mtest -j0 test_urllib2 test_bz2 
test_importlib


Running Debug|Win32 interpreter...
Run tests in parallel using 6 child processes
0:00:23 [1/3/1] test_urllib2 failed
test test_urllib2 failed -- Traceback (most recent call last):
  File "C:\work-in-progress\cpython\lib\test\test_urllib2.py", line 
821, in test_file

f = open(TESTFN, "wb")
PermissionError: [Errno 13] Permission denied: '@test_15564_tmp'

Although these errors are both intermittent and fairly easily spotted, 
the effect is that I rarely get a clean test run when I'm applying a patch.


I started to address this years ago but things stalled. I'm happy to 
pick this up again and have another go, but I wanted to ask first 
whether there was any objection to my converting tests to using tempfile 
functions which should avoid the problem?


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] windows installer and python list mention

[Tim Golden]

On 10/04/2017 21:48, Steve Dower wrote:

I wasn't aware of [the need to subscribe to Python list] - I'm sure
I've emailed the list before without it being rejected, and I'm
certainly not subscribed. Is it a recent change? Is it necessary?


As long as I've been involved, the list has been subscription-only with 
the first post moderated even after subscription (to prevent 
bot-subscription). But in fact we'd typically waved through any 
unsubscribed posts which were clearly genuine / on-topic etc.


We changed the policy a year ago. In fact the discussion kicked off 
between the list moderators on 11th April 2016, exactly a year ago.
The reasoning was that we were seeing people who had posted without 
being subscribed and who were not seeing replies because, by and large, 
people reply to the list and not to the OP.


We felt that we were doing a disservice to people unfamiliar with the 
mailing list mechanism since they might not realise that people were 
replying to their question but via the list, to which they were not 
subscribed. Clearly other decisions are possible; but that's what we've 
stuck to since.


(Pragmatically, we do in fact pass through certain posts which we 
recognise as long-time posters perhaps coming in from an unfamiliar 
account, say posting from their phone etc.)


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Py 3.6 on Ubuntu Zesty

[Tim Golden]

On 07/02/2017 22:38, Barry Warsaw wrote:

On Feb 07, 2017, at 02:15 PM, Mike Miller wrote:


Does anyone know why Python 3.6 is not the default Python 3 under the
upcoming Ubuntu Zesty, or what may be holding it back?


I guess that would be me. :)


Is there anyone that could give it a nudge?  It's in the repos but not as
python3:

http://packages.ubuntu.com/zesty/python3
http://packages.ubuntu.com/zesty/python3.6


I posted about this on the ubuntu-devel mailing list:


[... snip comprehensive explanation about how versions get promoted 
within Debian / Ubuntu ...]


Well I'm only a casual Linux user, but this was interesting just because 
of the better understanding it gives of the processes which distros have 
to go through once new versions are released upstream.


Thanks

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 468

[Tim Golden]

I've set him to moderation for now. Beyond that we'd have to unsubscribe 
him altogether and ask him to resubscribe later.


TJG

On 13/06/2016 22:34, Guido van Rossum wrote:

Can someone block Franklin until his mailer stops resending this message?

--Guido (mobile)

On Jun 13, 2016 2:26 PM, "Franklin? Lee" mailto:leewangzhong%2bpyt...@gmail.com>> wrote:

I am. I was just wondering if there was an in-progress effort I
should be looking at, because I am interested in extensions to it.

P.S.: If anyone is missing the relevance, Raymond
Hettinger's compact dicts are inherently ordered until a
delitem happens.[1] That could be "good enough" for many purposes,
including kwargs and class definition. If CPython implements
efficient compact dicts, it would be easier to propose
order-preserving (or initially-order-preserving) dicts in some
places in the standard.

[1] Whether delitem preserves order depends on whether you want to
allow gaps in your compact entry table. PyPy implemented compact
dicts and chose(?) to make dicts ordered.

On Saturday, June 11, 2016, Eric Snow mailto:ericsnowcurren...@gmail.com>> wrote:

On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee
 wrote:
> Eric, have you any work in progress on compact dicts?

Nope.  I presume you are talking the proposal Raymond made a
while back.

-eric


___
Python-Dev mailing list
Python-Dev@python.org 
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/guido%40python.org



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/mail%40timgolden.me.uk



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Terminal console

[Tim Golden]

Not subscribed; probably via gmane.

I've added him to a hold list via spam filter. See if that works.

TJG

On 25/04/2016 22:27, Brett Cannon wrote:

Can someone disable this person's subscription?

On Mon, 25 Apr 2016 at 14:15 Kenny via Python-Dev mailto:python-dev@python.org>> wrote:


fopen Terminal.app.python.
3.5.0.()

def fopen Termina.app.python.3.5.0.()

%add.%data(CDATA[])::true||false

fclose();

end Terminal.app.python.3.5.0.()

Yours thingy


Sent from Samsung Mobile
___
Python-Dev mailing list
Python-Dev@python.org 
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/brett%40python.org



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/mail%40timgolden.me.uk



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

[Tim Golden]

On 13/04/2016 12:40, Victor Stinner wrote:
> Last months, most 3.x buildbots failed randomly. Some of them were
> always failing. I spent some time to fix almost all Windows and Linux
> buildbots. There were a lot of different issues.

Can I state the obvious and offer a huge vote of thanks for this work,
which is often tedious and unrewarding?

Thank you

TJG

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #25910: Fixed more links in the docs.

[Tim Golden]

On 11/04/2016 15:38, serhiy.storchaka wrote:
> -  `__.
> +  `__.

Is there any intended irony in our link to openssl not being via https?

:)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Benchmark results across all major Python implementations

[Tim Golden]

On 16/11/2015 22:23, Zachary Ware wrote:

On Mon, Nov 16, 2015 at 3:38 PM, Brian Curtin  wrote:

On Monday, November 16, 2015, Brett Cannon  wrote:




Hi Brett

Any thoughts on improving the benchmark set (I think all of
{cpython,pypy,pyston} introduced new benchmarks to the set).



We should probably start a mailing list



There is/was a sp...@python.org list.


Is, but seems to be heavily moderated without active moderation.  I
sent an offer to speed-owner this morning to help with moderation, but
as yet no response.  I know I have a couple of messages waiting in the
queue :)


Just to help things along, I've added myself as list owner and released 
a bunch of messages.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP: Collecting information about git

[Tim Golden]

On 17/09/2015 02:59, Terry Reedy wrote:
> On 9/16/2015 5:20 AM, Oleg Broytman wrote:
> 
>> On Tue, Sep 15, 2015 at 07:44:28PM +, Augie Fackler
>>  wrote:
> 
>>> There are a lot of reasons to prefer one tool over another. Common
>>> ones are
>>> familiarity, simplicity, and power.
>>
>> Add here documentation, speed, availability of extensions and
>> 3rd-party tools, hosting options (both locally installable and web
>> services).
> 
> For me, the killer 3rd party tool in favor of hg is TortoiseHg, which I
> use on Windows. As far as I know (I did check a bit), there is no
> equivalent for git on Windows.  For me, the evaluation should be between
> hg+TortoiseHG versus git+???.

There certainly is (and with the obvious name!):

https://tortoisegit.org/

I use it every day

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How far to go with user-friendliness

[Tim Golden]

On 20/07/2015 19:48, Christie Wilson wrote:
> I am terrified of replying to this thread since so many folks on it seem
> unhappy that it is continuing, but I want to +1 what Erik said.

Don't be terrified :)

But do understand that, in general, and especially for this
already-noisy thread, the right place for arguments supporting a change
or a reversion is usually on the issue tracker:

 https://bugs.python.org/

I don't know whether Robert's opened an issue to propose his solution,
but if not, you could open one and add him as nosy.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] GetFinalPathNameByHandleW - what is the minimum windows version python-3.5 will support ?

[Tim Golden]

On 19/07/2015 13:10, Vitaly Murashev wrote:

I've just found out that that on Windows internal implementation of
python35.dll in posixmodule.c
uses winapi function GetFinalPathNameByHandleW

By the way from MSDN:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx

Minimum supported client
   Windows Vista [desktop apps only]

Minimum supported server
   Windows Server 2008 [desktop apps only]

Does it mean, that Python-3.5 doesn't support any windows versions prior
"Windows Vista" and "Windows Server 2008" ?


In essence: yes.

Python's support for Windows is outlined in PEP 11:

  https://www.python.org/dev/peps/pep-0011/#microsoft-windows

which establishes that Python drops support for a Windows platform when 
Microsoft does. WinXP (somewhat noisily) finished support last year:


  http://windows.microsoft.com/en-gb/windows/end-support-help

while Server 2003 -- more quietly; I had to go and look -- came out of 
extended support this month:


  https://support.microsoft.com/en-us/lifecycle?p1=3198

Since Python 3.5 will come out after both of those platforms have 
finished support, there's no guarantee that it will run without error on 
those systems.


Obviously, all earlier releases of Python -- including the 
long-term-supported 2.7 should continue to work. Any otherwise 
undocumented failure to work on older platforms should be raised as a bug.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Backporting the 3.5+ Windows build project files to 2.7

[Tim Golden]

On 22/06/2015 18:03, Zachary Ware wrote:
> As you may know, Steve Dower put significant effort into rewriting the
> project files used by the Windows build as part of moving to VC14 as
> the official compiler for Python 3.5.  Compared to the project files
> for 3.4 (and older), the new project files are smaller, cleaner,
> simpler, more easily extensible, and in some cases quite a bit more
> correct.
> 
> I'd like to backport those new project files to 2.7, and Intel is
> willing to fund that work as part of making Python ICC compilable on
> all platforms they support since it makes building Python 2.7 with ICC
> much easier.  


Very much +1. Anything which eases building on Windows is good. I'd
meant a while ago to put in a vote of thanks to you & Steve for the
incremental improvements and tidy-ups to the build area, and I'd
certainly like to see this proposed change go in.

I'll try to find time to check out your branch and build from there, but
unless you've done anything bizarre I'm sure I'll be happy with it.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenBSD buildbot has many failures

[Tim Golden]

On 01/04/2015 13:13, Victor Stinner wrote:
> Hi,
> 
> 2015-04-01 12:47 GMT+02:00 Tim Golden :
>> On the back of Victor's recent emails re buildbots, I've knocked
>> something up which can be scheduled to email the status of some or all
>> buildbots:
>>
>>   https://github.com/tjguk/buildbotinfo
> 
> Are you aware of this previous project?
> https://code.google.com/p/bbreport/

Yes -- I originally forked it with a view to extending it the way I
wanted, but I was rewriting so much that in the end I started afresh and
ended up with just my own code. (The way you do...)

[... snip useful ideas about more finely-tuned results ...]

I'd also thought of various directions things could go. TBH, though, I
knew if I started to get ambitious I'd end up with something which tried
to do everything and didn't do anything.

I might go somewhere with the thing in the future, but for now it does
what it does and if it helps someone -- including me -- at the simplest
level, well that's a good thing.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OpenBSD buildbot has many failures

[Tim Golden]

On 01/04/2015 08:32, Victor Stinner wrote:
> When I started to work on Python, I was surprised to not get emails from
> buildbots.
> 
> Currently, there is an IRC bot on #python-dev which notify when buildbot
> color changes. Or sometiles I chceck the huge waterfall page. By the
> way, it became difficult to browse this page because there are too many
> offline buildbots.


On the back of Victor's recent emails re buildbots, I've knocked
something up which can be scheduled to email the status of some or all
buildbots:

  https://github.com/tjguk/buildbotinfo

It's rough-and-ready but it does work. If it's useful to anyone, feel
free to use / clone / fork / whatever. By all means send PRs or raise
Issues but I've already overrun the little time I'd given myself to get
this working so I'm not sure when I'll get to them.

There are two modules: the underlying buildbot.py which lightly wraps
the XML-RPC interface; and the buildbotinfo.py which uses it to generate
some readable output according to some selection criteria.

See the project README for some details:

  https://github.com/tjguk/buildbotinfo/blob/master/README.rst

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Buildbot x86 XP-4 3.x doesn't compile anymore: drop it?

[Tim Golden]

On 28/03/2015 09:51, Victor Stinner wrote:

Hi,

The buildbot x86 XP-4 3.x doesn't compile anymore since 3 months or
more (maybe when Steve upgraded the Visual Studio project to VS 2015?
I don't know).

Would it be possible to fix this buildbot, or to turn it off?

By the way, do we seriously want to support Windows XP? I mean, *who*
will maintain it (no me sorry!). I saw recent changes to explicitly
*drop* support for Windows older than Visa (stop using GetTickCount,
always call GetTickCount64, for time.monotonic).


Per PEP 11, we track Microsoft lifecycle support, so we no longer 
support WinXP on 3.5 and newer. We do support XP on 3.4 and older, 
including 2.7. At least, that's my understanding. Given that, the only 
XP buildbot which makes sense is one running VS 2008 (2.7, 3.1, 3.2) or 
VS 2010 (3.3, 3.4).


I think -- and I'm responding here to the wider set of emails Victor has 
just posted re failing buildbots -- that the difficulty with red 
buildbots is finding someone at the intersection of understanding the 
buildbot platform and understanding the code which has just broken it. 
(Or at least, having the wherewithal to come to understand both).


And that someone might well not be the person who's hosting the 
buildbot: at its minimum they run up a VM and install the OS and the 
required tools. It's can be a way of offering help to the Python 
community without even being involved in core development at all.


I concur with what Victor's touched on: that buildbots are not useful if 
they're always red. But finding the right person to turn them green is 
not necessarily easy.


For myself I'm quite willing for someone to ping me with: "there's a 
Windows buildbot gone red; can you have a look?" But I have precious 
little time, and if the failure requires me to garner an understanding 
of a deep-level code change, a version-specific issue with the VS 
compiler, and some odd interaction with VM on which the buildbot is 
running, I'm unlikely to have enough time or energy to invest in it.


Willing-but-not-always-able-ly-yours,

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Tim Golden]

On 23/03/2015 01:46, Glenn Linderman wrote:
> On 3/22/2015 8:12 AM, Tim Golden wrote:
>> I'll create a £££ user (which is the easiest non-ASCII name to create
>> on a UK keyboard) to see how cleanly the latest installer works. 
> 
> You can also copy/paste.  A path with a Cyrillic, Greek, Chinese,
> Tibetan, Japanese, Armenian, and Romanian character, none of which are
> in the "Windows ANSI" character set, should suffice...  Here ya go...
> 
> ț硕բ文བོདΘ
> 
> In my work with Windows, I've certainly seen that £ is much more
> acceptable to more programs than ț or these other ones.
> <http://ar.wikipedia.org/wiki/%D8%A3%D9%84%D9%81%D8%A8%D8%A7%D8%A6%D9%8A%D8%A9_%D9%8A%D9%88%D9%86%D8%A7%D9%86%D9%8A%D8%A9>

Thanks, Glenn. Good point.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Tim Golden]

On 22/03/2015 15:12, Tim Golden wrote:

On 22/03/2015 14:44, Paul Moore wrote:

On which note, I'm assuming neither of the issues I've found are major
blockers. "pip.exe doesn't work if Python is installed in a directory
with non-ASCII characters in the name" can be worked around by using
python -m pip, and the launcher issue by using a generic shebang like
#!/usr/bin/python3.5.


That can become a more major blocker if "pip doesn't work" == "ensurepip
doesn't work and blocks thus the installer crashes" as was the case with
a mimetypes issue a little while back.

I'll create a £££ user (which is the easiest non-ASCII name to create on
a UK keyboard) to see how cleanly the latest installer works.


Tried with "Mr £££". The installer's fine but the installed pip.exe 
fails while "py -3 -mpip" succeeeds as Paul notes.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Installing Python to non-ASCII paths

[Tim Golden]

On 22/03/2015 14:44, Paul Moore wrote:

On which note, I'm assuming neither of the issues I've found are major
blockers. "pip.exe doesn't work if Python is installed in a directory
with non-ASCII characters in the name" can be worked around by using
python -m pip, and the launcher issue by using a generic shebang like
#!/usr/bin/python3.5.


That can become a more major blocker if "pip doesn't work" == "ensurepip 
doesn't work and blocks thus the installer crashes" as was the case with 
a mimetypes issue a little while back.


I'll create a £££ user (which is the easiest non-ASCII name to create on 
a UK keyboard) to see how cleanly the latest installer works.


TJG

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] incorrect docstring for sys.int_info.sizeof_digit?

[Tim Golden]

On 21/01/2015 11:07, Pfeiffer, Phillip E., IV wrote:
> Apologies if this has already been reported; I couldn't find a
> readily searchable archive for this mailing list (and apologies if
> I've just missed it).

Depending on "readily searchable", this isn't too bad:

http://markmail.org/search/?q=list%3Aorg.python.python-dev+integer+docstring

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PCBuild project updates

[Tim Golden]

On 22/11/2014 22:10, Steve Dower wrote:

Just attracting some attention to http://bugs.python.org/issue22919
for those of us who build Python out of the PCBuild folder. More
details/patches there, but the tl;dr is

* Still works with VS 2010 (and now VS 2013 and VS 2015 too) * Build
time should be reduced * Tools\buildbot\*.bat are also updated, so
buildbots shouldn't notice any change

If you're concerned/interested, I'll be watching the tracker for
comments. Ideally I'd like at least a couple of people to test build
with whatever VS version they have, but if nobody can do that then
I'll assume that nobody will notice anything break sooner than me :)



I'm trying to find the time to look, but every time I go there, there's 
a newer review and a later update :) I view this as a good sign.


My VS-fu is minimal but I'll try to pull and build against VS2010 which 
is all I have installed. As an overview point, though, I think it's 
great to have a good spring-cleaning of our Win-based setup, so thanks 
anyway.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows Dedicated Mailing List

[Tim Golden]

On 14/11/2014 08:34, Shorya Raj wrote:
> Hello
> I have been following the lists for a while, and have noticed that there
> do not seem to be any sort of specifics for Windows. Now, as someone
> developing python applications (and hoping to develop python itself on
> Windows), I think it may be prudent to consider adding a Windows
> specific mailing list regarding development on Windows, whether it is
> development of Python on windows, or developing Python applications on
> Windows. Please let me know what you guys think - if there is consensus,
> it would be great to get it up and running, and I would be more than
> willing to take steps from my side as required.

That would be this:

https://mail.python.org/mailman/listinfo/python-win32

TJG

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Who's using VS/Windows to work on Python?

[Tim Golden]

On 13/11/2014 19:47, Steve Dower wrote:

Just wondering who is regularly/occasionally using VS 2010 to work on
Python?


I use VS 2010 (and VS 2008 if I'm building 2.7). Frankly my time has 
been so scarce this last year, I don't manage to use them from one month 
to the next. But I do use them.



I want to get a feel for who will be disrupted when I merge in the
changes to build with VS 2015, which will help influence when that merge
occurs. VS 2015 Preview was just released yesterday, and while it’s not
perfect yet, it’s isolated enough from VS 2010 that there won’t be any
issues installing them both (I can’t say the same for VS 2013…). If
people are okay with this, then we can consider merging the changes
sooner. Once VS 2015 RC is released, I’ll be looking to merge asap., but
I don’t see a strong need to do it before then other than a longer bake
time.


Are the changes for VS2015 likely to hamper a build against VS2010?

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Microsoft Visual C++ Compiler for Python 2.7

[Tim Golden]

On 26/09/2014 19:01, Steve Dower wrote:

Hi all,

(This is advance notice since people on this list will be interested.
Official announcements are coming when setuptools makes their next
release.)

Microsoft has released a compiler package targeting Python 2.7 (i.e.
VC9). We've produced this package to help library developers build
wheels for Windows, but also to help users unblock themselves when
they need to build C extensions themselves.

The Microsoft Visual C++ Compiler for Python 2.7 is available from:
http://aka.ms/vcpython27


Wow. I am lost for words.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.5 release schedule PEP

[Tim Golden]

On 23/09/2014 18:05, Steve Dower wrote:

I'm also considering/experimenting with installing into "Program
Files" by default, but I suspect that isn't going to work out yet.


I'd like to see that go forward: I think it's increasingly difficult to 
justify Python's position at c:\pythonxx. But it does run the risk of

breaking All The Things. When it was discussed, people spoke about
symlinks (or hardlinks / junctions / whatever) in the appropriate
places to support hardcoded paths, but I don't know how feasible
that will turn out to be.



I'd like to move the Windows versions onto the next release of VC
(currently "VC 14" until the branding team figures out what to call
it). There isn't a promised RTM date for VC 14 yet, so it looks like
the best available compiler by Beta 1 will be a "Go Live" RC. (The
"Go Live" marking basically means "we think this is ready for use,
but expect a round of minor updates/fixes soon - the compiler is
least likely to be updated, my guess is that it'll be Visual Studio
UI mostly).


My only real misgiving here is that, for a few years, we'll need *three* 
versions installed to build the active branches: 2008 for 2.7; 2010 for 
3.4; and 2014 for 3.5. Am I wrong?


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows XP, Python 3.5 and PEP 11

[Tim Golden]

On 17/06/2014 04:08, Zachary Ware wrote:

On Mon, Jun 16, 2014 at 4:12 PM, Victor Stinner
 wrote:

Hi,

I would like to know if Python 3.5 will still support Windows XP or
not. Almost all flavors of Windows XP reached the end-of-life in
April, 2014 except "Windows XP Embedded". There is even an hack to use
Windows upgrades on the desktop flavor using the embedded flavor (by
changing a key in the registry). Extracts of the Wikipedia page:


This was recently discussed in the "Moving Python 3.5 on Windows to a
new compiler" thread, where Martin declared XP support to be ended
[1].  I believe Tim Golden is the only resident Windows dev from whom
I haven't seen at least implicit agreement that XP doesn't need
further support, so I'd say our support for XP is well and truly dead
:)

In any case, surely anyone stuck with XP can be happy with Python 3.4.
I'm perfectly fine with 3.2 on Win2k!



I think we're justified in dropping XP support, for all the reasons 
others have given. Like most people, I suppose, I'm support WinXP in 
various ways (including embedded) because "not supported" != "not 
working". But those are all running 2.x versions of Python.


It'll be good to be able stretch a little on the Windows API front 
without having to double-think about where a particular API came in.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

[Tim Golden]

On 15/06/2014 08:54, Paul Moore wrote:

On 15 June 2014 00:15, Greg Ewing  wrote:

However, it says the Windows version uses CreateProcess, which
doesn't use PATH.


Huh? CreateProcess uses PATH:


Just to be precise:

CreateProcess *doesn't* use PATH if you pass an lpApplicationName 
parameter. It *does* use PATH if you pass a lpCommandLine parameter 
without an lpApplicationName parameter. It's possible to do either via 
the subprocess module, but the latter is the default.


If you call:

subprocess.Popen(['program.exe', 'a', 'b'])

or

subprocess.Popen('program.exe a b'])


Then CreateProcess will be called with a lpCommandLine but no 
lpApplicationName and PATH will be searched.


If, however, you call:

subprocess.Popen(['a', 'b'], executable="program.exe")

then CreateProcess will be called with lpApplicationName="program.exe" 
and lpCommandLine="a b" and the PATH will not be searched.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

[Tim Golden]

On 15/06/2014 02:22, Ryan Gonzalez wrote:

Of course cmd.exe is hardcoded;


Of course it's not:

(from Lib/subprocess.py)

comspec = os.environ.get("COMSPEC", "cmd.exe")

I don't often expect, in these post-command.com days, to get anything 
other than cmd.exe. But alternative command processors are certainly 
possible.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] subprocess shell=True on Windows doesn't escape ^ character

[Tim Golden]

On 13/06/2014 03:11, Nikolaus Rath wrote:
> "R. David Murray"  writes:
>> Also notice that using a list with shell=True is using the API
>> incorrectly.  It wouldn't even work on Linux, so that torpedoes
>> the cross-platform concern already :)
>>
>> This kind of confusion is why I opened http://bugs.python.org/issue7839.
> 
> Can someone describe an use case where shell=True actually makes sense
> at all?

On Windows (where I think the OP is), Popen & friends ultimately invoke
CreateProcess.

In the case where shell=True, subprocess invokes the command interpreter
explictly under the covers and tweaks a few other things to avoid a
Brief Flash of Unstyled Console. This is the relevant snippet from
subprocess.py:

if shell:
startupinfo.dwFlags |= _winapi.STARTF_USESHOWWINDOW
startupinfo.wShowWindow = _winapi.SW_HIDE
comspec = os.environ.get("COMSPEC", "cmd.exe")
args = '{} /c "{}"'.format (comspec, args)


That's all. It's more or less equivalent to your prefixing your commands
with "cmd.exe /c".

The only reasons you should need to do this are:

* If you're using one of the few commands which are actually built-in to
cmd.exe. I can't quickly find an online source for these, but typical
examples will be: "dir" or "copy".

* In some situations -- and I've never been able to nail this -- if
you're trying to run a .bat/.cmd file. I've certainly been able to run
batch files without shell=True but other people have failed within what
appears to  be the same configuration unless invoking cmd.exe via
shell=True.

I use hg.exe (from TortoiseHg) but ISTR that the base Mercurial install
supplies a .bat/.cmd. If that's the OP's case then he might find it
necessary to pass shell=True.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pep8 reasoning

[Tim Golden]

On 25/04/2014 13:09, Chris Withers wrote:
> On 25/04/2014 04:03, Barry Warsaw wrote:
>> On Apr 25, 2014, at 12:00 PM, Chris Angelico wrote:
>>
>>> Don't forget that PEP 8 is not the standard for the Python language,
>>> only the Python stdlib. Particularly, there's no strong reason to
>>> follow some of its lesser advices (eg spaces rather than tabs, the
>>> exact maximum line length) for new projects;
>>
>> I'd say it depends.  If the code is going to be shared with people
>> outside of
>> your organization (e.g. open source libraries), then there's a strong
>> motivation to be consistent throughout the community, which means PEP 8.
> 
> Right, so for me this means even in a private code base, there are big
> benefits to using PEP 8; everything looks the same, whether it's a third
> party library, python core or your own code...

I essentially had this conversation via my blog a couple of years ago:

  http://ramblings.timgolden.me.uk/2012/03/27/pep8-or-not/

  http://ramblings.timgolden.me.uk/2012/03/29/more-on-pep8/

  http://ramblings.timgolden.me.uk/2012/04/09/pep8-it-is-then/

and was quite surprised at the strength of feeling evoked. As you can
even tell from the titles of the posts, I ended up by accepting that,
even though I'm at liberty to apply my own format to my own code, it
would be more of a community-friendly idea to use [near-enough] PEP8
regardless.

As you can also see from the comments throughout, YMMV.

:)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] pep8 reasoning

[Tim Golden]

On 24/04/2014 12:59, Tal Einat wrote:
> As far as I know that reason for these examples being frowned upon is
> that they are needlessly redundant. 

Oh, the irony! (Sorry, couldn't resist)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Wave module support for floating point data

[Tim Golden]

On 02/03/2014 10:25, Xavier de Gaye wrote:

The core-mentorship current archive is only available to the list
members as stated at the core-mentorship web site at
http://pythonmentors.com/.  Curious to know why.


The thinking behind c-m is to lower the entry bar for contribution. To 
that end, people can ask questions which might, to the more 
knowledgeable, appear naive. ("You don't know what Mercurial is?" 
"You've never used make?") If the archives were public then 
less-experienced questioners might shrink from exposing their ignorance 
and would ultimately not engage with Python development.


Another "rule" is that you should not quote c-m posts literally outside 
the c-m list. You can restate the question in general terms to, eg, get 
input from python-dev or python-committers. Advice *from* the committers 
on the list can be quoted elsewhere.


Note that the archives are open to all subscribers, and subscription is 
open to anyone. So it's not particularly secret, just a low barrier to 
remind people to respect the possible inexperience of posters.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] BugFix for "time" native module in Python 2.7

[Tim Golden]

On 03/02/2014 19:41, Виктор Щерба wrote:

Hi, guys!

I have found a bug in module "time" function "sleep" in Python 2.7 under
Windows XP / Server 2003 and lower.
I fix this bug locally. But how could I send you hg patch or pull
request or, maybe, commit to sandbox?


The best thing is to raise an bug on our issue tracker:

  http://bugs.python.org/

and attach the patch together with a test which reproduces the issue

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add Gentoo packagers of external modules to Misc/ACKS

[Tim Golden]

On 08/12/2013 18:11, Dmitriy Baranov wrote:

2013/12/8 R. David Murray :

As far as we have been able to determine, Tae Wong is in fact a bot
(note the 'seo' in the email address...a tip of the hand, as far as
I can see).  We have removed all access permissions (including email)
from the related account on the bug tracker already.  IMO this address
should be blocked from posting to all python lists.


He doesn't appear to have a subscription to python-list. (And I don't 
remember seeing any of these posts there, in any case).


TJG

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] NTPath or WindowsPath?

[Tim Golden]

On 18/11/2013 10:08, Serhiy Storchaka wrote:
> 18.11.13 04:31, Brian Curtin написав(ла):
>> On Sat, Nov 16, 2013 at 2:50 PM, Serhiy Storchaka
>>  wrote:
>>> 16.11.13 21:15, Antoine Pitrou написав(ла):
>>>
 In a (private) discussion about PEP 428 and pathlib, Guido proposed
 that maybe NTPath should be renamed to WindowsPath, since the name is
 more likely to stay relevant in the middle term. What do you think?
>>>
>>>
>>> What about nturl2path, os.name, sysconfig.get_scheme_names()?
>>
>> What about them?
> 
> Should nturl2path be renamed to windowsurl2path? Should os.name return
> "windows" on Windows, and should sysconfig support "windows" scheme name?

I think the answer's fairly obviously "no" for reasons of backwards
compatibility. (Although that doesn't rule out aliases if someone felt
strongly enough about it).

I don't say that there's no case for trying address the considerable
variety of Python & C ways of saying "I'm on Windows" with the core &
stdlib. But I do say that whoever makes a case had better be *very* sure
of the impact.

Going forwards, however, I'm happy to see new Python code using
"Windows" rather than the size-specific "Win32/64" or the dated and
over-specific "NT".

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] windows file closing race condition?

[Tim Golden]

On 06/09/2013 12:50, Richard Oudkerk wrote:
> On 06/09/2013 11:23am, Tim Golden wrote:
>> On 06/09/2013 11:14, Antoine Pitrou wrote:
>>> Le Fri, 06 Sep 2013 08:58:06 +0100,
>>> Tim Golden  a écrit :
>>>>
>>>> What should Python do?
>>>
>>> Maybe using FILE_SHARE_DELETE could help?
>>> http://bugs.python.org/issue15244
>>
>> I don't think so. It's the use of FILE_SHARE_DELETE (by other programs,
>> eg Virus Checkers) that typically causes the problem. IOW, the
>> sequence is:
>>
>> * [Some Other Prog] takes FILE_SHARE_DELETE handle, allowing other
>> programs to delete the file even while this handle is still open
>>
>> * Python calls DeleteFile -- succeeds if the only open handles are
>> FILE_SHARE_DELETE; carries on
>>
>> * File has apparently disappeared but still has open handles
>>
>> * Any attempt to create a file of the same name or to delete a
>> containing directory fail because the file is still open, even though
>> it's successfully been deleted.
>>
>> * (Some time later) [Some Other Prog] closes its handle and the file is
>> now completely gone
>>
>>
>> Unless I'm missing something, there's nothing Python can do to help here
>> apart from the sort of delay-retry dance which test.support uses and
>> which I'm advocating against as a core feature.
> 
> Instead of deleting, the file could be moved to a temporary name in the
> root directory (or some other permanent directory on the same drive) and
> then deleted.  That would allow the directory to be closed even if a
> FILE_SHARE_DELETE handle is still open for the file.
> 

True, but then you're into determining a temporary name somewhere on the
same volume if possible and avoiding collisions etc. Again, I don't
think this is something we need to be doing by default in core Python.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] windows file closing race condition?

[Tim Golden]

On 06/09/2013 11:14, Antoine Pitrou wrote:
> Le Fri, 06 Sep 2013 08:58:06 +0100,
> Tim Golden  a écrit :
>>
>> What should Python do?
> 
> Maybe using FILE_SHARE_DELETE could help?
> http://bugs.python.org/issue15244

I don't think so. It's the use of FILE_SHARE_DELETE (by other programs,
eg Virus Checkers) that typically causes the problem. IOW, the sequence is:

* [Some Other Prog] takes FILE_SHARE_DELETE handle, allowing other
programs to delete the file even while this handle is still open

* Python calls DeleteFile -- succeeds if the only open handles are
FILE_SHARE_DELETE; carries on

* File has apparently disappeared but still has open handles

* Any attempt to create a file of the same name or to delete a
containing directory fail because the file is still open, even though
it's successfully been deleted.

* (Some time later) [Some Other Prog] closes its handle and the file is
now completely gone


Unless I'm missing something, there's nothing Python can do to help here
apart from the sort of delay-retry dance which test.support uses and
which I'm advocating against as a core feature.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] windows file closing race condition?

[Tim Golden]

On 06/09/2013 08:14, Nick Coghlan wrote:
> On 6 September 2013 15:50, Chris Withers  wrote:
>> Continuous testing is a wonderful thing when it comes to finding weird edge
>> case problems, like this one:

[... snip ...]
>> os.rmdir(path)
>> OSError: [WinError 145] The directory is not empty:
>> 'c:\\users\\jenkins\\appdata\\local\\temp\\tmpkeg4d7\\a'

> This feels a lot like an issue we were seeing on the Windows
> buildbots, which we ended up working around in the test support
> library: http://bugs.python.org/issue15496
> 
> That would be some awfully ugly code to upgrade from "hack in the test
> support library" to "this is just how Python unlinks files on
> Windows", though :P

I think that any kind of delay-retry loop falls squarely within the
remit of the calling application, not core Python. This isn't a problem
of Python's making: IIUC, you would see the same effect if you used any
other
language or simply deleted the folder from within Explorer. (I don't
know whether Explorer itself does anything canny under the covers to retry).

Obviously our test suite *is* a calling application, and so it makes
perfect sense to put some workaround in place.

The trouble with this class of problem, where a share-delete handle
allows operations to succeed and to fail later which would normally fail
early, is that the bad effect is at one remove from its cause. Here, by
the time the rmtree has reached the point of removing a parent
directory, it's long-since left behind the file which has a still-open
handle: the DeleteFile succeeded and the code moved on. You can't even
tell which file it was.

A related problem arises where the DeleteFile succeeds and an error
occurs when a subsequent CreateFile fails for the same filepath, again
because a share-delete handle is still open for a file at that path.
This is another one which hits our test suite because of an overuse of
one temp filename.

What should Python do? With some effort it could look for open file
handles against the file it's trying to delete, but what then? Wait
until they're all closed? That could leave it hanging. And even with a
timeout it would introduce a delay which might be unnecessary. A lot of
the time, no harm will come of the file existing a few seconds after the
DeleteFile has succeeded.

In short, I don't believe there's any mileage in introducing extra code
into Python's os or io modules. It falls on the shoulders of the calling
code to implement retry loops or whatever logic as needed.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 3.4 and Windows XP: just 45 days until EOL

[Tim Golden]

On 12/07/2013 00:58, Christian Heimes wrote:
> Hi,
> 
> how do you feel about dropping Windows XP support for Python 3.4? It
> would enable us to use some features that are only available on Windows
> Vista and newer, for example http://bugs.python.org/issue6926 and
> http://bugs.python.org/issue1763 .
> 
> PEP 11 says:
>   A new feature release X.Y.0 will support all Windows releases
>   whose extended support phase is not yet expired.
> 
> For Python 3.4 is going to be a very close call. According to PEP 429
> 3.4.0 final is scheduled for February 22, 2014. The extended support
> phase of Windows XP ends merely 45 days later on April 8, 2014. Do we
> really have to restrict ourselves to an API that is going to become
> deprecated 45 days after the estimated release of 3.4.0?

I would like to continue support for WinXP. It's still widely, widely
used -- MS support notwithstanding. The situation might have been
different if Vista had been a viable corporate desktop, but I suspect
that many outfits have waited (as we did here) until Win7 before moving
forward. Win7 is now our default desktop for new machines, but we're
still running a slight majority of WinXP machines.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] How to debug python crashes

[Tim Golden]

On 14/05/2013 13:32, Philippe Fremy wrote:
> I have a reproducable crash on Windows XP with Python 2.7 which I would
> like to investigate. I have Visual Studio 2008 installed and I
> downloaded the pdb files. However I could not find any instructions on
> how to use them and was unsuccessful at getting anything out of it.
> 
> I checked the developer guide but could not find anything on debugging
> crashes. On internet, this seems to be also an underdocumented topic.
> 
> So, a few questions :
> - is there some documentation to help debugging crashes ?

I don't think there is. As you say, it's somewhat underdocumented. Maybe
someone else can point to something, but I'm not aware of anything.

> - are the pdb files released along python usable with Visual Studio and
> stock Python ? Or do you need a hand-compiled version ?


I actually have no idea whether you drop in the .pdb files, but if you
have VS anyway, it's easy enough to build and run within VS and let the
debugger drop you into the code when it crashes.

Are you in a position to post a reproducible test case to the tracker?
Or were you holding back until you'd done some analysis?

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mimetypes broken on Windows

[Tim Golden]

On 17/04/2013 08:28, Tim Golden wrote:
> On 16/04/2013 23:22, Ben Hoyt wrote:
>> But yes, I would love to see a Windows Python committer chip in, even
>> if it's just with "agreed, please provide a patch".
> 
> I can chip in with an apology, at least. This has been on my to-do list
> for ages; but I have had absolutely minimal time to work on Python this
> last year. I'll set aside an hour later today to look over the different
> options and patches on offer and at least come back with an opinion on
> what should happen next, even if I have to ask someone else to apply the
> patch.

I've responded over there for now -->

  http://bugs.python.org/issue15207#msg187158

TJG

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mimetypes broken on Windows

[Tim Golden]

On 16/04/2013 23:22, Ben Hoyt wrote:
> But yes, I would love to see a Windows Python committer chip in, even
> if it's just with "agreed, please provide a patch".

I can chip in with an apology, at least. This has been on my to-do list
for ages; but I have had absolutely minimal time to work on Python this
last year. I'll set aside an hour later today to look over the different
options and patches on offer and at least come back with an opinion on
what should happen next, even if I have to ask someone else to apply the
patch.

Obviously should some other developer want to dive in, please do. Thanks
for bringing it back to the table, Ben.

TJG


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] casefolding in pathlib (PEP 428)

[Tim Golden]

On 12/04/2013 22:15, Larry Hastings wrote:


On 04/12/2013 10:05 AM, Guido van Rossum wrote:

On Fri, Apr 12, 2013 at 1:39 AM, Antoine Pitrou 
wrote:

I think we want glob("*.py") to find
"SETUP.PY" under Windows. Anything else will probably be surprising to
users of that platform.

Yeah, I suppose so. But there are more crazy details. E.g. IIRC
Windows silently ignores trailing dots in filenames. Do we want
"*.py." to match SETUP.PY then?






Someone who is fresher than I am at Windows programming should answer
this, but AFAICT Win32 provides no API that will tell you if a
particular filename / volume is case sensitive.


I don't have web access at the moment to check but IIRC the 
GetVolumeInformation call does return an indicator of whether the volume 
is case-sensitive via the VOLUME_FLAG flag enum. At least, it claims to: 
I don't have access to a case-sensitive filesystem to check whether it's 
lying or not.


TJG

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] cpython: issue9584: Add {} list expansion to glob. Original patch by Mathieu Bridon

[Tim Golden]

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 patch by Mathieu Bridon

files:
   Doc/library/glob.rst  |  11 ++--
   Lib/glob.py   |  65 ++
   Lib/test/test_glob.py |  64 +-
   Misc/NEWS |   3 +
   4 files changed, 118 insertions(+), 25 deletions(-)


diff --git a/Doc/library/glob.rst b/Doc/library/glob.rst
--- a/Doc/library/glob.rst
+++ b/Doc/library/glob.rst
@@ -13,10 +13,10 @@

  The :mod:`glob` module finds all the pathnames matching a specified pattern
  according to the rules used by the Unix shell.  No tilde expansion is done, 
but
-``*``, ``?``, and character ranges expressed with ``[]`` will be correctly
-matched.  This is done by using the :func:`os.listdir` and
-:func:`fnmatch.fnmatch` functions in concert, and not by actually invoking a
-subshell.  (For tilde and shell variable expansion, use
+``*``, ``?``, character ranges expressed with ``[]`` and list of options
+expressed with ``{}`` will be correctly matched.  This is done by using the
+:func:`os.listdir` and :func:`fnmatch.fnmatch` functions in concert, and not by
+actually invoking a subshell.  (For tilde and shell variable expansion, use
  :func:`os.path.expanduser` and :func:`os.path.expandvars`.)


Needs a versionchanged.

In any case, brace expansion is not part of globbing (see the bash or zsh
manuals) because it does not generate valid file names, and it is a non-POSIX
expansion of some shells.  Are you sure it should be put into the glob module?
(Not speaking of the backward incompatibility it creates.)


I backed it out very soon afterwards, Georg. It had had some (quite a 
bit of) discussion on the issue, but I'd messed up the patch somehow and 
the backwards compat issue was raised pretty much immediately by Serhiy. 
So I pulled the commit.


TJG

Insofar as
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Do we need __length_hint__ at all? (Was PEP 0424: A method for exposing a length hint)

[Tim Golden]

> 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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Issue 1677 - please advise

[Tim Golden]

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 way to add a test for this.
Unsurprisingly there don't appear to be any tests in the test suite
for the interactive interpreter and even if there were, this is an
inconsistent race condition I'm fixing.

So... should I go ahead and push anyway, or is there anything else
I should be doing as part of the change?

Thanks

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Bitbucket mirror?

[Tim Golden]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Bitbucket mirror?

[Tim Golden]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Poking about issue 1677

[Tim Golden]

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 present the code just drops through 
(with a comment warning) which is why we're seeing the interpreter exit.

What should happen, though? Raise SystemError?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Poking about issue 1677

[Tim Golden]

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 is not
>> guaranteed to work on windows. Also, working with the interactive
>> interpreter becomes really annoying for those with the habit of
>> deleting the whole input line via ctrl-c.
> 
> Idle Shell, 3.3.0a4, Win 7does not seem to have this problem. Still up
> after 6000 ^Cs. It is better anyway, in multiple ways, than Command
> Prompt. (That does not help batch-mode programs, though.)
> 
> That aside, perhaps the way it handles ^C might help.
> 
> I did get the CP to close four times, each time after a few hundred to
> maybe a thousand ^Cs. It seems to require more than just one held down
> key press. I suspect the closures happened after the limited line buffer
> was filled and it was starting to delete the earliest lines.
> 

I've just updated the call with as much as I had time for just now.

Your point about IDLE made me think; I installed pyreadline
and now I can't get it to fail at all. Seems to point even
more to myreadline.c.

More later

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Poking about issue 1677

[Tim Golden]

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
>>
>> 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 is not
>> guaranteed to work on windows. Also, working with the interactive
>> interpreter becomes really annoying for those with the habit of
>> deleting the whole input line via ctrl-c.
>>
>> Some people that read the bug report think that this only happens if
>> you hold down ctrl-c long enough or fast enough or some such thing.
>> That's not so; it can happen just from pressing ctrl-c once. Whatever
>> race condition here is not related to the timing gaps between presses
>> of ctrl-c. The "test cases" of "hold down ctrl-c for a bit" are to
>> conveniently reproduce, not a description of the problem.
>>
>> Hope this was the right place. #python-dev encouraged me to post here,
>> so, yeah. And thanks for all your hard work making Python a pleasant
>> place to be. :)
> 
> Thanks, Devin. Definitely useful info. AFAICT you haven't added that
> particular snippet of info to the call. (ie the fact that even one press
> will trigger the issue). Please feel free to add; I notice that you're
> the last submitter, some time last year.
> 
> Goodness knows if I'll get the time, but the
> natural thing would be to hunt down the uses of SetConsoleCtrlHandler to
> see what we're doing with them.

OK. We clearly *don't* set a console handler as I thought
we did. Scratch that idea off the list. As Martin said:
need to run this with a debugger attached to try to catch
in action.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Poking about issue 1677

[Tim Golden]

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 a KeyboardInterrupt, Python will exit completely. Because
> of this, any program that relies on ctrl-c/KeyboardInterrupt is not
> guaranteed to work on windows. Also, working with the interactive
> interpreter becomes really annoying for those with the habit of
> deleting the whole input line via ctrl-c.
> 
> Some people that read the bug report think that this only happens if
> you hold down ctrl-c long enough or fast enough or some such thing.
> That's not so; it can happen just from pressing ctrl-c once. Whatever
> race condition here is not related to the timing gaps between presses
> of ctrl-c. The "test cases" of "hold down ctrl-c for a bit" are to
> conveniently reproduce, not a description of the problem.
> 
> Hope this was the right place. #python-dev encouraged me to post here,
> so, yeah. And thanks for all your hard work making Python a pleasant
> place to be. :)

Thanks, Devin. Definitely useful info. AFAICT you haven't added that
particular snippet of info to the call. (ie the fact that even one press
will trigger the issue). Please feel free to add; I notice that you're
the last submitter, some time last year.

Goodness knows if I'll get the time, but the
natural thing would be to hunt down the uses of SetConsoleCtrlHandler to
see what we're doing with them.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
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 packaging in 3.3

[Tim Golden]

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 to me that a "Windows build service" is something the Python
> infrastructure could support.  This would be analogous to the types of binary
> build services Linux distros provide, e.g. the normal Ubuntu workflow of
> uploading a source package to a build daemon, which churns away for a while,
> and results in platform-specific binary packages which can be directly
> installed on an end-user system.

The devil would be in the details. As Paul Moore pointed out earlier,
building *any* extension which relies on some 3rd-party library on
Windows (mysql, libxml, sdl, whatever) can be an exercise in iterative
frustration as you discover build requirements on build requirements.
This isn't just down to Python: try building TortoiseSvn by yourself,
for example.

That's not say that this is insurmountable. Christopher Gohlke has
for a long while maintained an unofficial binary store at his site:

  http://www.lfd.uci.edu/~gohlke/pythonlibs/

but I've no idea how much work he's had to put in to get all the
dependencies built.

Someone who just turned up with a new build:
"Here's a Python interface for ToastRack -- the new card-printing
service" would need a way to provide the proposed build infrastructure
with what was needed to build the library behind the Python extension.

Little fleas have smaller fleas... and so on.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] .{git,bzr}ignore in cpython HG repo

[Tim Golden]

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 intentional sabotage of using git
(and bzr) for cpython, then that's the only explanation I can
understand, otherwise it doesn't make sense to me why these files are in
HG repository at all.



Sabotage, most certainly.


I had to laugh. It's the deadpan delivery.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Playing with a new theme for the docs, iteration 2

[Tim Golden]

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 criticism in
a constructive, open and often humorous manner. (As I've said
before, I'm also impressed by the way in which people are prepared
to come back and apologise / acknowledge that they had a moment
of jerkiness).


TJG
___
Python-Dev mailing list
Python-Dev@python.org
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 install layout and the PATH on win32

[Tim Golden]

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 and accept such breakage as the necessary
cost.

MAL, in his followup, asks what the advantages are of such a change. I've
actually been asking for the same thing in this thread and the only real
answer I've got is "consistency".  So while I share MAL's concerns, people
seem willing to push forward on this anyway, without the benefits having
been explained.

IOW, this isn't the decision I would make, but I think I've already made
that point a number of times in this thread.  Beyond that, there doesn't
seem much for me to add...


I agree on all points here. I don't understand quite why backward
compatibility is being treated so lightly here. But equally, I've made
my points and have little further to add.


Well I've gone through (and deleted) three draft contributions
to the ideas proposed here over the last week or so. In short,
I'm with Paul & Mark. The OP seems far more casual towards
breakage than would be the case if, eg, code were involved.
If this had been proposed for Python 3k I'd have said: go
for it - why not? But for this to drop in now means, as
others have said, that I'll have to adjust various small
tools which assume the location of python.exe according
to the (minor) version I'm running.

I can certainly cope with the change and without too much
difficulty, but I'm afraid it does smack of a too foolish
consistency. And it's not as though I've seen crowds of
people chiming in with a me-too! The only person strongly
supporting the change (as distinct from not opposing it)
is VanL, who appears to need it for his particular setup.

In short, I'm -1 but I'm not going to storm off in a huff
if it goes ahead, merely be a little bewildered at why this
was needed by anyone else and exactly what real-world problem
it's solving for thousands of Windows Python users.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
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 install layout and the PATH on win32

[Tim Golden]

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 question for you Mark, Paul, (and anyone else): Éric correctly points
out that there are actually two distinct changes proposed here:

1. Moving the Python binary
2. Changing from "Scripts" to "bin"

So far, the primary resistance seems to be to item #1 - moving the
python binary. There have been a few people who have noted that #2 will
require some code to change (i.e. Paul), but I don't see lots of
resistance.


Speaking for myself, I think that's true. At present I tend to
add /scripts to my path and I can just as easily add /bin (for
whatever version I'm running most often on that machine).

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 407: New release cycle and introducing long-term support versions

[Tim Golden]

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 let me add then that I'm worried about the additional work-load.

I'm particularly worried about the coordination of vacation across the
three people that work on a release. It might well not be possible to
make any release for a period of two months, which, in a six-months
release cycle with two alphas and a beta, might mean that we (the
release people) would need to adjust our vacation plans with the release
schedule, or else step down (unless you would release the "normal"
feature releases as source-only releases).


Thanks for the reminder, Martin.  Even with the current release schedule,
I think that the load on you is too much, and we need a whole team of
Windows release experts.  It's not really fair that the RM usually changes
from release to release (at least every 2), and you have to do the same
for everyone.

It looks like we have one volunteer already; if we find another, I think
one of them will also be not on vacation at most times :)



I'm certainly happy to help out there. Like everyone I'm
not always clear on my availability but the more people
who know what needs to be done, the better ISTM.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue 13524: subprocess on Windows

[Tim Golden]

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 DISPLAY may
cause the subprocess to fail starting.

IOW, users should "normally" pass all environment variables, and
only augment it with any specific additions and deletions that
they know are needed for the subprocess. If a user deliberately
passes a small set of environment variables (e.g. none), we must
assume that it was deliberate, and that any resulting failures
are desired. People do such stuff for security reasons, and
side-stepping their enforcement is not appropriate for Python
to do.


Having slept on this I must confess that this is pretty much the
conclusion I'd come to: we can't do anything in code which is
guaranteed to be correct in every case. The best we can do is
document. And, as Martin Packman pointed out (and I had missed),
this particular condition is already documented, at least enough
to point a user to.

We could probably do with a HOWTO (or blog post or whatever) on using
subprocess on Windows, not least because a fair amount of the docs
are Unix-centric and actually very slightly confusing for naive
Windows-based developers.

I think my proposal now is: do nothing. I'm aware that Nick Coghlan
has been making fairly extensive changes to the subprocess docs
recently and I don't I can propose anything on this matter which
amounts to more than shuffling the pieces around.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue 13524: subprocess on Windows

[Tim Golden]

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 feeling is that option 4 is best - set SystemRoot to its current
value if it's not been set by the user. This leaves the user unable to
set an environment with SystemRoot missing, but if the OS fails to
handle that properly, then I'm OK with that limitation.


FWIW if we went this route we could set it if it's missing but
that still allows the user to set it to blank. I'm just a little
bit wary of altering the environment which the user believes has
been set.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue 13524: subprocess on Windows

[Tim Golden]

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 should have highlighted in the earlier post.
Behaviour varies between Windows versions. On WinXP, if you
unset SystemRoot in a cmd shell, you won't be able to run the
test suite: Python won't even start up. On Win7 Python will
start but, eg, the random module will fail.

This is actually a separate issue: how much of Python will work
without a valid SystemRoot. The OP's issue was that if you use
subprocess to start an arbitrary process (you get the same problem
if you try "notepad.exe") and pass it an env block without a valid
SystemRoot then that process will likely fail to start up. And it
won't be obvious why.

The case where someone tries to run Python (in general) without
a valid SystemRoot is a tiny cornercase and you'd be quite right
to push that back and say "Don't do that". I don't believe we have
to test for it or add code to work around it.

While I put the idea forward, I agree that an exception is more likely
than not to break existing code. I just can't see any clear alternative,
apart from option 1: we do nothing.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Issue 13524: subprocess on Windows

[Tim Golden]

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 - strictly - a Python crash. The issue is essentially
a Windows one where a fairly unusual cornercase -- passing
an empty environment -- has unforseen effects.

The smallest reproducible example is this:

import os, sys
import subprocess
subprocess.Popen(
[sys.executable],
env={}
)

and it can be prevented like this:

import os, sys
import subprocess
subprocess.Popen(
[sys.executable],
env={"SystemRoot" : os.environ['SystemRoot']}
)

There's a blog post here which gives a worked example:


http://jpassing.com/2009/12/28/the-hidden-danger-of-forgetting-to-specify-systemroot-in-a-custom-environment-block/

but as the author points out, nowhere on MSDN is there a warning
that SystemRoot is mandatory. (And, in effect, it's not as it
would just be possible to write code which had no need of it).

So... what's our take on this? As I see it we could:

1) Do nothing: it's the caller's responsibility to understand the
   complications of the chosen Operating System.

2) Add a doc warning (ironically, considering the recent to-and-fro
   on doc warnings in this very module).

3) Add a check into the subprocess.Popen code which would raise some
   exception if the environment block is empty (or doesn't contain
   SystemRoot) on the grounds that this probably wasn't what the user
   thought they were doing.

4) Automatically add an entry for SystemRoot to the env block if it's
   not present already.


It's tempting to opt for (1) and if we were exposing an API called
CreateProcess which mimicked the underlying Windows API I would be
inclined to go that way. But we're abstracting a little bit away
from that and I think that that layer of abstraction carries its
own responsibilities.

Option (3) seems to give the best balance. It *is* a cornercase, but at
the same time it's easy to misunderstand that the env block you're
passing in *replaces* rather than *augments* that of the current
process.

Thoughts?

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Packaging and binary distributions for Python 3.3

[Tim Golden]

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 bureaucratic,
but I recently had to bundle a small number of common extensions as
.msi packages so they could be deployed easily onto our baseline
machines.

I'm not saying that Python *must* have .msi support for this reason:
if it didn't already, you could argue that it could be provided by
corporates who needed this, or by 3rd party service providers, if
only by providing light .msi wrappers round standard installers.

I'm completely overloaded at the moment, so I'm only following this
thread at a distance but I did want to chime in in agreement with
the points Paul's already made: Windows users expect executable
binary installers; it's much harder to compile libraries on Windows
even if you have a compiler; the integration with the OS package
manager (Add/Remove Programs) is a benefit although not a sine qua non.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Packaging and binary distributions for Python 3.3

[Tim Golden]

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 situation a few months ago.
I've had close to zero time to spend on Python lately so I could be
wrong but I remember that I had to "downgrade" to VS2008 for that reason.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 397 (Python launcher for Windows) reference implementation

[Tim Golden]

On 30/06/2011 05:23, Mark Hammond wrote:

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 has been experimenting ...


Not yet - my last update of the PEP has made the existing reference
implementation out-of-date, so I want to work on that before starting on
the C version. However, seeing as my note about the most recent PEP
update attracted zero comments..


Sorry, didn't realise you couldn't see me silently nodding my
head from the other side of the world ;) I really must work
on those communication skills...

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.access on Windows

[Tim Golden]

On 20/05/2011 22:56, "Martin v. Löwis" wrote:

TBH I think the less attractive we can make os.access() look the
better. It uses the real uid instead of the effective uid, it
encourages LBYL behavior, the outcome may be incorrect, it doesn't
work on Windows... The ONLY reason to ever use it is in a setuid()
program. But who writes those any more? (Esp. in Python!)


+1. The best way to determine "could I access this file" is to try
to access it, and be prepared to get an exception.


FWIW the OP knew this but -- for some reason specific to his
use case -- wanted to avoid updating the mod dates of the containing
directory. Obviously that's his problem, not ours...

> So we might deprecate-then-delete it on Windows.

I'll rework that patch to be a DeprecationWarning in that case.


People who *really* need to know in advance should use the Windows
API for that on Windows (i.e. call AccessCheck).


And indeed this is what I've recommended to the OP. I'll follow this
up in that python-list thread. I see that Benjamin's updated the
os.access docs so I'll let this thread die and talk the OP through
the AccessCheck route (which is, unfortunately, more tricky because
it's not exposed by pywin32. Also not our problem...)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] os.access on Windows

[Tim Golden]

On 20/05/2011 16:21, Brian Curtin wrote:


On Fri, May 20, 2011 at 03:38, Tim Golden 
(Sorry about that; I had no idea I'd sent that from my work account)


I think we should tread lightly in the documentation area. We already
have two note boxes, and adding a third probably scares everyone away.


I entirely agree. (That's what I meant by "involved" above)


Maybe there should be a bullet list of considerations to be made when
using os.access?

* Apply the patch in issue2528 to 3.3 and maybe 2.7


I'd vote in favor of this. If we can be a bit smarter in determining
os.access results, let's do it.

I haven't reviewed the patch other than 1 minute scan, but I'll put this
on my radar and try to get you a review.


Thanks. To be honest I wrote the patch 3 years ago; I haven't even
tried to apply it to either of the current posixmodule.c. Let's
see if I can dust it off and mould it into shape, or you'll be
left fighting patch errors instead of reviewing code :)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] os.access on Windows

[Tim Golden]

There's a thread on python-list at the moment:

  http://mail.python.org/pipermail/python-list/2011-May/1272505.html

which is discussing the validity of os.access results on
Windows. Now we've been here before: I raised issue2528
for a previous enquiry some years ago and proffered a patch
which uses the AccessCheck API to perform the equivalent check,
but didn't follow through.

Someone on the new thread is suggesting -- validly -- that the
docs should highlight the limitations of this call on Windows.
But the docs for that call are already fairly involved:

  http://docs.python.org/library/os.html#os.access

We seem to have a few options in increasing order of difficulty:

* Do nothing - inform the occasional enquirer of the situation and
  leave it at that.

* Update the docs to add something which describes what the function
  actually does on the Windows platform. (Whether or not we change any code).

* Apply the patch in issue2528 to 3.3 and maybe 2.7

* Leave os.access alone but offer alternative Windows-specific
  functionality in the os module or elsewhere, using essentially
  the code in the issue2528 patch.

As a side note, the pywin32 packages don't actually include AccessCheck
at the moment. (Which makes it slightly harder to explain to people
how they could do this check for themselves). It could probably be added
over there which might ease the burden over here.

Opinions?

TJG
Tim Golden
Very Senior Analyst Programmer

CBS Outdoor UK
Camden Wharf
28 Jamestown Road
London
NW1 7BY
T: 020 7482 3000
F: 020 7267 4944


http://www.cbsoutdoor.co.uk/
http://www.cbsoutdoor.co.uk/
http://www.bigbuschallenge.com/
Don't waste paper. Think before you print.
The contents of this e-mail are confidential to the ordinary user of the e-mail 
address to which it was addressed, and may also be privileged. If you are not 
the addressee of this e-mail you may not copy, forward, disclose or otherwise 
use it or any part of it in any form whatsoever. If you have received this 
e-mail in error, please e-mail the sender by replying to this message. CBS 
Outdoor Ltd reserves the right to monitor e-mail communications from 
external/internal sources for the purposes of ensuring correct and appropriate 
use of CBS Outdoor facilities. CBS Outdoor Limited, registered in England and 
Wales with company number 02866133 and registered address at Camden Wharf, 28 
Jamestown Road, London, NW1 7BY.





This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] blogroll for the new blog

[Tim Golden]

Well I've created a python-dev category under my usual blog so if you wouldn't 
mind adding that:

  http://ramblings.timgolden.me.uk/category/tech/python/python-dev/

TJG
Tim Golden
Senior Analyst Programmer

CBS Outdoor UK
Camden Wharf
28 Jamestown Road
London
NW1 7BY
T: 020 7482 3000
F: 020 7267 4944


http://www.cbsoutdoor.co.uk/
http://www.cbsoutdoor.co.uk/
http://www.cbsoutdoor.co.uk/Newsletter-sign-up
Don't waste paper. Think before you print.
The contents of this e-mail are confidential to the ordinary user of the e-mail 
address to which it was addressed, and may also be privileged. If you are not 
the addressee of this e-mail you may not copy, forward, disclose or otherwise 
use it or any part of it in any form whatsoever. If you have received this 
e-mail in error, please e-mail the sender by replying to this message. CBS 
Outdoor Ltd reserves the right to monitor e-mail communications from 
external/internal sources for the purposes of ensuring correct and appropriate 
use of CBS Outdoor facilities. CBS Outdoor Limited, registered in England and 
Wales with company number 02866133 and registered address at Camden Wharf, 28 
Jamestown Road, London, NW1 7BY.





This e-mail has been scanned for all viruses by Star. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Tim Golden]

On 21/03/2011 02:49, Éric Araujo wrote:

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://mercurial.selenic.com/wiki/GitExtendedDiffFormat.)

“hg import --no-commit” is basically a patch command that understands
the extended format.  (Pro tip: it can be abbreviated to “hg import
--no-c”, as Mercurial accepts unambiguous abbreviations of commands and
options.)


A further tip in case it helps anyone: hg import (and its mq
counterpart hg qimport) can patch directly from a URL. This
is handy when I want to try out someone's patch directly from
the issue page on bugs.python.org. [Maybe everyone else knew
this, but I found it out by accident!]

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

[Tim Golden]

On 07/03/2011 10:49, Mark Hammond wrote:

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 interpreter?
Presumably that launcher would be pretty version independent, so (a)
the one that gets installed with Python 3.3 would support older
versions even though they didn't include the launcher themselves, (b)
overwriting the launcher when a new version of Python is installed
wouldn't be too big a deal, and (c) it could be released as a
standalone package for people with only older versions of Python
installed?


Yup - although I think a pythonw.exe launcher would be needed too (for
the same reasons we need python.exe and pythonw.exe today)


I like this idea. If I had the spare time (I don't :-() I'd work on
this myself.

+1 from me.


Agreed all round. In the highly unlikely event that I find
some time I too might have a play with the idea. The devil
will undoubtedly be in the details. I've implemented
a Pure-python version of this before, but found it unacceptably
slow for anything but ad-hoc use. Still, it was useful for
that :)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows

[Tim Golden]

On 28/01/2011 16:29, Brian Curtin wrote:

On Fri, Jan 28, 2011 at 10:12, anatoly techtonikwrote:

I've seen about 7 requests to add Python into %PATH% in installer. All
closed with no result, but with some fear and uncertainty. Martin
feared that MSI installers are not able to remove entry from PATH and
even if they can, they may kill the whole PATH instead of removing
just one entry.

To prove or dispel these fears, I've just installed/uninstalled
Mercurial from mercurial-1.7.3-1-x86.msi and App Engine from
GoogleAppEngine-1.4.1.msi several times. Both add entries to PATH and
both remove them without any further problems. Should we finally add
this to 3.2 installer for Python?

--
anatoly t.



Definitely not for 3.2, but this is something I'd like to look into for 3.3.

Recently I've talked to two Python trainers/educators and the major gripe
their attendees see is that you can't just sit down and type "python" and
have something work. For multi-Python installs, we'll have to define what
that "something" is, but I think it should be possible for the installer to
optionally put Python into the path, and to also remove itself on uninstall.


I don't think, ultimately, that there is any insurmountable technical
objection. There are misgivings but they could undoubtedly be overcome
or overridden. But it would require someone to patch the MSI builder
so it added the functionality and -- I think -- offered it as an option
which could be enabled or disabled.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] configparser 1.1 - one last bug fix needed

[Tim Golden]

On 14/12/2010 17:01, Raymond Hettinger wrote:


On Dec 14, 2010, at 3:38 AM, Fred Drake wrote:


On Tue, Dec 14, 2010 at 6:24 AM, Steven D'Aprano  wrote:

The good thing about that idea is that maintenance of buggy.py will be so
simple!


It's self-describing, and needs no further documentation.  :-)



And psychologically more effective than deprecation.
Anyone writing "import buggy" probably feels like they
have got some explaining to do :-)


They might be intro retro-robotics:

  http://www.anf.nildram.co.uk/beebcontrol/buggies/bbc_buggy/index.html

(For those not in the UK, this was a very popular schools
project kit on the back of the famous BBC micro initiative)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] logging doc broken

[Tim Golden]

On 13/12/2010 11:21, Nick Coghlan wrote:

On Mon, Dec 13, 2010 at 9:04 PM, Vinay Sajip  wrote:

Tim Golden  timgolden.me.uk>  writes:



On 13/12/2010 10:31, Vinay Sajip wrote:
[...]

Ideally, link to the wrong doc section on docs.python.org in your bug report.


Now that's not a piece of advice you see very often :)



True, but this area changed after 2.6 was released (after even 2.7, IIRC), so I
want to be sure that if I'm going to change the doc sources on release26-maint,
I'm doing the right thing.


It was more a comment on the fact that, at first glance, that sentence
looks like an instuction to provide an incorrect link, rather than to
provide a link to the section of the docs that is incorrect. Just a
quirk of English grammar :)


Thanks, Nick. That is what I meant. I wanted to indicate that
it was tongue-in-cheek, but I never can remember the sequence
of characters which means that...

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] logging doc broken

[Tim Golden]

On 13/12/2010 10:31, Vinay Sajip wrote:
[...]

Ideally, link to the wrong doc section on docs.python.org in your bug report.



Now that's not a piece of advice you see very often :)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Removal of Win32 ANSI API

[Tim Golden]

On 11/11/2010 16:07, Hirokazu Yamamoto wrote:

Hello. Is it possible to remove Win32 ANSI API (ie: GetFileAttributesA)
and only use Win32 WIDE API (ie: GetFileAttributesW)?
Mainly in posixmodule.c.
I think we can simplify the code hugely. (This means droping bytes
support for os.stat etc on windows)

# I recently did it for winsound.PlaySound with MvL's approval


+1 from me

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

[Tim Golden]

On 12/10/2010 7:17 PM, R. David Murray wrote:

On Tue, 12 Oct 2010 19:33:52 +0200, 
=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=  wrote:

So as well as pysetup.py/.exe I would like pysetup-3.2.py / .exe on
Windows please. (I'd really like a python-3.2.exe as well.)


Please submit a patch to the installer, then.

I'm still skeptical about adding PATH, because
a) I find that fairly invasive, and despise long paths myself
(it hurts my eyes to see the list of directories that VS adds to MY
path)


Assume, for the sake of the argument, that we patched the
MSI so it (optionally) added the installing version of Python
(and, optionally ./scripts) to the PATH. What, then, do we
do with existing PATH entries which point to older/other Python
installations? Option (a) says: clear them
all out, because it's meaningless having more than one entry
with a python.exe on it and the one we want must be this one
because we've just ticked a box to say so. Option (b) says:
don't mess with other entries on the PATH; it's not done.

That said, the current installer switches an APPPATH entry and
changes -- optionally -- the file associations to point to
the installing version, so there is a precedent for ditching
previous data.

I'm actually +0 on the idea. An expert user who's trying to
juggle different Python versions should be able to sort
himself out. A naive user can use Start > Run > Python to
get the current version (thanks to the APPPATH) and can
use "program.py arg1 arg2" on the console to run program.py
with the associated version. (Notwithstanding the bug which
doesn't correctly redirect output via file associations)

But all this is pie in the sky until someone actually integrates
such a change to the MSI. Martin's clearly not going to since
he doesn't like the idea. I'm actually +0.5 on including a
script in tools\scripts (or wherever) which, when run, would
set as current the version of Python which ran it. I have a  roughly
working version of such a thing; the problem is getting it to
work with all the different Python versions and all the different
Windows versions we support.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

[Tim Golden]

On 23/09/2010 13:28, "Martin v. Löwis" wrote:

add relevant keywords to make it easier to find in searches

-0. Going through old issues just to make sure the keywords are right
seems wasteful.



Hard as it may be to believe, we do have (and are trying to cultivate)
people who want to contribute to Python and start by searching for
issues at the bug tracker.


Sure. However, on any specific search, many issues come up already.
So people searching for stuff to do will easily find tasks already.


Seems to me that the distinction to be made here is between activity
which might, to some, appear a waste of time (eg setting flags and versions
on existing calls) but which at worst provides no benefit and in fact
might help someone narrow down a search more easily; and activity
which is simply flatus vocis and which actually distracts or irritates.

Individuals' thresholds clearly vary.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

[Tim Golden]

On 23/09/2010 10:38, "Martin v. Löwis" wrote:

Let me ask a question which I don't think has been asked in this
thread: are there guidelines for tracker-trawlers? I'm never sure
where to look for this kind of thing myself. If there's nothing,
I'm happy to pen a dos-and-donts (which I might do anyway, simply
as a blog entry...)


Can you please rephrase the question? What's a "tracker-trawler"?


My invented terminology for someone -- like Mark -- who invests time
in going through issues in the tracker with a view to assessing them,
prioritising them, de-duplicating, etc. As opposed to someone who's
looking through issues with a view to finding things to fix within
a particular area of competence.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Goodbye

[Tim Golden]

On 23/09/2010 09:46, Georg Brandl wrote:

Am 23.09.2010 09:18, schrieb "Martin v. Löwis":

I personally think that the tracker fields and how they should be set is
of minor importance. If there is a bug in Python, the most useful
contribution is to submit a fix (or provide a rationale why this is not
a bug). Asking every now and then "is this still an issue", or setting
the version number, doesn't really advance the issue.


It does however attract attention from developers who either weren't around
when the original issue was submitted, or didn't feel competent enough to
fix it then.

It is also helpful to try reproducing the bug with a current version, in
case the issue has been fixed already -- whether because of a duplicate
bug report or by "chance".



I think my experience is that of several others. The work done by
Mark and other tracker-trawlers has been useful: to dust off issues,
attempt to assess their current validity, add suitable people to
nosy lists, and where possible to try to reproduce or to encourage
an OP to provide patches or other useful input.

I've addressed, closed, or at least taken note of several issues
in this way which I might not otherwise have done.

The two less useful overspills of this generally useful activity
have been: simple noise of the "Is anyone interested in this?"
variety -- although even that might be useful, as Georg says, in
highlighting older issues to newer developers; and the over-eager
closure of calls on the basis of lack of response, and it seems
to be an excess of this last which has brought the matter to a
head.

Let me ask a question which I don't think has been asked in this
thread: are there guidelines for tracker-trawlers? I'm never sure
where to look for this kind of thing myself. If there's nothing,
I'm happy to pen a dos-and-donts (which I might do anyway, simply
as a blog entry...)

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Tim Golden]

On 13/08/2010 10:02 PM, Michael Foord wrote:

On 13/08/2010 06:39, Stephen J. Turnbull wrote:

Michael Foord writes:

   >   How is ~/python not memorable or consistent? (And cross-platform
   >   memorability and consistency is valuable too.)

But what does "~" mean on Windows?

There is a "user directory" in Windows directly analagous to ~, and this
is the path returned by os.path.expanduser('~') in Python:


Well, see my post early on in the thread about the
various senses of "user directory" under Windows.
The addition of expanduser to include Windows caused
a long debate at the time.  (ISTR)

I'm not really all that bothered for this purpose.
There's something to be said for all the suggestions
so far. However, as I've said elsewhere, I'm more
concerned that whatever we end up choosing for
location(s) be clearly documented as such.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Tim Golden]

On 12/08/2010 12:17, Michael Foord wrote:


How is ~/python not memorable or consistent? (And cross-platform
memorability and consistency is valuable too.)


I was thinking outside Python rather than inside it (where ~ has no
meaning on Windows) but you make a good point here. If we were just
discussing Python code this would effectively be a winning point IMO.


Another issue is discoverability. Many users won't know about these
config files unless they *see* them.


While I sympathise with this, I'm not sure how much weight
one should give it in the context of this discussion. In the Unix
world, if I were guessing, I would justifiably look in
~/.myapp followed perhaps by /etc/myapp. On Windows, I might go
for the registry, as you mention elsewhere, and look in
HKLM\Software\MyApp but for actual files I'm not sure where
"discoverable" would be.

re: using the Registry: To be honest, I was answering the literal
question posed by Eric: where to put config files? Not the wider
question: how should config data be stored? Where the answer to
the latter question might be: the Registry -- much as I find it
awkward to work with at times.

One very definite point in its favour as regards this discussion
is that Python on Windows *already* defines a key in the Registry
(and has done so since v2.0 at least) and it would make some sense
to place things under there.

Ultimately, I don't feel very strongly about this subject. I'm more
concerned that the chosen location (file or registry or whatever) be
documented -- and documented from a Windows perspective as well, so
you don't have to guess what "HOME" means in this context.


TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Tim Golden]

On 12/08/2010 11:40, Michael Foord wrote:

User editable configuration files are very different from libraries. The
per user site-packages folder *should* be hidden somewhere out of the
way where you can get at them if you want them but won't stumble across
them all the time. e.g. AppData on Windows.

For files we expect the user to be able to edit we shouldn't go out of
our way to make them hard or inconvenient to find.


This really comes down -- as with the Mac discussion last week, I
think -- to the tension between standard file locations and easy-to-get-to.
The difference on Windows, though, is that while on Mac it's either:
Apple standard /This/That/TheOther vs Unix standard $HOME/.something
on Windows it's %APPDATA%\myprog vs whatever-I-thought-of-at-the-time.

APPDATA isn't actually that hard to get to on any version of Windows
post 2000. (Just stick %APPDATA% into any Explorer window -- even
IE, for goodness sake). Even from the command line it's not hard:

notepad "%APPDATA%\python\python26\idle.ini"

Ultimately, as a Windows user/developer, I'd vote for a memorable
consistency, which for me would be %APPDATA%\python\... If everything's
in one place, I'll just create a shortcut / hardlink / whatever to get
me there when I want to change things.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Tim Golden]

On 12/08/2010 10:50, Tim Golden wrote:

Unfortunately, the canonical place is not always the place most
used. Especially since the convention under *nix is to place dotfile
or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
various locations are considered $HOME, including (but not limited
to):

* the directory pointed to by %HOME%
* the directory pointed to by %USERPROFILE%
* the "My Documents" shell folder
(often, but not always, %USERPROFILE%\My Documents)
* c:\ (no: really)
* the NT profile home directory (typically a mapped share)


Additionally, on Windows Python expands ~ to the first of:

%HOME%
%USERPROFILE%
%HOMEDRIVE%\%HOMEPATH%

all of which are perfectly defensible defintions of "Home" on
Windows. But combining that with the Unix-minded concept of
"create a dotfile called ~/.myapp" means you get dotapps in
non-standard places on Windows.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Tim Golden]

On 12/08/2010 11:18, Steve Holden wrote:

On 8/12/2010 5:50 AM, Tim Golden wrote:


[... snip explanation of standard & non-standard locations ...]


Didn't we have this discussion when per-user libraries came up?
Shouldn't we be using a subdirectory of that location?


Yes we should. My explanation above was really just painting the
picture. It should have been an Appendix for the Truly Interested.


One might make a case that all configuration data should be stored in a
single SQLite database (with a suitable API to hide the relational
nature of the store). Then at least there would only be one file no
matter how many versions of Python were installed. Seriously. We are
already spending enough time doing stat calls on non-existent directories.


-1 on this. I don't care how many stats we're doing; I want to be able
to see my configuration / libraries etc without firing up a sqlite
session.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fixing #7175: a standard location for Python config files

[Tim Golden]

On 11/08/2010 16:22, Éric Araujo wrote:

It would be nice to define one standard location for config files used
by stdlib modules, and maybe also by third-party programs related
closely to Python development (testing tools, static code checkers and
the like), in a way that doesn’t clutter the user home directory with a
dozen dotfiles while still being easily found.

(The Unix notions of dotfiles and home directory have to be adapted to
use non-dotfiles in some standard place on various Windows. The Mac
experts disagree on the right directory to use.)


The canonical place on Windows (per Microsoft [1]) is:

for roaming data: the Application Data folder (exposed as the
APPDATA env var and as CSIDL_APPDATA pre-Vista and the
FOLDERID_RoamingAppData Known Folder on Vista+).

for non-roaming data: the local app data (CSIDL_LOCAL_APPDATA
or FOLDERID_LocalAppData)

The obvious difference is whether a user expects the data to be
available for the same account on a different computer. At present,
the user site packages are held under %APPDATA%\Python\Pythonxx,
ie are considered roaming.

Unfortunately, the canonical place is not always the place most
used. Especially since the convention under *nix is to place dotfile
or dotdirs under $HOME. Windows doesn't, by default, have a $HOME so
various locations are considered $HOME, including (but not limited
to):

* the directory pointed to by %HOME%
* the directory pointed to by %USERPROFILE%
* the "My Documents" shell folder
  (often, but not always, %USERPROFILE%\My Documents)
* c:\ (no: really)
* the NT profile home directory (typically a mapped share)

Dotfiles are possible on Windows; the issue is that they can't
be created within the shell (ie within Windows Explorer). They
can be renamed, edited, etc without issue, so it's not much of
a problem. They can be created by any program which can call
CreateFile -- including Python, obviously.

TJG

[1] http://support.microsoft.com/kb/310294
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] New Summary Lists on Issue Tracker

[Tim Golden]

On 11/08/2010 16:45, Ronald Oussoren wrote:


On 11 Aug, 2010, at 16:21, Tim Golden wrote:


Thanks to whoever's been working on the new Summary lists on the Issue Tracker.
The "Followed by you" / "Created by you" / "Assigned to you" are just what
the doctor ordered.


I'm not quite happy about them because these reports include closed issues 
which is noise most of the time, and because issues aren't grouped or ordered 
by priorities.


Hadn't noticed that in my enthusiasm about having them at all.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] New Summary Lists on Issue Tracker

[Tim Golden]

Thanks to whoever's been working on the new Summary lists on the Issue 
Tracker.

The "Followed by you" / "Created by you" / "Assigned to you" are just what
the doctor ordered.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
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-checkins] r83831 - in python/branches/release31-maint/Lib: subprocess.py test/test_subprocess.py

[Tim Golden]

On 08/08/2010 11:31 PM, Eric Smith wrote:

On 8/8/10 12:18 PM, tim.golden wrote:

Modified: python/branches/release31-maint/Lib/subprocess.py
==
--- python/branches/release31-maint/Lib/subprocess.py   (original)
+++ python/branches/release31-maint/Lib/subprocess.py   Sun Aug  8 18:18:18 2010
@@ -829,7 +829,7 @@
   startupinfo.dwFlags |= _subprocess.STARTF_USESHOWWINDOW
   startupinfo.wShowWindow = _subprocess.SW_HIDE
   comspec = os.environ.get("COMSPEC", "cmd.exe")
-args = comspec + " /c " + args
+args = comspec + " /c " + '"%s"' % args
   if (_subprocess.GetVersion()>= 0x8000 or
   os.path.basename(comspec).lower() == "command.com"):
   # Win9x, or using command.com on NT. We need to


If args is a tuple, this fails with a TypeError. I realize args
shouldn't be a tuple, but that's not a great failure if it is. I think
this would be better written as:

   args = '{} /c "{}"'.format(compspec, args)




Thanks, Eric. I'll rework.

TJG
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Windows

[Tim Golden]

On 04/08/2010 16:38, Steve Holden wrote:

On 8/4/2010 11:00 AM, Brian Curtin wrote:

On Wed, Aug 4, 2010 at 09:48, Barry Warsawmailto:ba...@python.org>>  wrote:

 On Aug 03, 2010, at 09:08 PM, 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.

 Should note that I did try to build Python using my MSDN license for
 Windows 7
 and Visual Studio 2010.  I only had an hour or so to attempt it, and
 did not
 succeed, though I think I got as far as trying to properly situate
 various
 dependent libraries (sqlite, ssl).

 If anybody's successfully navigated the twisty maze, would you be
 able to
 write something up on the wiki to describe the steps you've taken?

 -Barry


I can expand the dev setup guide I wrote for the PSF Sprints to include
the third-party stuff, then try to get that in wider circulation. I
currently gloss over it to get a first-time contributor up and running
quickly (since someone's first look into core dev is unlikely to be
fixing sqlite).

I haven't tried the current codebase on VS2010 yet, but it's on my todo
list.


I think that could be incredibly useful. I've tried building Windows
Pythons in the past and stalled because I didn't have enough familiarity
with the VS environment.


Brian: could you remind us where that doc is, please? I've lost track of it.

In broad terms it's not too hard to get going once you've installed 
VS[*]; I've
rebuild several different fresh Python checkouts several times today 
while these

issues have been discussed, and generally it's a question of:

cd py3k (or whatever)
tools\buildbot\externals.bat
cd py3k\pcbuild
env
build -d
rt -d

and you're done and tested.

That said, I seem to be having build issues with ssl on 2.7 which I'll
try to look into. But the technique is fairly straightforward.

TJG

[*] And a small clutter of other tools for certain bits
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com