Am 03.11.2010 03:35, schrieb Antoine Pitrou:
On Tue, 2 Nov 2010 19:57:48 -0700
Brett Cannon br...@python.org 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 03/11/2010 02:57, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 19:50, Michael Foordfuzzy...@voidspace.org.uk wrote:
On 02/11/2010 02:35, Brett Cannon wrote:
On Wed, Oct 27, 2010 at 03:42, Antoine Pitrousolip...@pitrou.netwrote:
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander
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
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On 03/11/2010 14:05, Nick Coghlan wrote:
On Wed, Nov 3, 2010 at 9:32 AM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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
raymond.hettin...@gmail.com wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of the
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
raymond.hettin...@gmail.com wrote:
Sounds like a decision to split a module into a
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: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
raymond.hettin...@gmail.com wrote:
Sounds like
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
raymond.hettin...@gmail.com wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of the individual file names becomes a
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 depending
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
raymond.hettin...@gmail.com wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of
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
On Tue, Nov 2, 2010 at 6:58 PM, Guido van Rossum gu...@python.org 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
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 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
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
raymond.hettin...@gmail.com wrote:
Sounds like a decision to split a module into a package is a big
commitment. Each of
On Wed, 03 Nov 2010 19:26:53 +
Michael Foord fuzzy...@voidspace.org.uk 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
On Wed, Nov 3, 2010 at 3:45 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 03 Nov 2010 19:26:53 +
Michael Foord fuzzy...@voidspace.org.uk wrote:
Antoine is firmly of the opinion that making TestCase instances
unpickleable is a feature...
Apparently you didn't really understand
Le mercredi 03 novembre 2010 à 15:48 -0400, Jesse Noller a écrit :
On Wed, Nov 3, 2010 at 3:45 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Wed, 03 Nov 2010 19:26:53 +
Michael Foord fuzzy...@voidspace.org.uk wrote:
Antoine is firmly of the opinion that making TestCase instances
On 03/11/2010 19:48, Jesse Noller wrote:
On Wed, Nov 3, 2010 at 3:45 PM, Antoine Pitrousolip...@pitrou.net wrote:
On Wed, 03 Nov 2010 19:26:53 +
Michael Foordfuzzy...@voidspace.org.uk wrote:
Antoine is firmly of the opinion that making TestCase instances
unpickleable is a feature...
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
On Wed, Nov 3, 2010 at 4:59 PM, Glyph Lefkowitz gl...@twistedmatrix.com wrote:
..
Maybe ship with a command that says hey, somewhere on sys.path,
there is a class with this name. Please run '$EDITOR file +line' (or the
current OS's equivalent) so I can look at the source code.
Well, we
On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon br...@python.org 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
On Tue, Nov 2, 2010 at 15:33, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon br...@python.org 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
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 case
On Nov 2, 2010, at 3:33 PM, Nick Coghlan wrote:
On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon br...@python.org 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
On Nov 02, 2010, at 03:43 PM, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 15:33, Nick Coghlan ncogh...@gmail.com wrote:
On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannon br...@python.org wrote:
So basically it seems like we have learned a lesson: we prefer to have
our code structured in files that
On Tue, Nov 2, 2010 at 3:47 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
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 now
On Tue, Nov 2, 2010 at 15:47, Raymond Hettinger
raymond.hettin...@gmail.com 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,
2010/11/2 Raymond Hettinger raymond.hettin...@gmail.com:
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
On 02/11/2010 22:43, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 15:33, Nick Coghlanncogh...@gmail.com wrote:
On Tue, Nov 2, 2010 at 12:35 PM, Brett Cannonbr...@python.org wrote:
So basically it seems like we have learned a lesson: we prefer to have
our code structured in files that match the
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 so
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 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 split a
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 structure now
On 02/11/2010 23:00, Brett Cannon wrote:
On Tue, Nov 2, 2010 at 15:47, Raymond Hettinger
raymond.hettin...@gmail.com 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.
On 02/11/2010 22:58, Guido van Rossum wrote:
On Tue, Nov 2, 2010 at 3:47 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Tue, Nov 2, 2010 at 4:39 PM, Michael Foord fuzzy...@voidspace.org.uk 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
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 a
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
raymond.hettin...@gmail.com 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
On Tue, Nov 2, 2010 at 5:03 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
Antoine Pitrou solip...@pitrou.net 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
On 12:47 am, ben+pyt...@benfinney.id.au wrote:
Antoine Pitrou solip...@pitrou.net 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
On Tue, Nov 2, 2010 at 8:47 PM, Ben Finney ben+pyt...@benfinney.id.au 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
On Tue, Nov 2, 2010 at 16:43, Guido van Rossum gu...@python.org wrote:
On Tue, Nov 2, 2010 at 4:39 PM, Michael Foord fuzzy...@voidspace.org.uk
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,
On 02/11/2010 02:35, Brett Cannon wrote:
On Wed, Oct 27, 2010 at 03:42, Antoine Pitrousolip...@pitrou.net wrote:
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolskyalexander.belopol...@gmail.com wrote:
While I appreciate your and Michael's eloquence, I don't really see
why five 400-line
On Tue, Nov 2, 2010 at 19:50, Michael Foord fuzzy...@voidspace.org.uk wrote:
On 02/11/2010 02:35, Brett Cannon wrote:
On Wed, Oct 27, 2010 at 03:42, Antoine Pitrousolip...@pitrou.net wrote:
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolskyalexander.belopol...@gmail.com wrote:
While
On Wed, 03 Nov 2010 11:47:55 +1100
Ben Finney ben+pyt...@benfinney.id.au 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
On Tue, 2 Nov 2010 19:57:48 -0700
Brett Cannon br...@python.org 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
On Tue, Nov 2, 2010 at 7:50 PM, Brett Cannon br...@python.org 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
On Wed, Oct 27, 2010 at 03:42, Antoine Pitrou solip...@pitrou.net wrote:
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
While I appreciate your and Michael's eloquence, I don't really see
why five 400-line modules are necessarily easier to
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 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
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
On Tue, 26 Oct 2010 22:06:37 -0400
Alexander Belopolsky alexander.belopol...@gmail.com 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
On Wed, Oct 27, 2010 at 2:33 PM, Ron Adam r...@ronadam.com 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
On 10/27/2010 08:51 AM, Nick Coghlan wrote:
On Wed, Oct 27, 2010 at 2:33 PM, Ron Adamr...@ronadam.com 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
On Tue, 26 Oct 2010 23:37:10 -0400, Barry Warsaw ba...@python.org 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
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 named
On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Tue, 26 Oct 2010 10:39:19 -0700, Raymond Hettinger
raymond.hettin...@gmail.com 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
2010/10/26 Alexander Belopolsky alexander.belopol...@gmail.com:
On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
raymond.hettin...@gmail.com 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
On Oct 26, 2010, at 12:18 PM, Benjamin Peterson wrote:
2010/10/26 Alexander Belopolsky alexander.belopol...@gmail.com:
On Tue, Oct 26, 2010 at 1:39 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
..
Packaging is not always wrong. Maybe it was the right thing to do for
unittest,
On Tue, 26 Oct 2010 12:34:30 -0700
Raymond Hettinger raymond.hettin...@gmail.com 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.
On 26/10/2010 15:05, R. David Murray wrote:
On Tue, 26 Oct 2010 10:39:19 -0700, Raymond
Hettingerraymond.hettin...@gmail.com 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
On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
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 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 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
On Tue, Oct 26, 2010 at 5:37 PM, Fred Drake fdr...@acm.org wrote:
On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord
fuzzy...@voidspace.org.uk 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
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
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
Hettingerraymond.hettin...@gmail.com wrote:
If someone wants to reorganize code for clarity, I would prefer keeping
it within one file,
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 to
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
76 matches
Mail list logo
