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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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] 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] 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] 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] 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] 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] [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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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] 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

[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

[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

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

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] [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 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] 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 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 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] 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] 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] 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] 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] 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] 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] 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] 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] 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 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] 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] 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] 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

[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/

[Python-Dev] Building Py3K branch docs with Sphinx

[Tim Golden]

Can I ask which flavour of Sphinx is being used to build the py3k docs? 
I've taken the naive approach of simply pulling the sources from

branches/py3k and then calling make checkout to fetch the appropriate
sources, but these are from http://svn.python.org/projects and are
the same for 2.x and 3.x (and don't work under 3.x).

The latest sphinx from its mercurial tip repo has the same issues
so I wondered whether built the released docs used some other svn 
source or simply patched. The readme points out that the code won't 
work under Python 3.x but someone's managed to build the docs for 
the already-released versions.


(using the make.bat under Windows, but AFAICT the unix-style Makefile 
would have the same issues).


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] Building Py3K branch docs with Sphinx

[Tim Golden]

Tim Golden wrote:
Can I ask which flavour of Sphinx is being used to build the py3k docs? 
I've taken the naive approach of simply pulling the sources from

branches/py3k and then calling make checkout to fetch the appropriate
sources, but these are from http://svn.python.org/projects and are
the same for 2.x and 3.x (and don't work under 3.x).



... or I could just use an existing Python 2.x installation to build
the 3.x docs. Obviously. (slaps forehead)

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] Building Py3K branch docs with Sphinx

[Tim Golden]

andrew cooke wrote:

Tim Golden wrote:

Tim Golden wrote:

Can I ask which flavour of Sphinx is being used to build the py3k docs?
I've taken the naive approach of simply pulling the sources from
branches/py3k and then calling make checkout to fetch the appropriate
sources, but these are from http://svn.python.org/projects and are
the same for 2.x and 3.x (and don't work under 3.x).


... or I could just use an existing Python 2.x installation to build
the 3.x docs. Obviously. (slaps forehead)


I asked about this on the Sphinx list a while back.  I didn't get any
response at the time, but checking now I see that a week later someone
(the author I assume) commented -
http://groups.google.com/group/sphinx-dev/browse_thread/thread/9a0286f5deeb2912/778a02c397295add

So it seems that there is no public solution until release 0.6, and that
you cannot be able to run doctests when running with a "different" Python
version (my code should work with 3.0 and 2.6, so tests might work; for
some reason I can no longer remember I disabled that).



Thanks for the update; the thing's a bit complicated because Sphinx
is based on docutils and docutils makes heavy use of except ABC, def
and of unicode strings. I tried hand-changing it briefly but it all
got a bit cumbersome. Maybe 2to3 will work ok. For now, tho', I've
switched to using 2.x to generate and all is well.

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] Building Py3K branch docs with Sphinx

[Tim Golden]

Martin v. Löwis wrote:

Can I ask which flavour of Sphinx is being used to build the py3k docs?


The proper procedure to build the documentation is

make update
make htmlhelp #say



I think you misunderstood my question. I can build the docs
for 2.x, say -- have done so, in fact many times. 
I was simply trying to use Python 3.x itself

to build the docs for Python 3.x, not realising at first
that Sphinx (and docutils, Jinja etc.) won't actually
run under 3.x. 


Of course, as I later realised, I can just build them with
an existing 2.x install. I think I was sort of hoping to
have it produce its own dogfood, so to speak :)

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 for Windows??

[Tim Golden]

David H. Burns wrote:
I downloaded what claims to be Python for Windows (3.01). The tutorial 
brags a lot about how easy it is to learn, but the tutorials and 
instruction seem to be for a Linux or Unix version. There are three 
executable programs in the Python directory and no indication which 
should be used to start Python. One opens a Dos-like window presumably 
for  "command-line" entry. I can't make anything of it.


[as pointed out elsewhere, this is the wrong list for
this question, but just to get you going...]

The Python docs have a section on running Python
on Windows. This is the online version:

  http://docs.python.org/using/windows.html

The .chm version should be in c:\python31\doc\python31.chm

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] Anyone knows how to compile pywin32 for 64bit operating system

