On 16 Jul, 2013, at 14:02, Thomas Wouters wrote:
> On Tue, Jul 16, 2013 at 1:40 PM, Nick Coghlan wrote:
>
>> PEP 8 advises developers to use absolute imports rather than explicit
>> relative imports.
>>
>> Why? Using absolute imports couple the internal implementation of a
>> package to its p
Terry Reedy writes:
> On 7/15/2013 10:20 PM, Guido van Rossum wrote:
>
> >> Or is this something deeper, that a group *is* a new object in
> >> principle?
> >
> > No, I just think of it as returning "a string"
>
> That is exactly what the doc says it does. See my other post.
The problem
If sounds like the main problem with relative imports (even explicit)
is caused by ignoring the package structure and running modules inside
a package as a script, without using -m.
Maybe we should update the PEP to make this abundantly clear?
I note that an additional problem with informational
On 17 July 2013 11:55, Steven D'Aprano wrote:
> On 16/07/13 22:02, Thomas Wouters wrote:
> As I see it, if relative imports are a bad idea for the std lib, they're a
> bad idea for everyone. (What am I missing?) So why do we have relative
> imports? Was it a mistake? I don't think so.
>
> It seems
I have to say that a long time ago, when you couldn't tell a relative
import from a top-level import, the ban on relative imports made more
sense.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.py
On 16/07/13 22:02, Thomas Wouters wrote:
On Tue, Jul 16, 2013 at 1:40 PM, Nick Coghlan wrote:
PEP 8 advises developers to use absolute imports rather than explicit
relative imports.
Why? Using absolute imports couple the internal implementation of a
package to its public name - you can't just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Jul 16, 2013, at 07:34 PM, Tres Seaver wrote:
>On 07/16/2013 07:09 AM, Nick Coghlan wrote:
>
>> I did find it interesting that we *don't* explicitly advise against
>> the use of "import *" for anything other than optional accelerator
>> modules
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/16/2013 07:09 AM, Nick Coghlan wrote:
> I did find it interesting that we *don't* explicitly advise against
> the use of "import *" for anything other than optional accelerator
> modules or republishing internal interfaces through a public API
2013/7/16 Victor Stinner :
> I would like to add assertions in Python/ceval.c to detect such bugs
> earlier. The problem is that some functions rely on the ability to
> call PyEval_EvalFrameEx() with an exception set. Is it expected?
> Should it be avoided? The current exception can be replaced wit
2013/7/17 Serhiy Storchaka :
> Oh, I meaned Py_XDECREF.
Ah ok :-) Well, for this specific code, it can probably be replaced with:
if (_PyBytes_Resize(&bytes, n) < 0)
return NULL;
I'm not sure that _PyBytes_Resize() *always* decref bytes and then set
bytes to NULL. I was too
Am 17.07.2013 00:03, schrieb Victor Stinner:
> 2013/7/16 Serhiy Storchaka :
>>> http://hg.python.org/cpython/rev/533eb9ab895a
>>> summary:
>>>Issue #18408: Fix fileio_read() on _PyBytes_Resize() failure
>>>
>>> bytes is NULL on _PyBytes_Resize() failure
>>
>> Why not Py_DECREF?
>
> Because Py_
17.07.13 01:03, Victor Stinner написав(ла):
2013/7/16 Serhiy Storchaka :
http://hg.python.org/cpython/rev/533eb9ab895a
summary:
Issue #18408: Fix fileio_read() on _PyBytes_Resize() failure
bytes is NULL on _PyBytes_Resize() failure
Why not Py_DECREF?
Because Py_DECREF(NULL) does crash.
2013/7/16 Serhiy Storchaka :
>> http://hg.python.org/cpython/rev/533eb9ab895a
>> summary:
>>Issue #18408: Fix fileio_read() on _PyBytes_Resize() failure
>>
>> bytes is NULL on _PyBytes_Resize() failure
>
> Why not Py_DECREF?
Because Py_DECREF(NULL) does crash.
Victor
_
17.07.13 00:09, victor.stinner написав(ла):
http://hg.python.org/cpython/rev/533eb9ab895a
changeset: 84669:533eb9ab895a
user:Victor Stinner
date:Tue Jul 16 21:36:02 2013 +0200
summary:
Issue #18408: Fix fileio_read() on _PyBytes_Resize() failure
bytes is NULL on _PyBytes_Re
On 7/16/2013 9:39 AM, R. David Murray wrote:
On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano wrote:
For example, pkgutil includes classes with single-underscore methods, which I take as
private. It also has a function simplegeneric, which is undocumented and not listed in
__all__. In in
On 7/16/2013 7:40 AM, Nick Coghlan wrote:
PEP 8 advises developers to use absolute imports rather than explicit
relative imports.
Why? Using absolute imports couple the internal implementation of a
package to its public name - you can't just change the top level
directory name any more, you have
On Tue, Jul 16, 2013 at 12:55 AM, Antoine Pitrou wrote:
> Is there a strong enough use case to change it? I can't say the current
> behaviour seems very useful either, but some people may depend on it.
This is the crucial question. I personally see the current behavior as
an artifact of the (lack
On Jul 16, 2013, at 04:10 PM, Nick Coghlan wrote:
>Yeah, we should probably be a bit more vocal in pointing out that PEP
>8 is something to be applied judiciously, *not* treated as "sacred
>writ, never to be questioned". It's very tempting to just sigh and
>ignore it, instead of explicitly pointin
On Jul 16, 2013, at 11:48 PM, Nick Coghlan wrote:
>For the general case, the patch I posted to the issue tracker sets the
>precedence as docs -> __all__ -> leading underscore.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On Jul 16, 2013, at 11:28 AM, Richard Oudkerk wrote:
>BTW, how does the use of __all__ effect things? Somewhere I got the idea
>that if a module uses __all__ then anything not listed is internal. I take
>it that is wrong?
Purely technically, __all__ is there to affect how from-import-* works.
On Jul 15, 2013, at 11:02 PM, Chris McDonough wrote:
>Given that misunderstanding, is there a way to divorce stdlib-centric
>guidelines like the one being discussed now from "PEP8"-ness? I don't
>think any amount of marketing effort or reasoned explanation is going to
>separate "PEP8" from "corre
On Jul 16, 2013, at 02:02 PM, Thomas Wouters wrote:
>In my experience changing the name of a package is problematic for more
>reasons than just 'import'. We used to do the put-in-a-package thing for
>third-party packages at Google, and we quit doing it because it was just
>too painful: it's hard t
On 16 July 2013 23:39, R. David Murray wrote:
> On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano
> wrote:
>> On 16/07/13 20:28, Richard Oudkerk wrote:
>> > On 16/07/2013 6:44am, Nick Coghlan wrote:
>> >> Clarifying what constitutes an internal interface in a way that
>> >> doesn't require ren
On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano wrote:
> On 16/07/13 20:28, Richard Oudkerk wrote:
> > On 16/07/2013 6:44am, Nick Coghlan wrote:
> >> Clarifying what constitutes an internal interface in a way that
> >> doesn't require renaming anything is a necessary prerequisite for
> >> bund
On 16/07/13 20:28, Richard Oudkerk wrote:
On 16/07/2013 6:44am, Nick Coghlan wrote:
Clarifying what constitutes an internal interface in a way that
doesn't require renaming anything is a necessary prerequisite for
bundling or bootstrapping the pip CLI in Python 3.4 (as pip exposes
its internal i
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/issue17
On 16 July 2013 22:27, Nick Coghlan wrote:
> These are good reasons, but they're not the reasons the PEP currently
> gives. "Better failure modes" is a good practical benefit :)
I have now included an updated rationale for this rule in the patch
attached to http://bugs.python.org/issue18472 (the
On 16 July 2013 22:02, Thomas Wouters wrote:
> On Tue, Jul 16, 2013 at 1:40 PM, Nick Coghlan wrote:
>>
>> PEP 8 advises developers to use absolute imports rather than explicit
>> relative imports.
>>
>> Why? Using absolute imports couple the internal implementation of a
>> package to its public n
On 16 July 2013 21:10, Nick Coghlan wrote:
> On 16 July 2013 20:28, Richard Oudkerk wrote:
>> On 16/07/2013 6:44am, Nick Coghlan wrote:
>>>
>>> Clarifying what constitutes an internal interface in a way that
>>> doesn't require renaming anything is a necessary prerequisite for
>>> bundling or boo
Am 12.07.13 01:58, schrieb Christian Heimes:
> 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
On Tue, Jul 16, 2013 at 1:40 PM, Nick Coghlan wrote:
> PEP 8 advises developers to use absolute imports rather than explicit
> relative imports.
>
> Why? Using absolute imports couple the internal implementation of a
> package to its public name - you can't just change the top level
> directory n
PEP 8 advises developers to use absolute imports rather than explicit
relative imports.
Why? Using absolute imports couple the internal implementation of a
package to its public name - you can't just change the top level
directory name any more, you have to go through and change all the
absolute i
On 16 July 2013 20:28, Richard Oudkerk wrote:
> On 16/07/2013 6:44am, Nick Coghlan wrote:
>>
>> Clarifying what constitutes an internal interface in a way that
>> doesn't require renaming anything is a necessary prerequisite for
>> bundling or bootstrapping the pip CLI in Python 3.4 (as pip expose
On 16 July 2013 18:41, Terry Reedy wrote:
> On 7/15/2013 11:11 PM, Nick Coghlan wrote:
>
>> I'll look into adding some stronger wording at the top making it clear
>> that while PEP 8 is a useful starting point and a good default if a
>> project doesn't have a defined style guide of it's own, it is
On 16 July 2013 19:18, Terry Reedy wrote:
> I wonder if the change was an artifact of changing the code to prohibit
> mixing Unicode and bytes.
I'm pretty sure we the only thing we changed in 3.x is to migrate re
to the PEP 3118 buffer API, and the behavioural change Guido is seeing
is actually t
On 16/07/2013 6:44am, Nick Coghlan wrote:
Clarifying what constitutes an internal interface in a way that
doesn't require renaming anything is a necessary prerequisite for
bundling or bootstrapping the pip CLI in Python 3.4 (as pip exposes
its internal implemetnation API as "import pip" rather th
2013/7/16 Antoine Pitrou :
> Le Tue, 16 Jul 2013 02:34:49 +0200,
> Victor Stinner a écrit :
>> I would like to add assertions in Python/ceval.c to detect such bugs
>> earlier. The problem is that some functions rely on the ability to
>> call PyEval_EvalFrameEx() with an exception set. Is it expect
On 7/15/2013 10:20 PM, Guido van Rossum wrote:
Or is this something deeper, that a group *is* a new object in
principle?
No, I just think of it as returning "a string"
That is exactly what the doc says it does. See my other post.
--
Terry Jan Reedy
_
On 7/15/2013 7:14 PM, Guido van Rossum wrote:
In a discussion about mypy I discovered that the Python 3 version of
the re module's Match object behaves subtly different from the Python
2 version when the target string (i.e. the haystack, not the needle)
is a buffer object.
In Python 2, the type
On 7/15/2013 11:11 PM, Nick Coghlan wrote:
I'll look into adding some stronger wording at the top making it clear
that while PEP 8 is a useful starting point and a good default if a
project doesn't have a defined style guide of it's own, it is *not*
the be-all-and-end-all for Python style guides
Le Tue, 16 Jul 2013 02:34:49 +0200,
Victor Stinner a écrit :
> Hi,
>
> I'm working on the issue #18408 (fix issues found by my pyfailmalloc
> tool). To analyze some bugs, I have to add debug traces in various
> functions to find which function returned NULL without setting an
> error, or the oppo
Le Mon, 15 Jul 2013 21:53:42 -0700,
Guido van Rossum a écrit :
> Hm. I'd still like to change this, but I understand it's debatable...
> Is the group() method written in C or Python?
Is there a strong enough use case to change it? I can't say the current
behaviour seems very useful either, but so
42 matches
Mail list logo
