Nick Coghlan | 1 Jul 03:50 2011
Picon

Re: svn.python.org confusion

On Fri, Jul 1, 2011 at 1:40 AM, Tres Seaver <tseaver <at> palladion.com> wrote:
> On 06/30/2011 10:32 AM, Barry Warsaw wrote:
>> I'm not against adding this to svn, but please be sure these files don't leak
>> into the tarballs should we need to cut another 2.5 or 2.6 release.  I think
>> that just means tweaking sandbox/release/release.py.
>
> The fact that releases might / will still be made from those branches
> argues against including the file on them at all:  they are in fact the
> "canonical" repository locations, even if most of the work is done in hg
> and patched into them.

Indeed, 2.5 and 2.6 should be left alone. +1 on adding such a file to
the more recent branches that are handled in hg, though.

Cheers,
Nick.

--

-- 
Nick Coghlan   |   ncoghlan <at> gmail.com   |   Brisbane, Australia
Mark Hammond | 1 Jul 04:21 2011
Picon

Re: PEP 397 (Python launcher for Windows) reference implementation

On 30/06/2011 10:09 PM, Vinay Sajip wrote:
> There's a lot to like in the PEP, and I have some questions relating to the
> latest version:
>
> 1. In the section on shebang line parsing, it says "If the command starts with
> the definition of a customized command followed by a space character, the
> customized command will be used." Sorry if I'm being dense, but what's the
> significance of the trailing space character? In fact, your vpython example in
> the customeised comments section doesn't show a trailing space - you've used
> '#! vpython' as the shebang line.

This is just clumsy wording on my part - what I'm trying to say is 
simply that 'vpython3' will not match a customized command 'vpython'.

> 2. The section on .ini files says that "Commands specified in the [.ini file
> in the] "application directory" [APPDATA] will have precedence over the one
> next to the [launcher] executable." What's the benefit of this?

The idea is that a user without admin permissions can customize the 
behaviour - so the admin can add a .ini file, but the user can override 
any commands in that file with their own definitions.

> If you have
> only one launcher executable of one type (say console, 32-bit) on a system,
> then there's no point in having two locations for .ini files.

The idea is that some users will not have permission to edit the one 
next to the launcher.  I'd be open to considering this yagni if others 
agree.

(Continue reading)

Bernie Bill | 1 Jul 06:56 2011
Picon

Re: commant

and thanks!!

lederbill
<div><div>
<div>and thanks!!</div>
<div><br></div>
<div>lederbill</div>
</div></div>
Ulrich Eckhardt | 1 Jul 08:51 2011

Re: time.sleep(-1) behaviour

On Thursday 30 June 2011, R. David Murray wrote:
> Please file a bug report at bugs.python.org.

Filed as bug #12459.

Uli

**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann
vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie
nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder
gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten.
Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************

Victor Stinner | 1 Jul 11:18 2011

Re: [Python-checkins] cpython (3.2): test_os: add TemporaryFileTests to the testcase list

I tried to find which commit removes TemporaryFileTests from the
testcase list (to see if there is a good reason to do that, or if it's
just a mistake): it's somewhere between Python 2.x and Python 3.0, but I
didn't find the commit.

Is there a tool to detect that a testcase is never executed to ensure
that there is no other forgiven testcase?

Victor

Le vendredi 01 juillet 2011 à 03:06 +0200, victor.stinner a écrit :
> http://hg.python.org/cpython/rev/00a874ad4fc9
> changeset:   71104:00a874ad4fc9
> branch:      3.2
> parent:      71101:7c60c1b41da9
> user:        Victor Stinner <victor.stinner <at> haypocalc.com>
> date:        Fri Jul 01 02:56:15 2011 +0200
> summary:
>   test_os: add TemporaryFileTests to the testcase list
> 
> The testcase was never executed, it's now fixed.
> 
> files:
>   Lib/test/test_os.py |  1 +
>   1 files changed, 1 insertions(+), 0 deletions(-)
> 
> 
> diff --git a/Lib/test/test_os.py b/Lib/test/test_os.py
> --- a/Lib/test/test_os.py
> +++ b/Lib/test/test_os.py
>  <at>  <at>  -1344,6 +1344,7  <at>  <at> 
>          PidTests,
>          LoginTests,
>          LinkTests,
> +        TemporaryFileTests,
>      )

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Vinay Sajip | 1 Jul 11:20 2011
Picon

Re: PEP 397 (Python launcher for Windows) reference implementation

Mark Hammond <skippy.hammond <at> gmail.com> writes:

> The intention is that there only be a single launcher, as only one app 
> can be associated with .py files.  OTOH though, file associations can be 
> configured per-user IIRC, and assuming that is the case, we could avoid 
> my multiple-ini-file usecase above by just allowing a different launcher 
> to be registered for a specific user.  This is sounding difficult from 
> the UI perspective though (ie, does the installer then need to ask that 
> question, will there be a post-install technique for per-user 
> registration, etc?)

