Just a small input into this discussion:
In EVE, for historical reasons, we implemented our own importing mechanism. I
think it is because we started out with an ancient Python version that didn't
support packages.
Regardless, we still have a system where a hierarchy of files is scanned, and
t
Antoine Pitrou writes:
> On Wed, 03 Nov 2010 11:47:55 +1100
> Ben Finney wrote:
> >
> > > If someone wants to depend on some undocumented detail of the
> > > directory layout it's their problem (like people depending on
> > > bytecode and other stuff).
> >
> > I would say that names without a
On Tue, Nov 2, 2010 at 7:50 PM, Brett Cannon wrote:
> This is not what I am suggesting for PEP 8. I want to say that a
> package's file structure should reflect the public API.
But what does that mean? I could argue that unittest's structure
(TestCase in case.py, etc.) reflects its public API jus
On Tue, 2 Nov 2010 19:57:48 -0700
Brett Cannon wrote:
> >
> > How could we have split the module into a package in a way that matched the
> > API, whilst still retaining backwards compatibility with the old API? We had
> > no choice but to export the public names at the top level.
>
> I'm not dis
On Wed, 03 Nov 2010 11:47:55 +1100
Ben Finney wrote:
>
> > If someone wants to depend on some undocumented detail of the
> > directory layout it's their problem (like people depending on bytecode
> > and other stuff).
>
> I would say that names without a single leading underscore are part of
> t
FWIW, I also agree with Michael that static analysis would be much
preferred. You never know what side effects importing a module has.
(This could even be construed as an attack vector.)
--Guido
On Tue, Nov 2, 2010 at 7:54 PM, Brett Cannon wrote:
> On Tue, Nov 2, 2010 at 17:35, Guido van Rossum
On Tue, Nov 2, 2010 at 19:50, Michael Foord wrote:
> On 02/11/2010 02:35, Brett Cannon wrote:
>>
>> On Wed, Oct 27, 2010 at 03:42, Antoine Pitrou wrote:
>>>
>>> On Tue, 26 Oct 2010 22:06:37 -0400
>>> Alexander Belopolsky wrote:
While I appreciate your and Michael's eloquence, I don't r
On Tue, Nov 2, 2010 at 17:35, Guido van Rossum wrote:
> If you are importing the code, the __module__ attribute on each class
> should tell you where it is actually defined (as opposed to where you
> imported it from). Then sys.modules gives you the module object which
> has a __file__ attribute,
On 02/11/2010 02:35, Brett Cannon wrote:
On Wed, Oct 27, 2010 at 03:42, Antoine Pitrou wrote:
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolsky wrote:
While I appreciate your and Michael's eloquence, I don't really see
why five 400-line modules are necessarily easier to maintain than on
On Tue, Nov 2, 2010 at 16:43, Guido van Rossum wrote:
> On Tue, Nov 2, 2010 at 4:39 PM, Michael Foord
> wrote:
>> As the maintainer of unittest I'd like to say that in the absence of clear
>> consensus that the merger should happen, or a fiat from the BDFL, the merger
>> won't happen. I believe
On Tue, Nov 2, 2010 at 8:47 PM, Ben Finney wrote:
> I would say that names without a single leading underscore are part of
> the public API, whether documented or not.
I don't recall this ever being the standard library's policy. There are
many modules using leading underscores as hints, and man
On 12:47 am, ben+pyt...@benfinney.id.au wrote:
Antoine Pitrou writes:
I don't agree with this. Until it's documented, it's an implementation
detail and should be able to change without notice.
If it's an implementation detail, shouldn't it be named as one (i.e.
with a leading underscore)?
If
On 02/11/2010 23:44, Raymond Hettinger wrote:
Brett, Does the import mechanism for importing packages preserve enough
information to be able to figure-out where all the components are defined? I'm
wondering if it is possible for the class browser to be built-out to
scan/navigate class struct
Antoine Pitrou writes:
> I don't agree with this. Until it's documented, it's an implementation
> detail and should be able to change without notice.
If it's an implementation detail, shouldn't it be named as one (i.e.
with a leading underscore)?
> If someone wants to depend on some undocumente
If you are importing the code, the __module__ attribute on each class
should tell you where it is actually defined (as opposed to where you
imported it from). Then sys.modules gives you the module object which
has a __file__ attribute, etc.
On Tue, Nov 2, 2010 at 4:44 PM, Raymond Hettinger
wrote:
On Tue, Nov 2, 2010 at 5:03 PM, Raymond Hettinger
wrote:
> Some forces against packaging are that it breaks the class browser. As you
> say, different users of different toolsets are affected differently. For me,
> the unittest split broke my usual ways of finding out how the new methods
> we
Raymond Hettinger writes:
> >> Are we permanently locked into the exact ten filenames that are
> >> currently used: utils, suite, loader, case, result, main, signals,
> >> etc?
[…]
> Sounds like a decision to split a module into a package is a big
> commitment. Each of the individual file names b
On 02/11/2010 23:34, Michael Foord wrote:
On 02/11/2010 23:00, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 15:47, Raymond Hettinger
wrote:
On Nov 1, 2010, at 7:35 PM, Brett Cannon wrote:
I think the issue here is that the file structure of the code no
longer matches the public API documented
On Nov 2, 2010, at 4:43 PM, Guido van Rossum wrote:
> The remaining thrust of the thread seems
> to be whether PEP 8 should advise against breaking code up into many
> little modules.
I was thinking of PEP 8 wording that listed the forces for and against.
For example, ply.yacc and ply.lex was
Brett, Does the import mechanism for importing packages preserve enough
information to be able to figure-out where all the components are defined? I'm
wondering if it is possible for the class browser to be built-out to
scan/navigate class structure across a module that has been split into a
On Tue, Nov 2, 2010 at 4:39 PM, Michael Foord wrote:
> As the maintainer of unittest I'd like to say that in the absence of clear
> consensus that the merger should happen, or a fiat from the BDFL, the merger
> won't happen. I believe that this is standard Python development process.
I don't thin
On 02/11/2010 22:58, Guido van Rossum wrote:
On Tue, Nov 2, 2010 at 3:47 PM, Raymond Hettinger
wrote:
I'm not sure I follow where we're stuck with the current package.
AFAICT, the module is still used with "import unittest".
The file splitting was done badly, so I don't think there any of the
On 02/11/2010 23:00, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 15:47, Raymond Hettinger
wrote:
On Nov 1, 2010, at 7:35 PM, Brett Cannon wrote:
I think the issue here is that the file structure of the code no
longer matches the public API documented by unittest. Personally I,
like most people
Le mardi 02 novembre 2010 à 16:32 -0700, Raymond Hettinger a écrit :
> On Nov 2, 2010, at 4:00 PM, Brett Cannon wrote:
> >> Are we permanently locked into the exact ten filenames
> >> that are currently used: utils, suite, loader, case, result, main,
> >> signals,
> >> etc?
> >> Is the file struc
On Nov 2, 2010, at 4:00 PM, Brett Cannon wrote:
>> Are we permanently locked into the exact ten filenames
>> that are currently used: utils, suite, loader, case, result, main, signals,
>> etc?
>> Is the file structure now frozen?
>
> Somewhat, yes.
That's a bummer.
Sounds like a decision to sp
Le mardi 02 novembre 2010 à 16:20 -0700, Raymond Hettinger a écrit :
>
> For example, to find-out what assert.ItemsEqual does, I have
> to figure-out that it was put in the case.py file.
Well, it's a TestCase method, so it seems rather intuitive to look for
it in case.py.
Regards
Antoine.
___
On Nov 2, 2010, at 3:58 PM, Guido van Rossum wrote:
> To spout a somewhat contrarian opinion, I just browsed the new
> unittest package, and the structure seems reasonable to me, even if
> its submodules are not particularly reusable. I've used this kind of
> style for development myself. What is
On 02/11/2010 22:43, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 15:33, Nick Coghlan wrote:
On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon wrote:
So basically it seems like we have learned a lesson: we prefer to have
our code structured in files that match the public API. I think that
is a legi
2010/11/2 Raymond Hettinger :
> On Nov 1, 2010, at 7:35 PM, Brett Cannon wrote:
>
> I think the issue here is that the file structure of the code no
> longer matches the public API documented by unittest. Personally I,
> like most people it seems, prefer source files to be structured in a
> way to
On Tue, Nov 2, 2010 at 15:47, Raymond Hettinger
wrote:
> On Nov 1, 2010, at 7:35 PM, Brett Cannon wrote:
>
> I think the issue here is that the file structure of the code no
> longer matches the public API documented by unittest. Personally I,
> like most people it seems, prefer source files to be
Le mardi 02 novembre 2010 à 15:47 -0700, Raymond Hettinger a écrit :
>
> What is it you're seeing as a risk that I'm not seeing?
> Are we permanently locked into the exact ten filenames
> that are currently used: utils, suite, loader, case, result, main,
> signals, etc?
> Is the file structure no
On Tue, Nov 2, 2010 at 3:47 PM, Raymond Hettinger
wrote:
> I'm not sure I follow where we're stuck with the current package.
> AFAICT, the module is still used with "import unittest".
> The file splitting was done badly, so I don't think there any of the
> components are usable directly, i.e. "fro
On Nov 02, 2010, at 03:43 PM, Brett Cannon wrote:
>On Tue, Nov 2, 2010 at 15:33, Nick Coghlan wrote:
>> On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon wrote:
>>> So basically it seems like we have learned a lesson: we prefer to have
>>> our code structured in files that match the public API. I th
On Nov 2, 2010, at 3:33 PM, Nick Coghlan wrote:
> On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon wrote:
>> So basically it seems like we have learned a lesson: we prefer to have
>> our code structured in files that match the public API. I think that
>> is a legitimate design rule for the stdlib t
On Nov 1, 2010, at 7:35 PM, Brett Cannon wrote:
>
> I think the issue here is that the file structure of the code no
> longer matches the public API documented by unittest. Personally I,
> like most people it seems, prefer source files to be structured in a
> way to match the public API. In the ca
On Tue, Nov 2, 2010 at 15:33, Nick Coghlan wrote:
> On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon wrote:
>> So basically it seems like we have learned a lesson: we prefer to have
>> our code structured in files that match the public API. I think that
>> is a legitimate design rule for the stdlib
On Tue, Nov 2, 2010 at 10:55 PM, Victor Stinner
wrote:
> I don't know how to ignore the BytesWarning without importing warning. How can
> I do that?
I was suggesting trying to fix the bootstrap issue so you could use a
top-level import, instead of working around it with a function level
import (w
exar...@twistedmatrix.com wrote:
I can't help thinking that most of this confusion is caused by using <
for determining subsets. If < were not defined for sets and people had
to use "set.issubset" (which exists already), then sorting a list with
sets would raise an exception, a much more unde
On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon wrote:
> So basically it seems like we have learned a lesson: we prefer to have
> our code structured in files that match the public API. I think that
> is a legitimate design rule for the stdlib to follow from now on, but
> in the case of unittest it'
On 11/2/2010 1:23 PM, Michael Foord wrote:
Right, I did quote that exact text earlier in the thread. False
expectations come when there are exceptions to otherwise-consistent
behaviour.
Particularly as it still works for other mutable collections. Worth
being aware that custom implementations
On 02/11/2010 17:17, exar...@twistedmatrix.com wrote:
On 04:29 pm, fuzzy...@voidspace.org.uk wrote:
On 02/11/2010 16:23, Terry Reedy wrote:
On 11/2/2010 10:05 AM, C. Titus Brown wrote:
...but, as someone who has to figure out how to teach stuff to CSE
undergrads
(and biology grads) I hate the
On 04:29 pm, fuzzy...@voidspace.org.uk wrote:
On 02/11/2010 16:23, Terry Reedy wrote:
On 11/2/2010 10:05 AM, C. Titus Brown wrote:
...but, as someone who has to figure out how to teach stuff to CSE
undergrads
(and biology grads) I hate the statement "...any programmer should
expect this..."
Terry Reedy writes:
> ethical character. Or have them consider the partial order dependencies
> between morning get-ready-for-class activities (socks before shoes
> versus pants and shirt in either order). They already do topological
> sorting every day, even if the name seems fancy.
Augme
On Tue, Nov 2, 2010 at 12:37 PM, Jacob Kaplan-Moss wrote:
> Hopefully I'm still allowed to use Python.
Definitely! Python's a great place to learn about all these things. :-)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
__
On Tue, Nov 2, 2010 at 11:23 AM, Terry Reedy wrote:
> What I did say in the post you responded to is "Any programmer who sorts (or
> uses functions that depend on proper sorting) should know and respect the
> difference between partial orders, such as set inclusion, and total orders,
> such as lex
On 02/11/2010 16:23, Terry Reedy wrote:
On 11/2/2010 10:05 AM, C. Titus Brown wrote:
...but, as someone who has to figure out how to teach stuff to CSE
undergrads
(and biology grads) I hate the statement "...any programmer should
expect this..."
And indeed I (intentionally) did not say that.
On 11/2/2010 10:05 AM, C. Titus Brown wrote:
...but, as someone who has to figure out how to teach stuff to CSE undergrads
(and biology grads) I hate the statement "...any programmer should
expect this..."
And indeed I (intentionally) did not say that. People who are ignorant
and inexperience
Sorry for late post.
On 2010/09/29 20:01, Antoine Pitrou wrote:
Furthermore, it can produce real bugs, especially under Windows when
coupled with refererence cycles created by traceback objects
I think this can be relaxed with the patch in #9815. ;-)
___
On Tue, Nov 02, 2010 at 05:28:43PM +0900, Stephen J. Turnbull wrote:
> C. Titus Brown writes:
>
> > p.s. Seriously? I can accept that there's a rational minimalist argument
> > for this "feature",
>
> It is a feature, even if you aren't gonna need it. I want it.
>
> Many programmers do know
I don't know how to ignore the BytesWarning without importing warning. How can
I do that?
Victor
Le vendredi 29 octobre 2010 04:31:42, Benjamin Peterson a écrit :
> 2010/10/28 victor.stinner :
> > Author: victor.stinner
> > Date: Fri Oct 29 02:38:58 2010
> > New Revision: 85902
> >
> > Log:
> >
C. Titus Brown writes:
> p.s. Seriously? I can accept that there's a rational minimalist argument
> for this "feature",
It is a feature, even if you aren't gonna need it. I want it.
Many programmers do know that sets are partially ordered by inclusion,
preordered by size, and (in Python) tot
51 matches
Mail list logo
