Re: [Python-Dev] os.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories
On Wed, Jun 27, 2012 at 01:49:34AM +0200, Giampaolo Rodol?
wrote:
> I've just noticed a strange behavior when dealing with gvfs filesystems:
>
> giampaolo@ubuntu:~$ python -c "import os;
> print(os.path.exists('/home/giampaolo/.gvfs'))"
> True
> giampaolo@ubuntu:~$ sudo su
> root@ubuntu:~# python -c "import os;
> print(os.path.exists('/home/giampaolo/.gvfs'))"
> False
>
> This is due to os.stat() which internally fails with PermissionError (EACCES).
BTW, the same is true for FUSE when an FS has been mounted without
something like "-o allow_other" or "-o allow_root":
root@nb # ls /home/phd/mnt/net
ls: cannot access /home/phd/mnt/net: Permission denied
Oleg.
--
Oleg Broytmanhttp://phdru.name/[email protected]
Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0 beta 1
All,
Congradulations. This is a big one!
On Wed, Jun 27, 2012 at 2:10 AM, Georg Brandl wrote:
> On behalf of the Python development team, I'm happy to announce the
> first beta release of Python 3.3.0.
>
> This is a preview release, and its use is not recommended in
> production settings.
>
> Python 3.3 includes a range of improvements of the 3.x series, as well
> as easier porting between 2.x and 3.x. Major new features and changes
> in the 3.3 release series are:
>
> * PEP 380, syntax for delegating to a subgenerator ("yield from")
> * PEP 393, flexible string representation (doing away with the
> distinction between "wide" and "narrow" Unicode builds)
> * A C implementation of the "decimal" module, with up to 80x speedup
> for decimal-heavy applications
> * The import system (__import__) now based on importlib by default
> * The new "lzma" module with LZMA/XZ support
> * PEP 397, a Python launcher for Windows
> * PEP 405, virtual environment support in core
> * PEP 420, namespace package support
> * PEP 3151, reworking the OS and IO exception hierarchy
> * PEP 3155, qualified name for classes and functions
> * PEP 409, suppressing exception context
> * PEP 414, explicit Unicode literals to help with porting
> * PEP 418, extended platform-independent clocks in the "time" module
> * PEP 412, a new key-sharing dictionary implementation that
> significantly saves memory for object-oriented code
> * PEP 362, the function-signature object
> * The new "faulthandler" module that helps diagnosing crashes
> * The new "unittest.mock" module
> * The new "ipaddress" module
> * The "sys.implementation" attribute
> * A policy framework for the email package, with a provisional (see
> PEP 411) policy that adds much improved unicode support for email
> header parsing
> * A "collections.ChainMap" class for linking mappings to a single unit
> * Wrappers for many more POSIX functions in the "os" and "signal"
> modules, as well as other useful functions such as "sendfile()"
> * Hash randomization, introduced in earlier bugfix releases, is now
> switched on by default
>
> In total, almost 500 API items are new or improved in Python 3.3.
> For a more extensive list of changes in 3.3.0, see
>
> http://docs.python.org/3.3/whatsnew/3.3.html (*)
>
> To download Python 3.3.0 visit:
>
> http://www.python.org/download/releases/3.3.0/
>
> Please consider trying Python 3.3.0 with your code and reporting any bugs
> you may notice to:
>
> http://bugs.python.org/
>
>
> Enjoy!
>
> (*) Please note that this document is usually finalized late in the release
> cycle and therefore may have stubs and missing entries at this point.
>
> --
> Georg Brandl, Release Manager
> georg at python.org
> (on behalf of the entire python-dev team and 3.3's contributors)
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com
--
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 423 : naming conventions and recipes related to packaging
Hi, Here is an informational PEP proposal: http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt Could you review it for style, consistency and content? Additional notes: * Original discussion posted to [email protected] * started on May 2012 at http://mail.python.org/pipermail/distutils-sig/2012-May/018551.html * continues in June 2012 at http://mail.python.org/pipermail/distutils-sig/2012-June/018641.html * that's why I set "Discussion-To:" header. * Original document was edited as a contrib to cpython documentation: * http://bugs.python.org/issue14899 * file history at https://bitbucket.org/benoitbryon/cpython/history/Doc/packaging/packagenames.rst * but it looked like a PEP, so posted to [email protected]... Regards, Benoit (benoitbb on irc.freenode.net) ___ Python-Dev mailing list [email protected] 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 423 : naming conventions and recipes related to packaging
Hello, On Wed, 27 Jun 2012 11:08:45 +0200 Benoît Bryon wrote: > Hi, > > Here is an informational PEP proposal: > http://hg.python.org/peps/file/52767ab7e140/pep-0423.txt > > Could you review it for style, consistency and content? There is one Zen principle this PEP is missing: Flat is better than nested. This PEP seems to promote the practice of having a top-level namespace denote ownership. I think it should do the reverse: promote meaningful top-level packages (e.g. "sphinx") as standard practice, and allow an exception for when a piece of software is part of a larger organizational body. (i.e., "Community-owned projects can avoid namespace packages" should be the first item in the PEP and renamed so that it appears common rule) I don't think we want a Java-like landscape where everyone operates behind their closed fences à la org.myorganization.somecommunity and where package names shout "ownership" rather than "functionality". (*) Also, do note that "packaging" is ambiguous in Python-land. (*) (for the record, companies internally can do what they want; this PEP AFAICT addresses the case of publicly released packages) Regards Antoine. ___ Python-Dev mailing list [email protected] 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 423 : naming conventions and recipes related to packaging
I thought the PEP actually covered it pretty well: - if you don't want to worry about name conflicts for every module, pick *one* short top level namespace for your group and use that - for shared modules, use the top level namespace with PyPI as the name registry It's reasonable advice when coupled with the "avoid more than two levels of nesting - when tempted by this, split out some peer modules" elsewhere in the doc. ___ Python-Dev mailing list [email protected] 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 423 : naming conventions and recipes related to packaging
On Wed, 27 Jun 2012 21:19:57 +1000
Nick Coghlan wrote:
> I thought the PEP actually covered it pretty well:
> - if you don't want to worry about name conflicts for every module, pick
> *one* short top level namespace for your group and use that
> - for shared modules, use the top level namespace with PyPI as the name
> registry
That's not very clear to me when reading the PEP.
For example, one of the items in the "overview" is "use top-level
namespace for ownership". I don't think it should be, unless we want to
promote such a practice.
Similarly, I think the section about private projects ("Private
(including closed-source) projects use a namespace") should be removed.
It is not our duty to promote naming standards for private (i.e.
internal) projects. Also, I don't see what's so important about using
your company's name as a top-level namespace. You don't need it for
conflict avoidance: you can just as well use distinctive project names.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
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 423 : naming conventions and recipes related to packaging
On 27 June 2012 12:34, Antoine Pitrou wrote: > On Wed, 27 Jun 2012 21:19:57 +1000 > Nick Coghlan wrote: >> I thought the PEP actually covered it pretty well: >> - if you don't want to worry about name conflicts for every module, pick >> *one* short top level namespace for your group and use that >> - for shared modules, use the top level namespace with PyPI as the name >> registry > > That's not very clear to me when reading the PEP. > For example, one of the items in the "overview" is "use top-level > namespace for ownership". I don't think it should be, unless we want to > promote such a practice. I agree. I only skimmed the PEP, but even on a skimming, I got the impression that it was promoting the use of namespaces for ownership, in a Java-like way. The part Nick quoted is substantially more reasonable (assuming that's a direct quote, rather than Nick's summarisation) but the principle should be made clear right at the top. I'd say that a headline item should be something like; Using namespaces: - "Flat is better than nested" - where possible, use a single top-level name for your package (check on PyPI that the name you choose isn't in use). - Where you expect to have multiple packages all relating to the same top-level functionality, it may make sense to use a single top-level namespace package, and put your packages underneath that. - There should never be a need to use more than one level of namespace (if you think there is, you should probably promote each of the level-2 namespaces.to the top level). - Namespaces (and package names) should always be based on functionality, never on ownership[1]. Personal or private code doesn't need to follow these guidelines, but be aware that personal code often ends up more widely used than originally envisaged... [1] Sorry, Barry. There clearly needs to be an exception for the flufl namespace :-) Paul. ___ Python-Dev mailing list [email protected] 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.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories
Am 27.06.2012 01:49, schrieb Giampaolo Rodolà:
> I've just noticed a strange behavior when dealing with gvfs filesystems:
>
> giampaolo@ubuntu:~$ python -c "import os;
> print(os.path.exists('/home/giampaolo/.gvfs'))"
> True
> giampaolo@ubuntu:~$ sudo su
> root@ubuntu:~# python -c "import os;
> print(os.path.exists('/home/giampaolo/.gvfs'))"
> False
The issue isn't isolated to GVFS. It's more the current user doesn't
have the exec persmission on the directory entry /home/giampaolo. On
most systems the home directories have either 0700 or 0750.
A user needs the 'x' bit enter or traverse through a directory
(mnemonic: exec -> enter), the 'r' bit to read the content of a
directory (e.g. listdir) and the 'w' bit to write (create or delete
files unless the sticky bit is set).
Christian
___
Python-Dev mailing list
[email protected]
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.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories
On 27/06/12 02:19:03, Giampaolo Rodolà wrote: > 2012/6/27 Cameron Simpson : >> So I'd be +0.5 for making the docs more clear that True is reliable and >> False may merely mean "could not access". > > +1 +1 > I was about to propose a 'strict' parameter which lets the exception > propagate in case of errno != EACCES/EPERM but a doc fix is probably > just fine. > I'll file a bug report later today. A 'strict' parameter that just propagates the exception might be a good idea. That would allow the user to deal with whatever issues stat() encounters. Arbitrarily mapping EPERM to 'False' would be unhelpful, as it leaves the user in a position where one value can mean two different things. -- HansM ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Poking about issue 1677
On 26/06/2012 20:02, Terry Reedy wrote: > On 6/26/2012 6:51 AM, Devin Jeanpierre wrote: > >> The issue is that sometimes, if you press ctrl-c on Windows, instead >> of raising a KeyboardInterrupt, Python will exit completely. Because >> of this, any program that relies on ctrl-c/KeyboardInterrupt is not >> guaranteed to work on windows. Also, working with the interactive >> interpreter becomes really annoying for those with the habit of >> deleting the whole input line via ctrl-c. > > Idle Shell, 3.3.0a4, Win 7does not seem to have this problem. Still up > after 6000 ^Cs. It is better anyway, in multiple ways, than Command > Prompt. (That does not help batch-mode programs, though.) > > That aside, perhaps the way it handles ^C might help. > > I did get the CP to close four times, each time after a few hundred to > maybe a thousand ^Cs. It seems to require more than just one held down > key press. I suspect the closures happened after the limited line buffer > was filled and it was starting to delete the earliest lines. > I've just updated the call with as much as I had time for just now. Your point about IDLE made me think; I installed pyreadline and now I can't get it to fail at all. Seems to point even more to myreadline.c. More later TJG ___ Python-Dev mailing list [email protected] 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 423 : naming conventions and recipes related to packaging
On 27 June 2012 13:20, Paul Moore wrote:
> I agree. I only skimmed the PEP, but even on a skimming, I got the
> impression that it was promoting the use of namespaces for ownership,
> in a Java-like way. The part Nick quoted is substantially more
> reasonable (assuming that's a direct quote, rather than Nick's
> summarisation) but the principle should be made clear right at the
> top.
Reading in a bit more depth, I'd say that I specifically disagree with
this section:
"""
Top-level namespace relates to code ownership
=
This helps avoid clashes between project names.
Ownership could be:
* an individual.
[...]
* an organization.
[...]
* a group or community.
[...]
* a group or community related to another package.
"""
I'd say a top-level namespace should *never* (hello again, Barry!)
relate to an individual. And never to an organisation either, the
Django case notwithstanding. In the case of Django, I see the
top-level namespace as belonging to the *software* Django, not to the
*organisation*, the Django foundation. In fact, with the exception of
the "an individual" case, I'd say all of the others are actually
referring to the software rather than the organisation/group/community
owning that project.
To be honest, I see this whole section as misguided - the top-level
namespace is the project. Simple as that. Oh, and the terminology is
further muddled here, as the "top level namespace" is usually not a
namespace package in the sense of PEP 420.
Generally, the impression I get is that the PEP is recommending more
levels of nesting than I would agree with: But it's hard to be sure,
because the concept of nesting feels a bit overloaded. The key for me
is that generally, I like to be able to type "import X" where X is not
a dotted name, and then refer to X.x1, X.x2, etc. I'd call that no
levels of nesting, to be honest. For complex stuff, subpackages
("import X.Y") might be needed, but that's rare (and even then, key
names should be exposed directly from X).
Paul.
PS Having said all this, I don't maintain any code on PyPI - I'm a
user not a producer. That may affect my perspective...
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Poking about issue 1677
I can confirm that there is a race condition between the code in myreadline.c and the signal_handler. I have a patch in readiness which basically loops until the signal has been tripped. But what I don't know is: what to do if the signal *still* doesn't trip (after 100 millisecond-retries)? At present the code just drops through (with a comment warning) which is why we're seeing the interpreter exit. What should happen, though? Raise SystemError? ___ Python-Dev mailing list [email protected] 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 423 : naming conventions and recipes related to packaging
On 2012-06-27, at 10:57 AM, Paul Moore wrote:
> Generally, the impression I get is that the PEP is recommending more
> levels of nesting than I would agree with: But it's hard to be sure,
> because the concept of nesting feels a bit overloaded. The key for me
> is that generally, I like to be able to type "import X" where X is not
> a dotted name, and then refer to X.x1, X.x2, etc. I'd call that no
> levels of nesting, to be honest. For complex stuff, subpackages
> ("import X.Y") might be needed, but that's rare (and even then, key
> names should be exposed directly from X).
Why instead of writing 'import project' you don't want to write
'from acme import project'?
With python adoption (enterprise too) growing, we will inevitably
find out that one single namespace (PyPI) is not enough, and
name collisions will become a frequent headache.
-
Yury
___
Python-Dev mailing list
[email protected]
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 423 : naming conventions and recipes related to packaging
On Wed, Jun 27, 2012 at 10:57 AM, Paul Moore wrote:
> For complex stuff, subpackages
> ("import X.Y") might be needed, but that's rare (and even then, key
> names should be exposed directly from X).
>
> Paul.
>
> PS Having said all this, I don't maintain any code on PyPI - I'm a
> user not a producer. That may affect my perspective...
>
That, and if you don't work with web stuff or networking stuff. Things
having lots of subpackages are quite the rule there.
Also, functional naming for top-level modules is actually an anti-pattern:
an invitation to naming conflicts, especially with future stdlib contents.
Suppose two people want to write an "email" package? Unless you jam the
ownership into the name (e.g. joes_email and bobs_email), what are you
supposed to do?
This is why we have popular packages with names like nose and celery and
django and pyramid and lamson: because unique memorable names >
functionally descriptive names.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On a new version of pickle [PEP 3154]: self-referential frozensets
On Sat, Jun 23, 2012 at 3:19 AM, M Stefan wrote:
> * UNION_FROZENSET: like UPDATE_SET, but create a new frozenset
>stack before: ... pyfrozenset mark stackslice
>stack after : ... pyfrozenset.union(stackslice)
>
Since frozenset are immutable, could you explain how adding the
UNION_FROZENSET opcode helps in pickling self-referential frozensets? Or
are you only adding this one to follow the current style used for pickling
dicts and lists in protocols 1 and onward?
> While this design allows pickling of self-referenti/Eal sets,
> self-referential
> frozensets are still problematic. For instance, trying to pickle `fs':
> a=A(); fs=frozenset([a]); a.fs = fs
> (when unpickling, the object a has to be initialized before it is added to
> the frozenset)
>
> The only way I can think of to make this work is to postpone
> the initialization of all the objects inside the frozenset until after
> UNION_FROZENSET.
> I believe this is doable, but there might be memory penalties if the
> approach
> is to simply store all the initialization opcodes in memory until pickling
> the frozenset is finished.
>
>
I don't think that's the only way. You could also emit POP opcode to
discard the frozenset from stack and then emit a GET to fetch it back from
the memo. This is how we currently handle self-referential tuples. Check
out the save_tuple method in pickle.py to see how it is done. Personally, I
would prefer that approach because it already well-tested and proven to
work.
That said, your approach sounds good too. The memory trade-off could lead
to smaller pickles and more efficient decoding (though these
self-referential objects are rare enough that I don't think that any
improvements there would matter much).
While self-referential frozensets are uncommon, a far more problematic
> situation is with the self-referential objects created with REDUCE. While
> pickle uses the idea of creating empty collections and then filling them,
> reduce tipically creates already-filled objects. For instance:
> cnt = collections.Counter(); cnt[a]=3; a.cnt=cnt; cnt.__reduce__()
> (, ({<__main__.A object at 0x0286E8F8>: 3},))
> where the A object contains a reference to the counter. Unpickling an
> object pickled with this reduce function is not possible, because the
> reduce
> function, which "explains" how to create the object, is asking for the
> object
> to exist before being created.
>
Your example seems to work on Python 3. I am not sure if I follow what you
are trying to say. Can you provide a working example?
$ python3
Python 3.1.2 (r312:79147, Dec 9 2011, 20:47:34)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle, collections
>>> c = collections.Counter()
>>> class A: pass
...
>>> a = A()
>>> c[a] = 3
>>> a.cnt = c
>>> b =pickle.loads(pickle.dumps(a))
>>> b in b.cnt
True
> Pickle could try to fix this by detecting when reduce returns a class type
> as the first tuple arg and move the dict ctor parameter to the state, but
> this may not always be intended. It's also a bit strange that __getstate__
> is never used anywhere in pickle directly.
>
I would advise against any such change. The reduce protocol is already
fairly complex. Further I don't think change it this way would give us any
extra flexibility.
The documentation has a good explanation of how __getstate__ works under
hood:
http://docs.python.org/py3k/library/pickle.html#pickling-class-instances
And if you need more, PEP 307 (http://www.python.org/dev/peps/pep-0307/)
provides some of the design rationales of the API.
___
Python-Dev mailing list
[email protected]
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.path.exists() / os.path.isdir() inconsistency when dealing with gvfs directories
If someone wants to see the error details, they should use os.stat directly rather than an existence check. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list [email protected] 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: Changed importlib tests to use assertIs, assertIsInstance, etc., instead of
On 6/27/2012 3:26 PM, eric.smith wrote: http://hg.python.org/cpython/rev/9623c83ba489 changeset: 77825:9623c83ba489 user:Eric V. Smith date:Wed Jun 27 15:26:26 2012 -0400 summary: Changed importlib tests to use assertIs, assertIsInstance, etc., instead of just assertTrue. You forgot assertIsNone ;-) or was that intentional? -self.assertTrue(loader is None) +self.assertIs(loader, None) self.assertIsNone(loader) tjr ___ Python-Dev mailing list [email protected] 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: Changed importlib tests to use assertIs, assertIsInstance, etc., instead of
On 6/27/2012 4:34 PM, Terry Reedy wrote: > On 6/27/2012 3:26 PM, eric.smith wrote: >> http://hg.python.org/cpython/rev/9623c83ba489 >> changeset: 77825:9623c83ba489 >> user:Eric V. Smith >> date:Wed Jun 27 15:26:26 2012 -0400 >> summary: >>Changed importlib tests to use assertIs, assertIsInstance, etc., >> instead of just assertTrue. > > You forgot assertIsNone ;-) > or was that intentional? Darn it! I can never remember which ones exist. I was hoping for an assertHasAttr, but no such luck. I'll fix it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