I don't like this, for the reasons you state. I think it would be better if the
PEP was changed to say that there is intended to be just one launcher
installation per machine. As the intention is for the launcher to ship with
Python, and there can be multiple Pythons installed, I presume we'll have to
handle this by installing the launcher in some common-to-all-Pythons location
somewhere outside a Python installation location, such as "c:\Program
Files\Python Launcher". This should be stated in the PEP, and we'll also need to
indicate how the launcher will be cleaned up if for some strange reason someone
uninstalls all Pythons from a machine. Then we can just state that there's a
global .ini file (where the launcher is installed) and a local one (in the
user's APPDATA). From that perspective, it makes sense to have items in the
local (APPDATA) override the global (launcher installation location).

> Sure, that would be awesome!  I think that will mean your impl is fairly 
> close to the first draft of the PEP I checked into HG, which is nice and 
> still quite useful to use :)

Okay, I'll do this soon - once I've added a few tests. I've updated the
implementation to include help output.

BTW I thought of another thing that perhaps needs handling: what if a customized
command points to the launcher itself? It'd be turtles all the way down :-)

Regards,

Vinay Sajip

Antoine Pitrou | 1 Jul 11:24 2011
Picon

Re: cpython: Issue #12451: Add support.create_empty_file()

On Thu, 30 Jun 2011 23:25:59 +0200
victor.stinner <python-checkins <at> python.org> wrote:
> http://hg.python.org/cpython/rev/0c49260e85a0
> changeset:   71103:0c49260e85a0
> user:        Victor Stinner <victor.stinner <at> haypocalc.com>
> date:        Thu Jun 30 23:25:47 2011 +0200
> summary:
>   Issue #12451: Add support.create_empty_file()
> 
> We don't need to create a temporary buffered binary or text file object just to
> create an empty file.

Is there a reason for this?
I find it quite explicit and obvious what the following does:

    with open("somefile", "wb"):
        pass

so I wonder what replacing it with support.create_empty_file() brings
(except from having to lookup yet another helper function).

Regards

Antoine.

Victor Stinner | 1 Jul 13:12 2011

Re: cpython: Issue #12451: Add support.create_empty_file()

Le vendredi 01 juillet 2011 à 11:24 +0200, Antoine Pitrou a écrit :
> On Thu, 30 Jun 2011 23:25:59 +0200
> victor.stinner <python-checkins <at> python.org> wrote:
> > http://hg.python.org/cpython/rev/0c49260e85a0
> > changeset:   71103:0c49260e85a0
> > user:        Victor Stinner <victor.stinner <at> haypocalc.com>
> > date:        Thu Jun 30 23:25:47 2011 +0200
> > summary:
> >   Issue #12451: Add support.create_empty_file()
> > 
> > We don't need to create a temporary buffered binary or text file object just to
> > create an empty file.
> 
> Is there a reason for this?

The code was correct. I think that a function with an explicit name is
better than the open().close() pattern (which has various flavours, see
the diff). This pattern came sometimes with a comment explaining what it
does (create an empty file), which let me think that it's not easy to
understand what it is supposed to do (if you don't have the comment).

My initial need was to make quiet a warning (of my patched Python, see
#12451) if a file is opened in text mode without an explicit encoding.

> I find it quite explicit and obvious what the following does:
> 
>     with open("somefile", "wb"):
>         pass

For "wb", the only gain is to avoid the creation of temporary FileIO and
BufferedWriter objects, a micro optimisation. Most of the time, "w" mode
was used, so another temporary TextIOWrapper object was also created. I
also saw "w+" mode (use BufferedRandom+TextIOWrapper objects).

Victor

_______________________________________________
Python-Dev mailing list
Python-Dev <at> python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org
Tim Lesher | 1 Jul 14:17 2011
Picon

Re: time.sleep(-1) behaviour

On Thu, Jun 30, 2011 at 15:13, Ulrich Eckhardt
<ulrich.eckhardt <at> dominolaser.com> wrote:
> Hi!
>
> This is a request for clarification for the thread "how to call a function for
> evry 10 seconds" from the user mailinglist/newsgroup.
>
>
> The gist is this:
> 1. On Linux/Python 2.6, time.sleep(-1.0) raises an IOError.
> 2. On MS Windows/Python 2.5 or 2.7 this sleeps forever. It seems that
> converting this to a 32-bit integer for Sleep() causes an underflow.

> 3. Is the behaviour under MS Windows acceptable or a bug?

On the Windows side, Sleep(-1) as "infinite" is correct and documented:

http://msdn.microsoft.com/en-us/library/ms686298(v=vs.85).aspx

--

-- 
Tim Lesher <tlesher <at> gmail.com>
Nick Coghlan | 1 Jul 14:39 2011
Picon

Re: [Python-checkins] cpython (3.2): test_os: add TemporaryFileTests to the testcase list

On Fri, Jul 1, 2011 at 7:18 PM, Victor Stinner
<victor.stinner <at> haypocalc.com> wrote:
> I tried to find which commit removes TemporaryFileTests from the
> testcase list (to see if there is a good reason to do that, or if it's
> just a mistake): it's somewhere between Python 2.x and Python 3.0, but I
> didn't find the commit.
>
> Is there a tool to detect that a testcase is never executed to ensure
> that there is no other forgiven testcase?

Coverage data for the test suite itself.

Cheers,
Nick.

--

-- 
Nick Coghlan   |   ncoghlan <at> gmail.com   |   Brisbane, Australia

Gmane