[Tim Golden]

Michael Foord wrote:
pywin32 has its own mailing list where you are more likely to get an 
answer to your question:


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


And, just for accuracy's sake: that list isn't a list for
pywin32 stuff as such -- although it's obviously a good
place to ask. It's for Python development under Windows
in general. pywin32 has its own trackers shown here:

 http://sourceforge.net/projects/pywin32/support

Nonetheless, I certainly second the recommendation to post
to python-win32.

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 2.7b1?

[Tim Golden]

On 10/04/2010 17:02, Brian Curtin wrote:

I contacted David Bolen for some details about the his buildbot because I
can't reproduce the failure on any Windows XP, Server 2003, or 7 box that I
have, and it's also not a problem on the other XP buildbot. He's traveling
at the moment but will try to get me access to the box after the weekend is
over.


Might it be significant that he's running a Cygwin build of Python?
I've only run the tests on a native Win32 build myself, and I imagine
that's true for you 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

Re: [Python-Dev] MSDN licenses available for python-dev

[Tim Golden]

On 19/04/2010 13:33, Paul Moore wrote:

On 19 April 2010 11:47, Antoine Pitrou  wrote:

Le Fri, 16 Apr 2010 08:01:54 -0500, Brian Curtin a écrit :


The recent threads on builds/installers for Mac and Windows reminded me
of Steve Holden's push to get the python-dev team equipped via a
connection with the Microsoft Open Source Technology Center. The OSTC
team provides Microsoft Developer Network licenses to open source
projects to assist them in better supporting Windows.

I've talked with Steve (who passed the task to me) and the Microsoft
folks, and they are happy to provide more licenses if needed. If you are
interested in getting a copy of MSDN, please contact me off-list.


Does it include a license for Windows itself?
Does it allow me to install and run it in a VM?
If so, I'm interested.


Yes. Arguably that's the best thing about the MSDN licenses
(particularly for non-Windows users, but even for us Windows users to
set up "clean" VM environments).


For some reason I hadn't appreciated that this was the case. I'm in
the process of negotiating [*] to repurpose an out-of-work server here
as a buildbot and being able to install an O/S will smooth the
negotiations considerably. I'm especially keen to get a buildbot
running a Windows server OS rather than desktop.

TJG

[*] May come to nothing; don't hold your breath
___
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] Planning a Windows buildbot

[Tim Golden]

I've got agreement in principle for one of our decommissioned
servers to be repurposed as a Python buildbot. My idea would
be to set it up as a Windows 2003 R2 server, at least partly
because we don't seem to have any Windows server buildbots
and it's a platform I'm especially interested in.

Does anyone suggest that a different configuration would be
preferable? Thanks to the PSF MSDN license I can pretty much
choose whatever I want. I believe Brian Curtin's looking at
the possibility of a Win2k8 box which is one reason why I
steered away from that. Also because my box -- whenever they
hand it over -- will be relatively old.

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] Email addresses for new committers for python-committers

[Tim Golden]

On 20/04/2010 20:42, Brett Cannon wrote:

If you are a committer and are NOT subscribed to the python-committers
mailing list (I believe this at least includes Giampaolo, JP, and Brian),
then please either reply to this email with your preferred email address or
let me know directly (the former is preferred so Georg or Eric can beat me
to the subscription if I take too long).


I did subscribe earlier today, and replied to the usual "please confirm"
email, but instead of the conventional "You're on the list" email I got
a slightly ambiguous "You're due to be moderated" email. If you can confirm
that I'm subscribed then all well and good. If not, let me know if there's
something else I should do.

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] Mailbox module - timings and functionality changes

[Tim Golden]

On 29/06/2010 15:26, Steve Holden wrote:

Nick Coghlan wrote:

Command line: ./python -m test.regrtest -v test_mailbox

trunk: Ran 274 tests in 25.239s
py3k: Ran 268 tests in 26.263s

So I don't see any substantial difference on a Kubuntu 10.04 box (both
builds are recent'ish, but not completely up to date).

However, the underlying IO access is significantly different between
POSIX and Windows, so there could still be something pathological
happening at the filesystem manipulation layer. My comparisons are
also 2.7 vs 3.2 rather than 2.6 vs 3.1.

