gmane.comp.python.devel

Re: PEP 420 - dynamic path computation is missingrationale

Eric V. Smith — 2012-05-22T14:51:22

That seems like a pretty convincing example to me.

Personally I'm +1 on putting dynamic computation into the PEP, at least
for top-level namespace packages, and probably for all namespace packages.

The code is not very large or complicated, and with the proposed removal
of the restriction that sys.path cannot be replaced, I think it behaves
well.

But Guido can decide against it without hurting my feelings.

Eric.

P.S.: Here's the current code in the pep-420 branch. This code still has
the restriction that sys.path (or parent_path in general) can't be
replaced. I'll fix that if we decide to keep the feature.

class _NamespacePath:
    def __init__(self, name, path, parent_path, path_finder):
        self._name = name
        self._path = path
        self._parent_path = parent_path
        self._last_parent_path = tuple(parent_path)
        self._path_finder = path_finder

    def _recalculate(self):
        # If _parent_path has changed, recalculate _path
        parent_path = tuple(self._parent_path)

Re: [Python-checkins] cpython (2.7): #14804: Remove [] around optional arguments with default values

Hynek Schlawack — 2012-05-22T12:38:01

Hi Nick,


Ah dang, thanks for pointing this out! I went at least five times
through all changes but there had to be one thing I missed. :(

Same in dl.open() & ossaudiodev.oss_audio_device.setparameters(). I will
go through them all once more and fix it at the latest tomorrow.

Regards,
Hynek

Re: docs.python.org pointing to Python 3 by default?

Stefan Scherfke — 2012-05-22T07:08:25

Am 2012-05-21 um 19:58 schrieb Éric Araujo:


I think this URL scheme looks most clean:

docs.python.org/   --> Points to recommended version(2 for now, 3 later)
docs.python.org/2/  --> Points to latest stable 2.x
docs.python.org/2.7/ 
docs.python.org/2.6/
...
docs.python.org/3/  --> Points to latest stable 3.x
docs.python.org/3.2/
...
docs.python.org/dev/  --> Points to dev version (e.g., 3.3)

Using something like docs.python.org/stable/ in books might not make sense if the book is about Python 3 and /stable/ points to Python 4 a few years later.

Imho, adding additional sub-domains also wouldn’t improve anything, but would add more clutter and confusion (what if somebody types "docs3.python.org/2/ ?)

A prominent CCS-box showing the current version and offering Links to other main versions would make it perfect (e.g. 2, 3 and dev for all versions, 3.x sub-releases only, if you are under docs.python.org/3/... and for 2.x accordingly).

Cheers,
Stefan

Re: PEP 420 - dynamic path computation is missingrationale

Eric V. Smith — 2012-05-22T00:32:10

Any reason to make this the string "sys" or "foo", and not the module
itself? Can the module be replaced in sys.modules? Mostly I'm just curious.

But regardless, I'm okay with keeping these both as strings and looking
it up in sys.modules and then by attribute.

Eric.

Re: PEP 420 - dynamic path computation is missingrationale

Nick Coghlan — 2012-05-21T23:32:55

I agree the parent path should be retrieved by name rather than a direct
reference when checking the cache validity, though.

--
Sent from my phone, thus the relative brevity :)

Re: PEP 420 - dynamic path computation is missingrationale

Nick Coghlan — 2012-05-21T23:25:52

As a simple example to back up PJE's explanation, consider:
1.  encodings becomes a namespace package
2. It sometimes gets imported during interpreter startup to initialise the
standard io streams
3. An application modifies sys.path after startup and wants to contribute
additional encodings

Searching the entire parent path for new portions on every import would be
needlessly slow.

Not recognising new portions would be needlessly confusing for users. In
our simple case above, the application would fail if the io initialisation
accessed the encodings package, but work if it did not (e.g. when all
streams are utf-8).

PEP 420 splits the difference via an automatically invalidated cache: when
you iterate over a namespace package __path__ object, it rescans the parent
path for new portions *if and only if* the contents of the parent path have
changed since the previous scan.

Cheers,
Nick.

--
Sent from my phone, thus the relative brevity :)
On May 22, 2012 4:10 AM, "PJ Eby" <pje< at >telecommunity.com> wrote:

Volunteering to be PEP czar for PEP 421,sys.implementation

Barry Warsaw — 2012-05-21T21:24:09

I've mentioned this in private to a few folks, with generally positive
feedback.

I am formally volunteering to be PEP czar for PEP 421, sys.implementation.  If
there are no objections in the next few days, I'll make it official.

Cheers,
-Barry

Re: cpython (3.2): Issue12541 - Add UserWarning forunquoted realms

Georg Brandl — 2012-05-21T18:26:24

Am 15.05.2012 18:08, schrieb senthil.kumaran:



This looks suspect.  Do we issue UserWarnings/any warnings anywhere else in the
network-related libs when servers don't implement protocols correctly?
I'm afraid of spurious warnings generated that will bug users unnecessarily.

If the warning is left in, the message should probably include the offending
realm string.

Georg

Re: cpython: Close #14588: added a PEP 3115 compliant dynamic type creation mechanism

Georg Brandl — 2012-05-21T18:14:36

Am 19.05.2012 18:34, schrieb nick.coghlan:


Should have versionadded.

Georg

Re: PEP 420 - dynamic path computation is missingrationale

PJ Eby — 2012-05-21T18:08:16


That's fine by me - the class could actually be defined to take a module
name and attribute (e.g. 'sys', 'path' or 'foo', '__path__'), and then
there'd be no need to special case anything: it would behave exactly the
same way for subpackages and top-level packages.



To do that, you just assign to __path__, the same as now, ala __path__ =
pkgutil.extend_path().  The auto-updating is in the initially-assigned
__path__ object, not the module object or some sort of generalized magic.


 I'd like to hear more about this from Philip -- is that feature


Well, it's built into setuptools, so yes.  ;-)  It gets used any time a
dynamically specified dependency is used that might contain a namespace
package.  This means, for example, that every setup script out there using
"setup.py test", every project using certain paste.deploy features...  it's
really difficult to spell out the scope of things that are using this, in
the context of setuptools and distribute, because there are an immense
number of ways to indirec

Re: docs.python.org pointing to Python 3 by default?

Terry Reedy — 2012-05-21T18:04:26


Since there is no link to it from docs.python.org, of course it it 
difficult to find 8-). Such a link is part of the otherwise redundant 
proposal.

Re: docs.python.org pointing to Python 3 by default?

Éric Araujo — 2012-05-21T17:58:44

Le 21/05/2012 07:42, Georg Brandl a écrit :
+1.

I’d be +1 to adding /stable but both 2.7 and 3.2 are stable at this time.

Either sounds good, I’m in favor of redirecting to /2 for a few years
still to preserve existing links and avoid the need to click on each page.

+1, the py3k name is not obvious for everyone.

The URIs should not change, but it seems a bit bad to me that for
example the 2.7.1 docs don’t link to the latest 2.7 page and mention 2.6
as stable version

+1

On a related note, we may want to find a way to make the version more
prominent in the pages; I’ve seen beginners install Python 3 and use the
Python 2 docs and fail at the first print 'Hello, world!' example.
That’s why I support always having the version numbers in the URIs.

Cheers
_______________________________________________
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

Re: cpython (3.2): #14766: Add correct algorithm for when a 'time' object is naive.

Georg Brandl — 2012-05-21T17:46:59

Am 15.05.2012 04:33, schrieb r.david.murray:



I like that :)

Georg

Re: cpython: Close #13585: add contextlib.ExitStack to replace the ill-fated

Georg Brandl — 2012-05-21T17:45:14

Am 21.05.2012 14:54, schrieb nick.coghlan:

