On Tuesday 05 April 2005 15:53, Evan Jones wrote:
This functionality is provided by a flush() method on similar objects,
such as the zlib compression objects.
Or by close() on other objects (htmllib, HTMLParser, the SAX incremental
parser, etc.).
Too bad there's more than one way to do it.
On Tuesday 05 April 2005 06:47, Raymond Hettinger wrote:
Also, to help with institutional memory, I started a log of changes to
developer permissions. The goal is to remember who was given access, by
whom, and why (some folks are given access for a one-shot project for
example). The file
On Thursday 07 April 2005 10:58, Raymond Hettinger wrote:
Eric Price
Eric Price was an intern at CNRI; I think it's safe to remove him from the
list, as I've not seen anything from him in a *long* time.
-Fred
--
Fred L. Drake, Jr.fdrake at acm.org
On Friday 08 April 2005 09:53, Jeremy Hylton wrote:
Eric Price did some of the work on the decimal package, which was only
two summers ago. He wasn't an intern at CNRI.
A different Eric Price, then. Mea culpa.
(Or am I misremembering the intern's name? Hmm.)
-Fred
--
Fred L. Drake,
On Tuesday 11 July 2006 14:12, Alexander Belopolsky wrote:
Also __new__ and __init__ method docstrings is the natural place to
put set-up code.
Maybe, if all the tests required the same setup code. That's often not the
case.
-Fred
--
Fred L. Drake, Jr. fred at zope.com
Zope
On Tuesday 11 July 2006 14:37, Alexander Belopolsky wrote:
That's true, but you cannot test an object method without creating the
object first.
True. How the object is created can vary; if the creation affects the
expected behavior in any way, you'll need be careful about how the
I vaguely recall some discussion about removing hotshot in favor of a
better maintained profiler that has better thread support as well.
Does anyone remember the decision? I don't see anything about it in
PEP 4 or the Python 3000 PEPs I checked.
-Fred
--
Fred Drake fdrake
limited. :-)
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
attribute(self):
pass
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
that hard to achieve, at least for a known
property type. To support descriptors of completely different types,
the syntax from the first example may be required unless some other
crutch is added.
-Fred
--
Fred Drake fdrake at acm.org
___
Python
On Nov 1, 2007, at 9:18 PM, Fred Drake wrote:
Thanks! Of all the proposals that have been presented, I still like
that the best.
I've attached a quick hack of an implementation, just to play with it
and see how it feels. Here's an example use:
from property import property
class Base
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
no value to embedding the logic of auto-
detection into the codec. A function somewhere in the xml package is
all that's warranted.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
-encoding issue applies as well.
Simply, it's sometimes desired to know the encoding for purposes that
don't require immediate decoding. A function would be quite handing
in these cases.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev
the XML
specification should be in the xml package (somewhere). Determining
that the file is an XML file is separate.
I doubt this really makes sense in os.path.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev
on.
+1 for __builtin_namespace__.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
something reasonable in
spite of our yammering.
+1 for a module named builtin, or something similarly obscure.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
it as interesting in it's own right.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev
the promise has been there for so long.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive
to
duplicate that.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
of names); a single capable interface should be provided.
But that's a separate discussion.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Jan 8, 2008, at 7:53 PM, Neal Becker wrote:
Note also that mercurial has demandimport
http://www.selenic.com/mercurial/wiki/
Let's not forget zope.deferredimport:
http://pypi.python.org/pypi/zope.deferredimport
-Fred
--
Fred Drake fdrake at acm.org
posted may be somewhat better for most users, though.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
/ in
that case. Anything beyond that is grass-roots, and still pretty
obscure.
That said, I think extending usage of ~/.local/ is fine for things
that aren't supposed to be edited or directly used by users. ~/.local/
bin/ seems suspect.
-Fred
--
Fred Drake fdrake at acm.org
insane.
This kind of thing would be less of a problem if the standard library
were smaller, and the email package only available separately. It's
also why some of us want a smaller standard library.
-Fred
--
Fred Drake fdrake at acm.org
uploaded to python.org.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
for
posterity. :)
PEP: -1
tracker: +1
I agree with Jeroen completely on this. Using a PEP for this is just
plain silly.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Mar 2, 2008, at 7:43 PM, Fred Drake wrote:
2.4.5 won't build for me from the svn checkout on Mac OS X 10.5.2:
Neither does 2.3.7 now that I've tried that:
gcc -u __dummy -u _PyMac_Error -framework System -framework
CoreServices -framework Foundation -o python.exe
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
detailed a level.
Common sense, knowledge of the interpreter, and experience are often
more valuable the easily-outdated documentation.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http
that supported that performance assertion were made
by putting the standard library in a single ZIP, and using that.
I don't have measurements handy, but I recall being told by someone
who did that using a *lot* of separate ZIP files wasn't as effective.
-Fred
--
Fred Drake fdrake
in favor of removing the bdist_* from the standard
library, and allowing 3rd-party tools to implement whatever they need
for the distros. But I don't think what you're presenting there
supports it.
-Fred
--
Fred Drake fdrake at acm.org
to not wanting to build a separate ZIP for
(potentially) every script.
In practice, I suspect it's a lot better than this.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
-agnostic way if we want
to use the standard library version of that module with newer Pythons?
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
if the RPM packagers (or others) use that information.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options
documented, and many applications actually use it, I think it's worth
explaining that the None values can reasonably be expected, and what
they indicate.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http
On Aug 19, 2009, at 6:01 PM, Peter Moody wrote:
just to double check, it's fine for IPNetwork to remain hashable if
set_prefix() actually returned a new object, correct?
The name would be confusing, though. Perhaps using_prefix() would be
more clear.
-Fred
--
Fred Drake fdrake
On Thu, Dec 29, 2011 at 8:19 AM, Christian Heimes li...@cheimes.de wrote:
Persistence layers like ZODB and cross interpreter communication
channels used by multiprocessing may (!) rely on the fact that the hash
of a string is fixed.
ZODB does not rely on a fixed hash function for strings; for
On Fri, Jan 20, 2012 at 5:49 AM, Mark Shannon m...@hotpy.org wrote:
So, don't be afraid to change that hash function :)
Definitely.
The hash function *has* been changed in the past, and a lot of developers
were schooled in not relying on the iteration order. That's a good thing,
as those
On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky eli...@gmail.com wrote:
Besides, in
http://mail.python.org/pipermail/python-dev/2011-December/114812.html
Stefan Behnel said [...] Today, ET is *only* being maintained in the
stdlib by Florent Xicluna [...]. Is this not true?
I don't know. I
On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky eli...@gmail.com wrote:
The initial proposal of changing *the stdlib
import facade* for xml.etree.ElementTree to use the C accelerator
(_elementtree) by default.
I guess this is one source of confusion: what are you referring to an
an import
On Mon, Mar 12, 2012 at 11:43 AM, PJ Eby p...@telecommunity.com wrote:
I wish Gmail defaulted to reply-all in the edit box.
There's a lab for that. :-)
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
A person who won't read has no advantage over one who can't read.
--Samuel Langhorne
On Wed, Mar 21, 2012 at 2:46 PM, Guido van Rossum gu...@python.org wrote:
That doesn't mean the web designer shouldn't think at least twice
before specifying a smaller font than the browser default.
Yet 90% of designers (or more) insist on making text insanely small, commonly
specifying the
On Wed, Mar 21, 2012 at 3:13 PM, Ned Batchelder n...@nedbatchelder.com wrote:
There are bad designers, or more to the point, designers who favor the
overall look of the page at the expense of the utility of the page. That
doesn't mean all designers are bad, or that design is bad. Don't throw
On Tue, Apr 24, 2012 at 2:34 PM, Benjamin Peterson benja...@python.org wrote:
There is in the since that you can follow the HTML5 algorithm, which
can parse any junk you throw at it.
This whole can of worms is why I gave up on HTML years ago (well, one
reason among many).
There are markup
, not recommended for new test code.
+1 !
This kind of information, once known, should be included in all
maintained versions of the documentation so that users can build good
coding habits, or have more time to adjust existing code.
-Fred
--
Fred Drake fdrake at acm.org
that my preferred approach would be that there's no default at all;
the location would have to be specified explicitly. Whether on the
command line or in the distutils configuration doesn't matter, but
explicitness should be required.
-Fred
--
Fred Drake fdrake at acm.org
On May 10, 2008, at 11:49 PM, Guido van Rossum wrote:
Works for me. The other thing I always use from cgi is escape() --
will that be available somewhere else too?
xml.sax.saxutils.escape() would be an appropriate replacement, though
the location is a little funky.
-Fred
--
Fred Drake
, but I think Brett's
suggestion was really about issuing warnings when the stub functions
were called. For classes, I guess this could be handled using the
__init__ methods, but I'm not sure I like that, or that it will be
easy to get exactly the right behavior in all cases.
-Fred
--
Fred
in Subversion. :-)
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
subclassing.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
are a different
beast.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
the test as well.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
in this case.
I think it should be fixed for 2.5 as well, myself.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org
.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
version.
I think this is worth considering. I vaguely recall that the bsddb
module was maintained before it was incorporated into the core Python
release.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev
difficult.
It's also entirely possible that the API isn't interesting if you
don't support existing databases, for many applications.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
Python 2.5 isn't officially supported (whatever that means).
I think current versions of Zope 2 work with Python 2.5 as well.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Aug 18, 2008, at 2:33 PM, Benjamin Peterson wrote:
Why not name it testutils?
Heh. And what's the difference between *utils, *tools, and *lib?
They all sound the same to me. :-(
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev
On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote:
If it's about silencing warnings, then how about putting it in the
warnings
module?
That sounds good to me, and would be very reasonable. This would make
a nice context manager.
-Fred
--
Fred Drake fdrake at acm.org
installation packages of whatever form), then python.org is the right
place for it. Presumably //someone// is creating those now, right?
If they could upload them to python.org and update the pages
accordingly, that should be no worse than anything they're doing now.
-Fred
--
Fred Drake
.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
to add
the /opt tree to my environment in order to get compiles/tools to play
nice.
I'd go so far as to say that any reliance on LD_LIBRARY_PATH is a bad
idea, since it's horribly fragile. But I do link in the readline from
macports.
-Fred
--
Fred Drake fdrake at acm.org
years ago.)
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
. :-)
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
it didn't really make sense
to have both .tgz and .tar.bz2, and the software to handle .tar.bz2 is
widely deployed.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
On Oct 2, 2008, at 9:21 AM, Georg Brandl wrote:
I intend to set things up so that the docs at docs.python.org are
continually
rebuilt, just like the /dev docs were until now.
Wonderful! This should help avoid repeat reports of simple typos.
At one point, we started to separate the
On Oct 2, 2008, at 1:17 PM, Georg Brandl wrote:
All Sphinx-generated pages currently have a last update on: in the
footer.
Do you think that suffices for this purpose?
Yes, I do.
-Fred
--
Fred L. Drake, Jr. fdrake at acm.org
___
Python-Dev
On Oct 7, 2008, at 4:06 PM, Martin v. Löwis wrote:
b) I would propose that the notion of a default encoding is entirely
eliminated from Python, along with sys.(get|set)defaultencoding
+1
-Fred
--
Fred Drake fdrake at acm.org
___
Python
.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
that the type's C code
demands.
It's good to move work into __init__ where reasonable, so that it can
be avoided if a subclass wants it done in a completely different way,
but new can't work that way.
-Fred
--
Fred Drake fdrake at acm.org
On Thu, Dec 4, 2008 at 2:36 AM, Martin v. Löwis [EMAIL PROTECTED] wrote:
I would like to merge mailing lists, now that the design and first
implementation of Python 3000 is complete. In particular, I would
+1
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which
to be compatible with
(has been tested with). I'd love for this to be available, and
would be more proactive about testing software I've been involved in
releasing against more Python versions.
-Fred
--
Fred Drake fdrake at acm.org
___
Python
On Dec 5, 2008, at 2:27 AM, Martin v. Löwis wrote:
There is. There have been the following trove classifiers defined for
a few weeks now:
Wonderful! Thanks for clueing me in. I'll update my projects to use
those in future releases.
-Fred
--
Fred Drake fdrake at acm.org
by another clue.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
it
manually.
I think this is a significant issue, since editing that property is
about as error-prone as it can be. I've not really looked at the code
in svnmerge.py, so I'm not sure how hard it would be to fix.
-Fred
--
Fred Drake fdrake at acm.org
.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
:
If this is sufficient to drive a release, then whatever test there is
should be part of the release as well.
-Fred
--
Fred Drake fdrake at acm.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Tue, Jun 22, 2010 at 2:21 AM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
I had thought there was a conscious decision to not change any existing
classes from old-style to new-style.
I thought so as well. Changing any class from old-style to new-style
risks breaking applications in
On Tue, Jun 22, 2010 at 12:56 PM, Benjamin Peterson benja...@python.org wrote:
Never have externally maintained packages.
Seriously! I concur with this.
Fortunately, it's not a real problem in this case.
There's the (maintained) simplejson package, and the unmaintained json
package. And
On Tue, Jun 22, 2010 at 7:17 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
Benjamin fixed the UserDict and ABC problem earlier today in r82155.
It is now the same as it was in Py2.6.
Thanks, Benjamin!
-Fred
--
Fred L. Drake, Jr.fdrake at gmail.com
A storm broke loose in my
On Thu, Jun 24, 2010 at 4:55 PM, Barry Warsaw ba...@python.org wrote:
Which is probably another reason not to use foo.so.X.Y for Python extension
modules.
Clearly, foo.so.3.2 is the man page for the foo.so.3 system call.
The ABI ident definitely has to be elsewhere.
-Fred
--
Fred L.
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou solip...@pitrou.net wrote:
The two sets of repositories use different conversion tools and rules.
They have nothing in common (different changeset IDs, different
metadata, different branch/clone layout).
I'd love to see a more detailed description
On Wed, Jul 7, 2010 at 2:27 PM, Georg Brandl g.bra...@gmx.net wrote:
I know, and this is what I originally intended for Sphinx. However, the calls
for automatic doc generation are very loud, and it's understandable that most
project can't afford writing their documentation twice.
The ability
On Wed, Jul 7, 2010 at 4:58 PM, Georg Brandl g.bra...@gmx.net wrote:
Let's say we were okay with giving up single-source docs,
It's not clear that this is a goal.
one potential
problem is that autodoc needs to import the modules in question, which
can become a problem, on one hand for
On Thu, Jul 8, 2010 at 5:21 PM, Georg Brandl g.bra...@gmx.net wrote:
Problem is, in the case of help() we have no way of knowing whether the
given __doc__ string is supposed to be (mini)reST. Of course, reverting
to showing the plain content on parsing errors is one possibility, but
I can
On Thu, Jul 8, 2010 at 5:42 PM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
I am against mark-up in doc-strings, but this problem can be easily
solved by placing a magic character at __doc__[0] to indicate that the
rest is (mini)reST.
Or __docformat__ can be set appropriately.
On Fri, Jul 9, 2010 at 2:51 AM, Georg Brandl g.bra...@gmx.net wrote:
Yes, but[tm] it is not always easy to find the correct module to look for
__docformat__ when given an object.
True. That PEP was written before decorators were common, in
particular. That's changed the landscape in
On Fri, Jul 9, 2010 at 2:04 PM, Bill Janssen jans...@parc.com wrote:
I'd suggest that
HTTP is a better (more likely to succeed) default choice in this century.
FTP access also more often reflected the actual file hierarchy of the
machine, so trying that path as a system path is more likely to
On Fri, Jul 9, 2010 at 3:35 PM, MRAB pyt...@mrabarnett.plus.com wrote:
I concentrated my efforts on the matching speed because regexes tend to
be compiled only once, and are cached anyway, so I don't think it's as
important.
I think most here will agree with that, but it might be good to keep
On Sat, Jul 10, 2010 at 11:56 PM, Senthil Kumaran orsent...@gmail.com wrote:
I see the reason. But I doubt if this is a reliable approach. Also
when the scheme begins with file:// it should not be confused with
ftp, so I think, that portion of code in urllib which work that way
should be
On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytman p...@phd.pp.ru wrote:
Doesn't absolute import help?
Not when both modules are at the top level; both acceptably provide
the same name. The let's-play-with-it script just wasn't *intended*
to be a module.
-Fred
--
Fred L. Drake, Jr.
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
I'm sure Brett will love this idea, but if it was impossible to reimport the
script being executed as __main__ with a different name it would solve these
problems.
Indeed! And I'd be quite content with such a
I wrote:
Indeed! And I'd be quite content with such a solution, since I
consider scripts and modules to be distinct.
On Mon, Jul 12, 2010 at 5:59 PM, Antoine Pitrou solip...@pitrou.net wrote:
Except that modules can often be executed as scripts...
Rest assured, I'm well aware of the history,
On Tue, Jul 13, 2010 at 9:00 AM, Nick Coghlan ncogh...@gmail.com wrote:
Making sure both __main__ and the corresponding importable name refers
to the same module object seems reasonable.
One detail that may not have been obvious when I described the
persistent object problem; when class
On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan ncogh...@gmail.com wrote:
Fred's point about the practice of changing __name__ in the main
module corrupting generated pickles is one I hadn't thought of before
though.
Not sure about changing __name__ anywhere... I don't do that.
When an
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano st...@pearwood.info wrote:
It refers to the guideline that you shouldn't have a single function
with two (or more) different behaviour and an argument that does
nothing but select between them.
In particular, when that argument is almost never
On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam r...@ronadam.com wrote:
It doesn't fall under the single constant rule if done this way.
If the value for 'allow' were almost always given as a constant, this
would be an argument for three functions instead of one.
The guideline has little to do with
1 - 100 of 230 matches
Mail list logo