Cheers,
Nick.


Thanks for all the timings! If a Windows user could do the same thing
that would help ...


WinXP SP3

2.6 Ran 272 tests in 13.172s
3.1 Ran 267 tests in 15.735s
py3k A *lot* of ERROR and FAIL tests

WinXP SP3

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] Mailbox module - timings and functionality changes

[Tim Golden]

On 29/06/2010 15:51, Tim Golden wrote:

On 29/06/2010 15:26, Steve Holden wrote:

Nick Coghlan wrote:

Command line: ./python -m test.regrtest -v test_mailbox

trunk: Ran 274 tests in 25.239s
py3k: Ran 268 tests in 26.263s

So I don't see any substantial difference on a Kubuntu 10.04 box (both
builds are recent'ish, but not completely up to date).

However, the underlying IO access is significantly different between
POSIX and Windows, so there could still be something pathological
happening at the filesystem manipulation layer. My comparisons are
also 2.7 vs 3.2 rather than 2.6 vs 3.1.

Cheers,
Nick.


Thanks for all the timings! If a Windows user could do the same thing
that would help ...


WinXP SP3

2.6 Ran 272 tests in 13.172s
3.1 Ran 267 tests in 15.735s
py3k A *lot* of ERROR and FAIL tests


py3k HEAD on Win7 Ran 268 tests in 34.055s

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] Mercurial migration readiness

[Tim Golden]

On 02/07/2010 08:25, Dirkjan Ochtman wrote:

On Fri, Jul 2, 2010 at 02:08, Stephen J. Turnbull  wrote:

No, you don't.  You make links to 200MB+ (unless you're on Windows,
where I don't know how this works).  This is much cheaper than
copying, though not as cheap as in git.  I don't hesitate to make
branches in Mercurial.


It can still do hardlinks on Windows, provided the repo is on NTFS
(and I think NTFS supports only hardlinks within the same partition).


Strictly: on the same volume. (Which will generally but not always amount
to: under the same drive letter)

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] set/dict comprehensions don't leak in Py2.7 - intentional?

[Tim Golden]

On 05/07/2010 14:06, Stefan Behnel wrote:

Hi,

I only noticed now that set/dict comprehensions were backported to 2.7
without letting the loop Variables leak into the surrounding scope. So
they now behave different from list comprehensions. Is this intentional
or just a backporting oversight?

I'm asking because we had a discussion about the 'right' semantics
several times on the Cython list, and the current behaviour is that all
comprehensions leak when compiling Py2 code and the do not leak when
compiling Py3 code. I would hate to fix that up to match 2.7 and then
see that the behaviour in Py2.7 is to be considered an accident.


Depends on your definition of "comprehension", but generator expressions
have always not leaked, so these are already different in Py2.x:

[i for i in range (10)]

list (i for i in range (10))

I had understood (without being able to put my finger on a relevant thread)
that all comprehensions were going not leak their loop variables in the
future.

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] mkdir -p in python

[Tim Golden]

On 17/07/2010 11:03 PM, Peng Yu wrote:

I don't see that there is a function in the library that mimic the
behavior of 'mkdir -p'. If 'makedirs' is used, it will generate an
error if the file already exists. There are some functions available
on the website to close the gap. But I'd prefer this is in the
library. Is there any plan to add a function that mimic the behavior
of  'mkdir -p'?


If I were you I'd ping Tarek who's taken ownership of the shutil
module. It would go there if it went anywhere.

That said, it's not clear just how far the stdlib should go to
mimic every switch and option of shell commands...

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] Python Language Summit EuroPython 2010

[Tim Golden]

Before the main events of EuroPython 2010 a Python Language Summit took
place at the Conference venue in Birmingham. Present were (in the order
they sat around the table):

* Brett Cannon
* Guido van Rossum
* Holger Krekel
* Amaury Forgeot D'Arc
* Georg Brandl
* Péter Szabó
* Ezio Melotti
* Michael Foord
* Mark Dickinson
* Martin von Loewis
* Ronald Oussoren
* Tim Golden
* Marc Andre Lemburg
* Richard Jones