I'd prefer this versionadded a little more towards the top of the class
documentation, e.g. before the first method.  Otherwise it might get overlooked,
or taken as belonging to the close() method (the indentation suggests otherwise,
but that might not be enough cue for a quick read).

Georg

Re: docs.python.org pointing to Python 3 by default?

Hynek Schlawack — 2012-05-21T16:25:06

I find docs2/3 ugly as it reminds me of load balancing (like
www1.python.org) and it also doesn’t really make sense to me. I have no
problem to have these DNS records and redirect them to docs.python.org/2
or /3 but I wouldn’t like them to be the canonical URIs.
_______________________________________________
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

Re: docs.python.org pointing to Python 3 by default?

R. David Murray — 2012-05-21T16:15:38

Note that I did apply the fix for 14434 to 2.7.  So yes, I think 10446
should be applied to 2.7 as well.

--David

Re: docs.python.org pointing to Python 3 by default?

Terry Reedy — 2012-05-21T16:18:16

If you prefer these to docs2, docs3, OK with me.
Whatever we do, we should encourage book/blog writers to use the 
canonical 'latest' links that will not go out of date. So there should 
definitely be one for each, with the same format. The exact format is 
less important.


While I am a strong partisan of Py 3, I do not want Py 2 users to feel 
'pushed', so I vote for a neutral index or 'disambiguation' page.

What I would do is set up the canonical pages now. Next, add a notice to 
the top of docs.python.org that it will become a neutral index page with 
the release of 3.3, so 'please change bookmarks to the new, permanent 
page for Py 2', whatever it is.



I would leave those alone too.

Re: docs.python.org pointing to Python 3 by default?

Barry Warsaw — 2012-05-21T16:14:54


I'd be all for this, as long as I can still write
chrome/firefox/genericbrowser shortcuts to give me the latest Python 2 or
Python 3 library page.


Right.  I'm just keen on continuing to make progress.  I really do think we're
not far from a tipping point on Python 3, and I want to keep nudging us over
the edge.  Roller coasters are scary *and* fun. :)


If history is repeated, my guess is that will put us a few months into Python
3.5 development.  I think Python 3.3 is shaping up to be a fantastic release,
and once it's out we should start thinking about what we want to accomplish in
Python 3.4 to achieve the goal of Python 3 dominance.


There's already great ongoing work on this.  It could use more help of course.
I've mentioned Ubuntu's efforts here before, but this is really more about the
greater Python universe, and getting Python 3 on the radar of more and more
projects.


When I talk to folks starting new Python projects, I always push for it to
begin in Python 3.  Of course, the state of their d

Re: docs.python.org pointing to Python 3 by default?

Antoine Pitrou — 2012-05-21T16:07:36

On Mon, 21 May 2012 12:03:31 -0400
Terry Reedy <tjreedy< at >udel.edu> wrote:

I don't like docs2/docs3. First, they are clumsy to type and look
awkward. Second, it's not the right level of segregation; if you wanted
separate domains you'd really want docs.python2.org and
docs.python3.org.

So, in the end, I think the current scheme is ok and we only need to
add a "/stable" pointing to latest 3.x.

Regards

Antoine.

Re: docs.python.org pointing to Python 3 by default?

Terry Reedy — 2012-05-21T16:03:31


This looks great except for 'latest', which is ambiguous and awkward.

Like Guido, I would have docs2 and docs3 link to the latest of each 
series. This gives both series equal billing. docs itself could then 
become a *neutral* index page. In retrospect, I wish we had done this a 
year ago.

This design would continue to work if and when we need docs4.python.org.

Re: docs.python.org pointing to Python 3 by default?

Terry Reedy — 2012-05-21T15:56:02


Guido and I are proposing docs2 and docs3 each pointing to the latest 
docs for each series. That puts them on equal status.
docs.python.org, besides being a namespace for specific version docs
(/x.y, minus Nick's /latest) would be transitioned away from being a 
synonym for docs2. It could become a *neutral* index page listing docs2 
and docs3 for the 'latest' production version of each series and then 
each subdirectory.