On Wed, Nov 3, 2010 at 4:59 PM, Glyph Lefkowitz wrote:
..
> Maybe ship with a command that says "hey, somewhere on sys.path,
> there is a class with . Please run '$EDITOR file +line' (or the
> current OS's equivalent) so I can look at the source code".
>
Well, we already have inspect.findsource
On Nov 3, 2010, at 11:26 AM, Alexander Belopolsky wrote:
> This may not be a problem for smart tools, but for me and a simple
> editor what used to be:
Maybe this is the real problem? It's 2010, we should all be far enough beyond
EDLIN that our editors can jump to the definition of a Python c
On 03/11/2010 19:48, Jesse Noller wrote:
On Wed, Nov 3, 2010 at 3:45 PM, Antoine Pitrou wrote:
On Wed, 03 Nov 2010 19:26:53 +
Michael Foord wrote:
Antoine is firmly of the opinion that making TestCase instances
unpickleable is a feature...
Apparently you didn't really understand me. I'm
Le mercredi 03 novembre 2010 à 15:48 -0400, Jesse Noller a écrit :
> On Wed, Nov 3, 2010 at 3:45 PM, Antoine Pitrou wrote:
> > On Wed, 03 Nov 2010 19:26:53 +
> > Michael Foord wrote:
> >>
> >> Antoine is firmly of the opinion that making TestCase instances
> >> unpickleable is a feature...
>
On Wed, Nov 3, 2010 at 3:45 PM, Antoine Pitrou wrote:
> On Wed, 03 Nov 2010 19:26:53 +
> Michael Foord wrote:
>>
>> Antoine is firmly of the opinion that making TestCase instances
>> unpickleable is a feature...
>
> Apparently you didn't really understand me. I'm of the opinion that
> making
On Wed, 03 Nov 2010 19:26:53 +
Michael Foord wrote:
>
> Antoine is firmly of the opinion that making TestCase instances
> unpickleable is a feature...
Apparently you didn't really understand me. I'm of the opinion that
making TestCase instances pickleable is useless if that pickling
doesn't
On 03/11/2010 14:53, Eric Smith wrote:
On 11/3/10 10:16 AM, Michael Foord wrote:
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of the individual file names bec
On Nov 3, 2010, at 1:04 PM, James Y Knight wrote:
> This is the strongest reason why I recommend to everyone I know that they not
> use pickle for storage they'd like to keep working after upgrades [not just
> of stdlib, but other 3rd party software or their own software]. :)
+1.
Twisted actu
On Nov 3, 2010, at 11:25 AM, Eric Smith wrote:
> On 11/3/10 10:53 AM, Eric Smith wrote:
>
>> The problem is that there is no unittest.loader in 2.4, and
>> unittest.loader.TestLoader is the name that the 2.7 pickle creates. We
>> see this problem every time we try and move anything in the stdlib
On Tue, Nov 2, 2010 at 6: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. W
On 11/3/10 10:53 AM, Eric Smith wrote:
The problem is that there is no unittest.loader in 2.4, and
unittest.loader.TestLoader is the name that the 2.7 pickle creates. We
see this problem every time we try and move anything in the stdlib.
And BTW: for me, this is the strongest reason not to bre
On 03/11/2010 14:53, Eric Smith wrote:
On 11/3/10 10:16 AM, Michael Foord wrote:
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of the individual file names bec
On Nov 03, 2010, at 12:34 AM, Antoine Pitrou wrote:
>I don't agree with this. Until it's documented, it's an implementation
>detail and should be able to change without notice.
>If someone wants to depend on some undocumented detail of the directory
>layout it's their problem (like people dependin
On 11/3/10 10:16 AM, Michael Foord wrote:
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of the individual file names becomes a permanent
part of the API. Even f
On 03/11/2010 14:26, Michael Foord wrote:
On 03/11/2010 14:17, Antoine Pitrou wrote:
Le mercredi 03 novembre 2010 à 14:16 +, Michael Foord a écrit :
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module
Le mercredi 03 novembre 2010 à 14:26 +, Michael Foord a écrit :
>
> Interesting. We made some fixes before 2.7 to ensure they were copyable,
> but we fixed this in the copy module. TestCase instances now store some
> method objects in a dictionary which may make them unpickleable, so that
>
On 03/11/2010 14:17, Antoine Pitrou wrote:
Le mercredi 03 novembre 2010 à 14:16 +, Michael Foord a écrit :
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module into a package is a big commitment.
Eac
Le mercredi 03 novembre 2010 à 14:16 +, Michael Foord a écrit :
> On 03/11/2010 14:05, Nick Coghlan wrote:
> > On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
> > wrote:
> >> Sounds like a decision to split a module into a package is a big
> >> commitment. Each of the individual file name
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
Sounds like a decision to split a module into a package is a big commitment.
Each of the individual file names becomes a permanent part of the API. Even
future additional splits are precluded
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
wrote:
> Sounds like a decision to split a module into a package is a big commitment.
> Each of the individual file names becomes a permanent part of the API. Even
> future additional splits are precluded because it might break someones dotted
On 11/03/2010 01:47 AM, 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
the public API, whether docu
On 03/11/2010 02:57, Brett Cannon wrote:
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 Pitrouwrote:
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolskywrote:
While I appreciate your and Michael's
Am 03.11.2010 03:35, schrieb Antoine Pitrou:
> 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
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
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 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
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
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
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
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 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 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 one
>> 2000-line module. Splittin
On Oct 27, 2010, at 10:34 AM, R. David Murray wrote:
>To put your mind at ease, Barry, I'd not want to do that either :)
Phew! But I wasn't worried, 'cause I know you're not insane. (Though the
fact that you've effectively inherited the email package does bring that into
question. :)
>But by (
> While maintainers' convenience is a valid valid concern and some level
> of idiosyncrasy is healthy to allow active maintainers to code in
> their preferred style, I think users' convenience should come first
> when it conflicts with that of maintainers. Remember, code is written
> once and read
On Tue, 26 Oct 2010 23:37:10 -0400, Barry Warsaw wrote:
> On Oct 26, 2010, at 09:54 PM, Antoine Pitrou wrote:
> >I think it comes down to the preference of whoever works the most
> >actively on it. Michael is the most active contributor to unittest by
> >far, and I suppose he prefers it to be spli
On 10/27/2010 08:51 AM, Nick Coghlan wrote:
On Wed, Oct 27, 2010 at 2:33 PM, Ron Adam wrote:
I still would like to know what your thoughts are concerning where to put,
and/or how to package, the simple threaded text server?
Given the time frame until beta 1, I'd suggest leaving it in pydoc
On Wed, Oct 27, 2010 at 2:33 PM, Ron Adam wrote:
> I still would like to know what your thoughts are concerning where to put,
> and/or how to package, the simple threaded text server?
Given the time frame until beta 1, I'd suggest leaving it in pydoc for
now. We can look at possibly documenting i
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 one
> 2000-line module. Splitting code into modules is certainly a good
> thing when the resu
On Oct 26, 2010, at 8:37 PM, Barry Warsaw wrote:
> If done well, a split can help improve the readability and discoverability of
> the code.
No doubt that is true. The problem is that splitting can also impair
discoverability.
When unittest was in one file, you knew the filename was unittest
On 10/26/2010 05:35 PM, Raymond Hettinger wrote:
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
I wonder what you may think. Keep it in pydoc or move it to the
HTTP package? Document it or not?
I still would like to know what your thoughts are concerning where to put,
and/or how to pack
On Oct 26, 2010, at 09:54 PM, Antoine Pitrou wrote:
>I think it comes down to the preference of whoever works the most
>actively on it. Michael is the most active contributor to unittest by
>far, and I suppose he prefers it to be split into several submodules.
And that seems perfectly reasonable
On Tue, 26 Oct 2010 16:46:15 -0400, Michael Foord wrote:
> On 26/10/2010 15:05, R. David Murray wrote:
> > On Tue, 26 Oct 2010 10:39:19 -0700, Raymond
> > Hettinger wrote:
> >> If someone wants to reorganize code for clarity, I would prefer keeping
> >> it within one file, bringing related functi
On Oct 26, 2010, at 04:46 PM, Michael Foord wrote:
>I find the big-ball-of-mud style development, where everything lives inside
>huge monolithic modules, very painful. I also think that it is an extremely
>bad example for new developers. There is something to be said for consistency
>within the st
On Tue, Oct 26, 2010 at 5:37 PM, Fred Drake wrote:
> On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord
> wrote:
>> I find the big-ball-of-mud style development, where everything lives inside
>> huge monolithic modules, very painful. I also think that it is an extremely
>> bad example for new develop
On 10/26/2010 05:35 PM, Raymond Hettinger wrote:
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
I've worked on pydoc to make it much nicer to use in a browser.
While you're at it. Can you please modernize the html
and create a style sheet? Right now, all of formatting
is deeply intertwined
On Oct 26, 2010, at 2:54 PM, Ron Adam wrote:
> I've worked on pydoc to make it much nicer to use in a browser.
While you're at it. Can you please modernize the html
and create a style sheet? Right now, all of formatting
is deeply intertwined with content generation.
Fixing that would be a *
On 10/26/2010 02:34 PM, Raymond Hettinger wrote:
FWIW, it wasn't that big (approx 2500 lines).
The argparse, difflib, doctest, pickletools, pydoc, tarfile modules
are about the same size and the decimal module is even larger.
Please don't split those.
Sense you mention this...
I've worked on
On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord
wrote:
> I find the big-ball-of-mud style development, where everything lives inside
> huge monolithic modules, very painful. I also think that it is an extremely
> bad example for new developers.
Gadzooks, Michael! Something else we agree on. 2000
On 26/10/2010 15:05, R. David Murray wrote:
On Tue, 26 Oct 2010 10:39:19 -0700, Raymond
Hettinger wrote:
If someone wants to reorganize code for clarity, I would prefer keeping
it within one file, bringing related functions together and using
comment lines to mark the major sections. ISTM, th
On Tue, 26 Oct 2010 12:34:30 -0700
Raymond Hettinger wrote:
>
> FWIW, it wasn't that big (approx 2500 lines).
> The argparse, difflib, doctest, pickletools, pydoc, tarfile modules
> are about the same size and the decimal module is even larger.
> Please don't split those.
I think it comes down
On Oct 26, 2010, at 12:18 PM, Benjamin Peterson wrote:
> 2010/10/26 Alexander Belopolsky :
>> On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
>> wrote:
>> ..
>>> Packaging is not always wrong. Maybe it was the right thing to do for
>>> unittest, maybe not.
>>
>> This is an example that I pe
2010/10/26 Alexander Belopolsky :
> On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
> wrote:
> ..
>> Packaging is not always wrong. Maybe it was the right thing to do for
>> unittest, maybe not.
>
> This is an example that I personally find ill-justified. Particularly
> annoying is the fact t
On Tue, 26 Oct 2010 10:39:19 -0700, Raymond Hettinger
wrote:
> If someone wants to reorganize code for clarity, I would prefer keeping
> it within one file, bringing related functions together and using
> comment lines to mark the major sections. ISTM, this is cleaner than
> introducing a new di
On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
wrote:
..
> Packaging is not always wrong. Maybe it was the right thing to do for
> unittest, maybe not.
This is an example that I personally find ill-justified. Particularly
annoying is the fact that opening __init__.py gives you a list of
rel
On Oct 26, 2010, at 9:31 AM, Guido van Rossum wrote:
> I would like Gregor Lingl's approval of turning turtle.py into a package. It
> might make some things harder for novices, e.g. trackebacks and just browsing
> the source code.
>
> Also many people don't expect to find any code in a file na
76 matches
Mail list logo