Michael initiated a round-up of current and prospective Python versions for
various implementations. CPython and IronPython have both just released
v2.7 with IronPython offering some Py3 compatibility via a command-line
switch. The recent/current migration of Numpy and SciPy to Py3 should
give a boost to uptake. Amaury confirmed that PyPy currently supports
2.5.2 but is looking to target 2.7.

The PyPy guys also announced a C API bridging layer which should enable
a range of Python extension modules to work directly with PyPy. This is
only a stepping stone by way of broadening support. Brett suggested that
the Unladen Swallow merge to trunk was waiting for some work to complete
on the JIT compiler and Georg, as release manager for 3.2, confirmed that
Unladen Swallow would not be merged before 3.3.

The email module needs some work in Py3. David Murray has been given some
money by the PSF but needs more from other sources to complete the work.
This is hampered by the legalities around commercial organisations making
donations to not-for-profits when those donations are earmarked. Various
suggestions were put forward with no-one sure of the legal issues. Guido
suggested that we should move forward rather than stall for want of legal
advice.

A broad discussion arose concerning the issues debated on web-sig concerning
the WSGI protocol and the bytes vs string issues. Marc Andre brought up the
cgi module which has similar issues under Py3 and other examples were given,
including ftplib, urllib and some os functions. Various solutions were put
forward including a hybrid bytes-with-encoding object. This proposal was widely
unpopular, but two proposals met with broad approval: that certain stdlib
functions might be polymorphic, returning the type of their input as output;
and that the encoding string should include its error-handling. An example
of the first would be that os.getenv ("HOME") would return "/home/tjg" while
os.getenv (b"HOME") would return b"/home/tjg". An example of the latter would
be "utf8:strict". Something of the sort already works for PYTHONIOENCODING.

The issue of a __format__ equivalent for bytes was also raised as was the
idea of object methods to render an object as string or bytes, which could
be used in the polymorphic functions above.

Martin spoke about the state of the stable ABI PEP, indicating that he was
targetting 3.2. This work would reduce the need to recompile extension
modules separately on Windows for every version of Python -- something
especially pertinent when code has been orphaned but is still useful.
The versioned .so files PEP being worked out by Barry Warsaw overlaps with
this PEP and would only be useful for extensions which don't target the
stable ABI.

A messy discussion turned on the question of garbage collection of module
objects, and the order in which finalisers are called if at all, especially
when reference cycles exist. Marc Andre was proposing a __cleanup__ magic 
function
for Python modules, which would enable the implementer to define the order
in which resources are released / closed down. This is quite a subtle area
and raised the issue of unfinalised objects in a reference cycle whose
memory has been freed out from under them but which still exist. Martin 
described
the Java approach where finalisers are called once and then flagged so
they are not called again even if their object is resurrected. This sounded
like a useful approach for Python but would break code which expected to
be able to resurrect an object during its __del__ method... which is not
expected to account for much code.

Guido pointed out that no-one can be expected to hold enough of the complexities
of this area of Python's implementation in their head, and that an 
implementation
of some sort would need to be written so that the corner-cases could emerge.

Ronald described the issues around the version and architecture differences
on Mac OS X and especially around Tkinter (and therefore IDLE). It was agreed 
that
two installers could be provided: one targetting OS 10.3 on 32-bit Intel/PPC;
the other targetting 10.6 on 32 and 64-bit Intel. This latter would then be
able to use the system's Tk 8.5. The 10.6 binary would also work for 10.5,
which would be indicated in the install docs.

The Mercurial migration should move forward once Dirkjan has finished work
on his thesis. Martin insisted that a for-real repository would have to be
set up so that people can really see how it would work. An outstanding i

Re: [Python-Dev] No response to posts

[Tim Golden]

On 02/08/2010 8:40 PM, "Martin v. Löwis" wrote:

I think it's important to find out what people expect when posting
to the tracker. Maybe a mandatory radio list with these options
would help:

- I post this to get help from you
- I'm willing to work on other issues to expedite processing of this one
- The issue is not urgent, take your time


Or, clearly in some cases:

