Re: [Python-Dev] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3
On 03/18/2012 12:15 AM, Éric Araujo wrote: > Hi, > > Le 17/03/2012 19:03, Georg Brandl a écrit : >> On 03/17/2012 11:43 PM, Barry Warsaw wrote: >> I'm afraid it's the latter: tags are entries in .hgtags. So when you >> completely >> null-merge your 2.6 changes into 2.7, you are basically removing the tag from >> the 2.7 branch. And since to find tags, Mercurial looks in the .hgtags files >> of all active branch heads, you are basically hiding the tag when you merge >> 2.6 into 2.7, at which point it becomes an inactive branch head. > > The plus side to this concept of tags as entries in a file is that it’s > trivial to add the missing 2.6 tags in the 2.7 branch. > > Note that duplicate entries in .hgtags (when a tag was redone) should > not be “cleaned up”: the presence of the old changeset hash greatly > helps conflict resolution. (If someone pulled the repo with the old tag > and later pulls and updates, then they don’t have to find out which hash > is the right tag, they just accept all changes from the updated file > into their local file.) I don't understand that argument: especially when there is no change in the tree between the two tags. Georg ___ 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] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3
On Mar 17, 2012, at 07:15 PM, Éric Araujo wrote: >Note that duplicate entries in .hgtags (when a tag was redone) should >not be “cleaned up”: the presence of the old changeset hash greatly >helps conflict resolution. (If someone pulled the repo with the old tag >and later pulls and updates, then they don’t have to find out which hash >is the right tag, they just accept all changes from the updated file >into their local file.) But if someone wants to grab the 2.6.8rc2 tag, which changeset do they get? I guess the last one... maybe? >This problem in the future can be avoided by merging all changesets from >X.Y to X.Y+1, not null-merging, unless I misunderstand something. Except in this case, there's probably not much useful in the 2.6.8 changes that are appropriate for 2.7. -Barry ___ 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] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3
On Mar 18, 2012, at 12:03 AM, Georg Brandl wrote: >I'm afraid it's the latter: tags are entries in .hgtags. So when you >completely null-merge your 2.6 changes into 2.7, you are basically removing >the tag from the 2.7 branch. And since to find tags, Mercurial looks in the >.hgtags files of all active branch heads, you are basically hiding the tag >when you merge 2.6 into 2.7, at which point it becomes an inactive branch >head. D'oh. Okay, so leave the .hgtags file alone when null merging 2.6->2.7. Actually, that probably applies to all forward merges, so I think this would be useful information for either the devguide or PEP 101, or both. I updated the latter right at the --tag step. Thanks, -Barry ___ 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] cpython (2.6): Added tag v2.6.8rc2 for changeset bd9e1a02e3e3
On Mar 17, 2012, at 11:34 PM, barry.warsaw wrote: >http://hg.python.org/cpython/rev/6144a0748a95 >changeset: 75809:6144a0748a95 >branch: 2.6 >parent: 75806:bd9e1a02e3e3 >user:Barry Warsaw >date:Sat Mar 17 18:34:05 2012 -0400 >summary: > Added tag v2.6.8rc2 for changeset bd9e1a02e3e3 > >files: > .hgtags | 1 + > 1 files changed, 1 insertions(+), 0 deletions(-) > > >diff --git a/.hgtags b/.hgtags >--- a/.hgtags >+++ b/.hgtags >@@ -140,3 +140,4 @@ > caab08cd2b3eb5a6f78479b2513b65d36c754f41 v2.6.8rc1 > 5356b6c7fd4679f9bd71f7cd085239934e43 v2.6.8rc1 > 1d1b7b9fad48bd0dc60dc8a06cca4459ef273127 v2.6.8rc2 >+bd9e1a02e3e329fa7b6da06113090a401909c4ea v2.6.8rc2 I don't know why Mercurial does this. Here's what *I* did: * After I committed the last of my PEP 101 changes to the 2.6 branch, I did release.py --tag 2.6.8rc2. It sure looks like that added the tag. * Then I switched to the 2.7 branch, pulled and merged the changes from 2.6, `hg revert -ar .` then marked all conflicts as resolved `hg resolve -am`. AFAICT, that's the way to null merge 2.6 to 2.7. * Then I pushed my changes. * Switching back to my 2.6 branch, I then tried to `release -export 2.6.8rc2` and got an error that v2.6.8rc2 tag wasn't found. At this point I *retagged* for 2.6.8rc2, switch to default and pushed. This makes me a little wary about what's actually in the 2.6.8rc2 tarball, but I'm building and testing it now, and from visual inspection it *looks* okay, so I'm inclined to chalk this up to either a Mercurial wart, or my boneheaded use of it. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
On 17 Mar 2012, at 15:04, Georg Brandl wrote: > On 03/17/2012 09:47 PM, Michael Foord wrote: >> >> On 17 Mar 2012, at 08:49, Georg Brandl wrote: >> >>> On 03/15/2012 01:17 AM, victor.stinner wrote: http://hg.python.org/cpython/rev/27441e0d6a75 changeset: 75672:27441e0d6a75 user:Victor Stinner date:Thu Mar 15 01:17:09 2012 +0100 summary: Issue #10278: Add an optional strict argument to time.steady(), False by default files: Doc/library/time.rst | 7 +++- Lib/test/test_time.py | 10 + Modules/timemodule.c | 58 +- 3 files changed, 57 insertions(+), 18 deletions(-) diff --git a/Doc/library/time.rst b/Doc/library/time.rst --- a/Doc/library/time.rst +++ b/Doc/library/time.rst @@ -226,7 +226,7 @@ The earliest date for which it can generate a time is platform-dependent. -.. function:: steady() +.. function:: steady(strict=False) .. index:: single: benchmarking @@ -236,6 +236,11 @@ adjusted. The reference point of the returned value is undefined so only the difference of consecutive calls is valid. + If available, a monotonic clock is used. By default, if *strict* is False, + the function falls back to another clock if the monotonic clock failed or is + not available. If *strict* is True, raise an :exc:`OSError` on error or + :exc:`NotImplementedError` if no monotonic clock is available. >>> >>> This is not clear to me. Why wouldn't it raise OSError on error even with >>> strict=False? Please clarify which exception is raised in which case. >> >> It seems clear to me. It doesn't raise exceptions when strict=False because >> it falls back to a non-monotonic clock. If strict is True and a non-monotonic >> clock is not available it raises OSError or NotImplementedError. > > So errors are ignored when strict is false? Well, as described in the documentation an error in finding a monotonic clock causes the function to fallback to a different clock. So you could interpret that as either errors are ignored, or it isn't an error in the first place. I don't see how the following is ambiguous, but you're obviously having difficulty with it. Perhaps you can suggest another wording. if *strict* is False, the function falls back to another clock if the monotonic clock failed or is not available. The note from Eric notwithstanding though. Michael > > Georg > > ___ > 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/fuzzyman%40voidspace.org.uk > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
On 3/17/2012 4:47 PM, Michael Foord wrote: > > On 17 Mar 2012, at 08:49, Georg Brandl wrote: > >> On 03/15/2012 01:17 AM, victor.stinner wrote: >>> + If available, a monotonic clock is used. By default, if *strict* is >>> False, >>> + the function falls back to another clock if the monotonic clock failed >>> or is >>> + not available. If *strict* is True, raise an :exc:`OSError` on error or >>> + :exc:`NotImplementedError` if no monotonic clock is available. >> >> This is not clear to me. Why wouldn't it raise OSError on error even with >> strict=False? Please clarify which exception is raised in which case. > > It seems clear to me. It doesn't raise exceptions when strict=False because > it falls back to a non-monotonic clock. If strict is True and a non- > monotonic clock is not available it raises OSError or NotImplementedError. I have to agree with Georg. Looking at the code, it appears OSError can be raised with both strict=True and strict=False (since floattime() can raise OSError). The text needs to make it clear OSError can always be raised. I also think "By default, if strict is False" confuses things. If there's a default behavior with strict=False, what's the non-default behavior? I suggest dropping "By default". Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
On 03/17/2012 09:47 PM, Michael Foord wrote: > > On 17 Mar 2012, at 08:49, Georg Brandl wrote: > >> On 03/15/2012 01:17 AM, victor.stinner wrote: >>> http://hg.python.org/cpython/rev/27441e0d6a75 changeset: >>> 75672:27441e0d6a75 user:Victor Stinner >>> date:Thu Mar 15 01:17:09 2012 +0100 >>> summary: Issue #10278: Add an optional strict argument to time.steady(), >>> False by default >>> >>> files: Doc/library/time.rst | 7 +++- Lib/test/test_time.py | 10 >>> + Modules/timemodule.c | 58 +- 3 files >>> changed, 57 insertions(+), 18 deletions(-) >>> >>> >>> diff --git a/Doc/library/time.rst b/Doc/library/time.rst --- >>> a/Doc/library/time.rst +++ b/Doc/library/time.rst @@ -226,7 +226,7 @@ The >>> earliest date for which it can generate a time is platform-dependent. >>> >>> >>> -.. function:: steady() +.. function:: steady(strict=False) >>> >>> .. index:: single: benchmarking @@ -236,6 +236,11 @@ adjusted. The >>> reference point of the returned value is undefined so only the difference >>> of consecutive calls is valid. >>> >>> + If available, a monotonic clock is used. By default, if *strict* is >>> False, + the function falls back to another clock if the monotonic >>> clock failed or is + not available. If *strict* is True, raise an >>> :exc:`OSError` on error or + :exc:`NotImplementedError` if no monotonic >>> clock is available. >> >> This is not clear to me. Why wouldn't it raise OSError on error even with >> strict=False? Please clarify which exception is raised in which case. > > It seems clear to me. It doesn't raise exceptions when strict=False because > it falls back to a non-monotonic clock. If strict is True and a non-monotonic > clock is not available it raises OSError or NotImplementedError. So errors are ignored when strict is false? Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
On 17 Mar 2012, at 08:49, Georg Brandl wrote: > On 03/15/2012 01:17 AM, victor.stinner wrote: >> http://hg.python.org/cpython/rev/27441e0d6a75 >> changeset: 75672:27441e0d6a75 >> user:Victor Stinner >> date:Thu Mar 15 01:17:09 2012 +0100 >> summary: >> Issue #10278: Add an optional strict argument to time.steady(), False by >> default >> >> files: >> Doc/library/time.rst | 7 +++- >> Lib/test/test_time.py | 10 + >> Modules/timemodule.c | 58 +- >> 3 files changed, 57 insertions(+), 18 deletions(-) >> >> >> diff --git a/Doc/library/time.rst b/Doc/library/time.rst >> --- a/Doc/library/time.rst >> +++ b/Doc/library/time.rst >> @@ -226,7 +226,7 @@ >>The earliest date for which it can generate a time is platform-dependent. >> >> >> -.. function:: steady() >> +.. function:: steady(strict=False) >> >>.. index:: >> single: benchmarking >> @@ -236,6 +236,11 @@ >>adjusted. The reference point of the returned value is undefined so only >> the >>difference of consecutive calls is valid. >> >> + If available, a monotonic clock is used. By default, if *strict* is >> False, >> + the function falls back to another clock if the monotonic clock failed >> or is >> + not available. If *strict* is True, raise an :exc:`OSError` on error or >> + :exc:`NotImplementedError` if no monotonic clock is available. > > This is not clear to me. Why wouldn't it raise OSError on error even with > strict=False? Please clarify which exception is raised in which case. It seems clear to me. It doesn't raise exceptions when strict=False because it falls back to a non-monotonic clock. If strict is True and a non-monotonic clock is not available it raises OSError or NotImplementedError. Michael > > Georg > > ___ > 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/fuzzyman%40voidspace.org.uk > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
On 3/17/2012 10:50 AM, Paul Moore wrote: Meh. None of this is a real issue. It's just some extra messy coding. But Van's point is that this proposal gives him less hard coding. Beyond pointing out that it gives me more, I don't have much to add. I suspect a case could be made that harmonization now will benefit multiple people in, say, 5 years, especially if by then one only supported 3.3+ while supporting multiple platforms. It would be the same rationale as that for 3.0, and especially the bytes to unicode change for text. (As I remember, we are only 3 years in on that one ;-). I leave it to Van to actually explain and make the argument. -- Terry Jan Reedy ___ 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] cpython (3.2): this stuff will actually be new in 3.2.4
On 03/17/2012 06:20 PM, Éric Araujo wrote: > Hi, > >> changeset: 509b222679e8 >> branch: 3.2 >> user:Benjamin Peterson >> date:Wed Mar 07 18:49:43 2012 -0600 >> summary: >> this stuff will actually be new in 3.2.4 > >> diff --git a/Misc/NEWS b/Misc/NEWS >> --- a/Misc/NEWS >> +++ b/Misc/NEWS >> @@ -2,6 +2,57 @@ >> Python News >> +++ >> >> +What's New in Python 3.2.4 >> +== >> + >> +*Release date: XX-XX-* > > Thanks for sorting this out. There is however at least one mistake: > >> +- Issue #6884: Fix long-standing bugs with MANIFEST.in parsing in distutils >> + on Windows. > > I’m quite sure Georg transplanted that commit to the 3.2.3 release > clone, and hope you did likewise for 2.7.3. Fixed, thanks. Georg ___ 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] cpython (3.2): this stuff will actually be new in 3.2.4
Hi, > changeset: 509b222679e8 > branch: 3.2 > user:Benjamin Peterson > date:Wed Mar 07 18:49:43 2012 -0600 > summary: > this stuff will actually be new in 3.2.4 > diff --git a/Misc/NEWS b/Misc/NEWS > --- a/Misc/NEWS > +++ b/Misc/NEWS > @@ -2,6 +2,57 @@ > Python News > +++ > > +What's New in Python 3.2.4 > +== > + > +*Release date: XX-XX-* Thanks for sorting this out. There is however at least one mistake: > +- Issue #6884: Fix long-standing bugs with MANIFEST.in parsing in distutils > + on Windows. I’m quite sure Georg transplanted that commit to the 3.2.3 release clone, and hope you did likewise for 2.7.3. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): 3.2 explain json.dumps for non-string keys in dicts. closes issue6566. Patch
On 03/17/2012 08:41 AM, senthil.kumaran wrote: > http://hg.python.org/cpython/rev/613919591a05 > changeset: 75778:613919591a05 > branch: 3.2 > parent: 75771:32d3ecacdabf > user:Senthil Kumaran > date:Sat Mar 17 00:40:34 2012 -0700 > summary: > 3.2 explain json.dumps for non-string keys in dicts. closes issue6566. > Patch contributed Kirubakaran Athmanathan > > files: > Doc/library/json.rst | 8 > 1 files changed, 8 insertions(+), 0 deletions(-) > > > diff --git a/Doc/library/json.rst b/Doc/library/json.rst > --- a/Doc/library/json.rst > +++ b/Doc/library/json.rst > @@ -168,6 +168,14 @@ >so trying to serialize multiple objects with repeated calls to >:func:`dump` using the same *fp* will result in an invalid JSON file. > > + .. note:: > + > + Keys in key/value pairs of JSON are always of the type :class:`str`. > When > + a dictionary is converted into JSON, all the keys of the dictionary are > + coerced to strings. As a result of this, if a dictionary is convered > + into JSON and then back into a dictionary, the dictionary may not equal > + the original one. That is, ``loads(dumps(x)) != x`` if x has non-string > + keys. > > .. function:: load(fp, cls=None, object_hook=None, parse_float=None, > parse_int=None, parse_constant=None, object_pairs_hook=None, **kw) This is just a minor nitpick, and it absolutely is not specific to you, Senthil: please try to keep the rst file structuring with newlines intact. In particular, I place two blank lines between top-level function/class descriptions because single blank lines already occur so often in rst markup. When you add paragraphs, please try to keep the blank lines. Georg ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On 17 March 2012 16:28, Serhiy Storchaka wrote: > Thus, there are no reasons to use bytes instead of 'bytes'. Aesthetics ;-) I've implemented the encoding="bytes" version [1]. Thank you all for your input! Merlijn [1] http://bugs.python.org/issue6784#msg156166 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default
On 03/15/2012 01:17 AM, victor.stinner wrote: > http://hg.python.org/cpython/rev/27441e0d6a75 > changeset: 75672:27441e0d6a75 > user:Victor Stinner > date:Thu Mar 15 01:17:09 2012 +0100 > summary: > Issue #10278: Add an optional strict argument to time.steady(), False by > default > > files: > Doc/library/time.rst | 7 +++- > Lib/test/test_time.py | 10 + > Modules/timemodule.c | 58 +- > 3 files changed, 57 insertions(+), 18 deletions(-) > > > diff --git a/Doc/library/time.rst b/Doc/library/time.rst > --- a/Doc/library/time.rst > +++ b/Doc/library/time.rst > @@ -226,7 +226,7 @@ > The earliest date for which it can generate a time is platform-dependent. > > > -.. function:: steady() > +.. function:: steady(strict=False) > > .. index:: >single: benchmarking > @@ -236,6 +236,11 @@ > adjusted. The reference point of the returned value is undefined so only > the > difference of consecutive calls is valid. > > + If available, a monotonic clock is used. By default, if *strict* is False, > + the function falls back to another clock if the monotonic clock failed or > is > + not available. If *strict* is True, raise an :exc:`OSError` on error or > + :exc:`NotImplementedError` if no monotonic clock is available. This is not clear to me. Why wouldn't it raise OSError on error even with strict=False? Please clarify which exception is raised in which case. Georg ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
17.03.12 17:00, Guido van Rossum написав(ла): One reason to use 'bytes' instead of bytes is that it is a string that can be specified e.g. in a config file. Thus, there are no reasons to use bytes instead of 'bytes'. ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
One reason to use 'bytes' instead of bytes is that it is a string that can be specified e.g. in a config file. On Sat, Mar 17, 2012 at 7:28 AM, Stefan Behnel wrote: > Merlijn van Deen, 17.03.2012 15:20: >> On 17 March 2012 10:43, Stefan Behnel wrote: >>> In lxml, there was an "encoding=unicode" option that would let the >>> XML/HTML/text serialisation function return a Unicode string. This was >>> eventually deprecated in favour of "encoding='unicode'" when ElementTree >>> gained this feature as well some years later. >> >> That's this issue: http://bugs.python.org/issue8047 >> >> The thread also suggests the options >> encoding=False >> and >> encoding=None >> >> Considering ET uses encoding="unicode" to signal 'don't encode', I >> agree with you that using encoding="bytes" to signal 'don't encode' >> would be sensible. However, ET /also/ allows encoding=str.What about >> allowing both encoding="bytes" /and/ encoding=bytes? > > It doesn't read well for the unicode type any more because it's gone in Py3 > (and "encoding=str" just looks weird). It's less awkward for the bytes type. > > However, why should there be two ways to do it? > > Stefan > > ___ > 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/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
On 17 March 2012 14:07, Serhiy Storchaka wrote:
> 17.03.12 13:57, Paul Moore написав(ла):
>
>> As there is no
>> way of knowing the Python version without running Python, this is too
>> slow to be practical.
>
>
> Cold start:
> $ time python3 --version
> Python 3.1.2
>
> real 0m0.073s
> user 0m0.004s
> sys 0m0.004s
>
> Hot start:
> $ time python3 --version
> Python 3.1.2
>
> real 0m0.007s
> user 0m0.004s
> sys 0m0.004s
Blame it on Windows or my overloaded PC if you must :-) but I get
perceptible delays on a cold start at times. Plus, I'd probably need
to do this in code that enumerates all installed Pythons and
virtualenvs - that could be 10 installations. I've never tried it in
anger, so I could be worrying over nothing, but to an extent that's my
point - I don't *need* to know the version unless I have to have
version-specific code to define the layout.
And if I were starting Python up, I'd probably be better just
importing sys and sysconfig, and using sys.executable and
sysconfig.get_path('scripts'). And there's the chicken-and-egg problem
- if I don't know the version, I don't know where python.exe is, so
how can I run it to find the version?
Meh. None of this is a real issue. It's just some extra messy coding.
But Van's point is that this proposal gives him less hard coding.
Beyond pointing out that it gives me more, I don't have much to add.
Paul.
___
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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
Merlijn van Deen, 17.03.2012 15:20: > On 17 March 2012 10:43, Stefan Behnel wrote: >> In lxml, there was an "encoding=unicode" option that would let the >> XML/HTML/text serialisation function return a Unicode string. This was >> eventually deprecated in favour of "encoding='unicode'" when ElementTree >> gained this feature as well some years later. > > That's this issue: http://bugs.python.org/issue8047 > > The thread also suggests the options > encoding=False > and > encoding=None > > Considering ET uses encoding="unicode" to signal 'don't encode', I > agree with you that using encoding="bytes" to signal 'don't encode' > would be sensible. However, ET /also/ allows encoding=str.What about > allowing both encoding="bytes" /and/ encoding=bytes? It doesn't read well for the unicode type any more because it's gone in Py3 (and "encoding=str" just looks weird). It's less awkward for the bytes type. However, why should there be two ways to do it? Stefan ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On 17 March 2012 10:43, Stefan Behnel wrote: > In lxml, there was an "encoding=unicode" option that would let the > XML/HTML/text serialisation function return a Unicode string. This was > eventually deprecated in favour of "encoding='unicode'" when ElementTree > gained this feature as well some years later. That's this issue: http://bugs.python.org/issue8047 The thread also suggests the options encoding=False and encoding=None Considering ET uses encoding="unicode" to signal 'don't encode', I agree with you that using encoding="bytes" to signal 'don't encode' would be sensible. However, ET /also/ allows encoding=str.What about allowing both encoding="bytes" /and/ encoding=bytes? Best, Merlijn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
17.03.12 13:57, Paul Moore написав(ла): As there is no way of knowing the Python version without running Python, this is too slow to be practical. Cold start: $ time python3 --version Python 3.1.2 real0m0.073s user0m0.004s sys 0m0.004s Hot start: $ time python3 --version Python 3.1.2 real0m0.007s user0m0.004s sys 0m0.004s ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32
On 17 March 2012 05:28, Mark Hammond wrote: >> I hate to seem like I'm piling on now after panning your last brainstorm >> :-), but... this would be quite problematic for virtualenv users, many >> of whom do rely on the fact that the virtualenv "stuff" is confined to >> within a limited set of known subdirectories, and they can overlay a >> virtualenv and their own project code with just a few virtualenv >> directories vcs-ignored. >> >> I would prefer either the status quo or the proposed cross-platform >> harmonization. I work purely Windows-only, and I have a few scripts that manage virtualenvs for myself (for example, sort of a personal virtalenv-wrapper for Powershell - see https://bitbucket.org/pmoore/poshpy for a work-in-progress version). They have special casing for the differences in layout between standard installs, build directories, and virtualenvs. Changing the layout would cause these tools to need to change. In theory, putting python.exe/pythonw.exe into "Scripts" would simplify them (no need to cater for the cases where I need to put 2 directories on PATH), and changing Scripts -> bin would be trivial. But in practice, it would mean that I need to check (somehow) the Python version and adjust the layout used accordingly. As there is no way of knowing the Python version without running Python, this is too slow to be practical. So while the changes are in theory harmless in isolation (except the library locations - changing those *would* cause pain) the need to support multiple versions would make this a major issue for me. So, I prefer the status quo. If necessary, I can live with the change to rename scripts as bin and put the Python executables in there (some cost, but some small benefit as well) but I oppose changing the library locations (all cost, no gain for me). All of this presupposes that both the standard installer *and* virtualenv change. I suspect that having virtualenv respect the old layout for 3.2 and earlier, and the new one for 3.3+, could be messy, though, so that's not guaranteed, I guess... > Breaking the few tools I'm concerned about vs asking Van etc to continue > taking the pain he feels isn't going to mean the end of the world for any of > us. Agreed. I can't say my pain is any more important than Van's, but the same applies the other way round :-) > So given the stakes in this particular discussion aren't that high, > I'll try and summarize the thread over the next few days (or someone can > beat me to it if they prefer) and we can ask someone semi-impartial to make > a decision. I'd be happy to nominate MvL if he feels so inclined (even > though I haven't asked him). Sounds reasonable. I'd suggest that Van should probably report any other examples where someone would benefit from this change - at the moment unless I've misread the thread, it seems like he's the only example of someone who would gain. Paul. ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
Guido van Rossum, 17.03.2012 00:57: > OK, how about using encoding=bytes (yes, the type object!)? Or 'bytes' ? In lxml, there was an "encoding=unicode" option that would let the XML/HTML/text serialisation function return a Unicode string. This was eventually deprecated in favour of "encoding='unicode'" when ElementTree gained this feature as well some years later. Arguably, this was because there no longer was a unicode type in the then existing Py3, but ... Anyway, given that there is at least some precedence, I'd prefer the name "bytes" over the bare bytes type. Regarding possible naming conflicts, I don't see any sense in calling an actual encoding "bytes" that does anything but returning bare bytes in a bytes object, as is the case here. Stefan ___ 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] Unpickling py2 str as py3 bytes (and vice versa) - implementation (issue #6784)
On 17 March 2012 00:57, Guido van Rossum wrote:
> OK, how about using encoding=bytes (yes, the type object!)? Or 'bytes' ?
encoding=bytes makes (at least intuitive) sense to me;
encoding='bytes' would imply there is an encoding with name 'bytes'
that somehow does b''.decode('bytes')=b'', and would disallow anyone
to create a new encoding with the name 'bytes'.
I'll take a look at rewriting my patch later this weekend, and I'll
also give the documentation (both the 'consider not using pickle for
long time storage' and the docs for this setting) some thought.
Best,
Merlijn
___
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
