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.wink
Many programmers do know that sets are partially ordered by inclusion,
preordered by size, and (in Python)
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 python-check...@python.org:
Author: victor.stinner
Date: Fri Oct 29 02:38:58 2010
New Revision:
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.wink
Many programmers do know that
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 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 inexperienced
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 Tue, Nov 2, 2010 at 11:23 AM, Terry Reedy tjre...@udel.edu 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,
On Tue, Nov 2, 2010 at 12:37 PM, Jacob Kaplan-Moss ja...@jacobian.org 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. fdrake at acm.org
A storm broke loose in my mind. --Albert
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.
Augment
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...
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
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 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
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
On Tue, Nov 2, 2010 at 10:55 PM, Victor Stinner
victor.stin...@haypocalc.com 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
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
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 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
Raymond Hettinger raymond.hettin...@gmail.com 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
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
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
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 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
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 17:35, Guido van Rossum gu...@python.org 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
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
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 br...@python.org wrote:
On Tue, Nov 2, 2010 at 17:35,
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
Antoine Pitrou solip...@pitrou.net writes:
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
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
51 matches
Mail list logo