- I'm just letting you know and walking away; I'm not particularly
interested in pursuing it any further as I've already worked around it.

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 02:08, Steve Holden wrote:

It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.

I wonder if anyone can think of a way we can get some Windows skillz
into the group that could assist at ties like this. Some brainstorming
might find a way through.


My own problem is just the amount of ramp-up time (as a proportion of
my own available time) to get hold of a problem even when I see it.
(Speaking here in the more general sense of fixing Windows-related
Python bugs).

As one who has benefitted from the MSDN largesse I am certainly conscious of
the responsibility to contribute benefits back to the Python community.
On the basis that I'm far more likely to watch a buildbot which I actually
administer, I have recently nudged my sysadmins here to see if they can
make good on their promise to find me a spare server to use as a buildbot.

I have watched the buildbot pages occasionally, especially when I see
Windows-related commits going in, but several times "red" buildbots
have turned out to be -- apparently -- environmental / local issues
unrelated to commits. Obviously I could/should have contacted the
buildbot owner to at least inform him or her that something was amiss.
But somehow at that point one's technical enthusiasm for fixing a
problem diminishes when it's not clear that there *is* a problem.
(Grumble, grumble, mutter, mutter... :) )

While we'd certainly benefit from more Windows skills, we'd probably
benefit more from people who have more *time* to look at Windows
issues. OK; to propose something concrete: I'll write a blog post
and advertise on python-win32 to ask for Windows people who perhaps
might at least be interested in contributing time. I will also
advertise (and maybe enhance) Brian Curtin's how-to doc on Windows
Python core development... which I can't quite lay my hands on at
the moment. Hopefully we can lower the perceived entry-bar for
contribution at different levels.

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 05:34, Mark Hammond wrote:

On 4/08/2010 11:08 AM, Steve Holden wrote:

It's a little disappointing to discover that despite the relatively
large number of developers who have received MSDN licenses from
Microsoft, none if us have the time to make sure that the buildbots are
green for the 2.6.6 release.

I wonder if anyone can think of a way we can get some Windows skillz
into the group that could assist at ties like this. Some brainstorming
might find a way through.


I never go looking at the buildbots to look for problems - maybe some
way of explicitly bringing such failures to peoples attention would be
good


Agree with that. This page looks hopeful:

  http://www.python.org/dev/buildbot/

with Atom/RSS feeds and an XML-RPC interface. I've subscribed to the
RSS feeed which is -- from my perspective -- quite noisy. One could
do something with the xml-rpc according to this:

  http://buildbot.net/buildbot/docs/0.7.11/#XMLRPC-server

but does anyone know how easy it would be use setup a mail notifier
to go to a specific Python mailing list on failure? I've looked at
mail.python.org and Googled around and I can't see something which
already does this, but I'm very happy to be wrong...

There seems to be some previous discussion:

  http://mail.python.org/pipermail/python-dev/2006-October/069617.html

but no sign of an outcome.

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

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

[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] 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

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] 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 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: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 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 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] 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] 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 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] 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] 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

[Python-Dev] Apologies from the CBS autoresponder

[Tim Golden]

My many apologies to those who had their New Year
interrupted by my company's inane autoresponder.
I'm afraid that I went on leave for a week without
suspending list delivery just as my company changed
its name and sent out (unknown to me) an automatic
message to *everything* coming in to the old address.

I've pulled the plug on that address's subscription,
altho' I suspect some list admin got there before me.
Apologies again.

Tim Golden
___
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] splitext('.cshrc')

[Tim Golden]

Terry Reedy wrote:
> "Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
>> I consider it correct, or at the least, don't think it should be changed,
>> as it would make the behavior more difficult to reason about and introduce
>> yet another thing to worry about when writing cross-version code.
> 
> Windows did not allow .xxx as a filename in my attempts, so this case seems 
> irrelevant there.

Windows is a bit funny there. You can't create a ".xxx" filename
in Explorer, but you can from Console/the API:


import os

f = open (".xxx", "w")
f.close ()
os.path.isfile (".xxx")
# True


Not that this helps anything, really, but just
to make the point :)

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] 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] 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] 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] [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] 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] 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

[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] 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

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] 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