On Mon, Dec 1, 2014 at 12:37 PM, Jim J. Jewett wrote:
> I think even the proponents concede that git isn't better enough
> to justify a switch in repositories.
There are also many who find the Bitbucket tools more usable than the
Github tools.
I'm not aware of any functional differences (though
On Thu, Sep 7, 2017 at 4:52 PM, Terry Reedy wrote:
> Environmental variables tend to be a pain on Windows and nigh unusable by
> beginners. Leaving that aside, I see these problems with trying to use one
> for IDLE's *current* debugger.
>
> pdb is universal, in the sense of working with any pytho
On Wed, Sep 13, 2017 at 12:35 PM, Ned Deily wrote:
> Lots of releases coming up soon!
There's a "Python Release Schedule" calendar on Google Calendar that
used to be maintained, but that appears to have been dropped, though I
found it useful.
Is there any sort of calendar feed available with thi
On Wed, Oct 25, 2017 at 10:37 PM, Wes Turner wrote:
> What would you call the str argument? Does it accept strptime args or only
> ISO8601?
There'd be no reason to accept a format. That wouldn't make sense. A
.fromiso(s:str) should only accept an ISO 8601 string, though I'd
advocate tolerating
On Tue, Dec 29, 2015 at 1:27 PM, Facundo Batista
wrote:
> I was reading PEP 257 and it says that all public methods from a class
> (including __init__) should have a docstring.
>
> Why __init__?
>
> It's behaviour is well defined (inits the instance), and the
> initialization parameters should be
On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote:
> - a single os.fspath() with an allow_bytes parameter
> (mostly True in os and os.path, mostly False everywhere
> else)
-0
> - a str-only os.fspathname() and a str/bytes os.fspath()
+1 on using separate functions.
> I'm partial to the
On Wed, Apr 13, 2016 at 12:27 PM, Paul Moore wrote:
> -1 on fssyspath - the "system" representation is bytes on POSIX, but
> not on Windows. Let's be explicit and go with fsbytespath().
Depends on the semantics; if we're expecting it to return
str-or-bytes, os.fssyspath() seems fine. If only ret
On Wed, Apr 13, 2016 at 3:24 PM, Chris Angelico wrote:
> Is that the intention, or should the exception catching be narrower? I
> know it's clunky to write it in Python, but AIUI it's less so in C:
>
> try:
> callme = path.__fspath__
> except AttributeError:
> pass
> else:
> path = cal
On Sun, May 29, 2016 at 4:53 PM, Guido van Rossum wrote:
> I am currently in favor of Distinct Type [Alias].
I actually like distinguished type better:
A = typing.distinguish("A", int)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
On Fri, Mar 28, 2014 at 5:19 PM, Greg Ewing wrote:
> ISO 8601 doesn't seem to define a representation for
> negative durations, though, so it wouldn't solve the
> original problem.
Aside from the horribleness of the ISO 8601 notation for a duration, it's
best not to confuse the notions of duratio
On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin wrote:
> While it seems ConfigParser doesn't do any escaping as all, I'm
> thinking it should at least raise some exception when such a value is
> trying to be set.
>
> I'd expect writing something and then reading it back via the same
> configparse
On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy wrote:
> I leave it to someone to carefully read the doc, but a brief glance
> indicates "There are nearly as many INI format variants as there are
> applications using it. configparser goes a long way to provide support for
> the largest sensible set o
On Fri, Apr 25, 2014 at 3:12 PM, Ethan Furman wrote:
> Perhaps an enhancement request then: a way to provide a regex that keys
> must match, with an exception raised when a key doesn't. That way the
> safety belt could be used when desired.
You can subclass the parser class you're using and ove
On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano wrote:
> I think that a line beginning with "#spam" is ambiguous, it isn't clear
> if it is intended as a comment "spam" or a key starting with #, so by
> the Zen, configparser should refuse to guess.
Seriously?
Perhaps the second paragraph here c
On Sat, Apr 26, 2014 at 7:23 AM, Steven D'Aprano wrote:
> But the entry in question wasn't a line, it was a key=value pair in a
> dict. Here's that line again:
>
> cp.read_dict({'DEFAULT': {';foo': 'bar'}})
>
> or it could have been:
>
> cp['DEFAULT'][';foo'] = 'bar'
>
> Either way, if there's no
On Thu, Jul 5, 2018 at 9:02 PM Alexander Belopolsky
wrote:
> What happened to the "consenting adults" philosophy?
Just anecdotally, I've run into a number of professionals recently
who've come out of Java environments who really dislike the
"consenting adults" approach. While they value much tha
On Tue, Feb 26, 2019 at 10:20 PM Terry Reedy wrote:
> To me, total_x implies that there is a summation of multiple timedeltas,
> and there is not.
Do you believe this is a particularly dominant perception? I don't,
but specific backgrounds probably play into this heavily.
I'd expect to total a
On Mon, Jul 8, 2019 at 3:59 PM Barry Warsaw wrote:
> I’m not a super active moderator, but I do have to say that it’s so much
> easier to clear the queue now that the list is on Mailman 3. That said,
> it still takes active participation in order to review held messages.
...
> Volunteers are welc
On Tue, Nov 24, 2020 at 10:59 AM Stéfane Fermigier wrote:
> I've run a quick search on GitHub and the only meaningful reference I could
> find is the Grail browser (which had its last release, AFAICT, in 1999).
>
> http://grail.sourceforge.net/
Oh, the memories! Looking at docs, I can vaguely r
On Thu, Feb 25, 2021 at 5:35 AM Wes Turner wrote:
> The challenge with version conflicts is often less that you need to go
> update the constraints (which has little to do with sysadmin'ing, TBH) and
> more that you have insufficient *integration tests* and you're relying upon
> something else ru
On Wed, Apr 14, 2021 at 4:19 PM Paul Moore wrote:
> PS I see Barry plans on rejecting the PEP, which I think is probably
> the right decision, given the way this thread has developed.
>
Barry makes good plans.
Putting the version into the sources is a bit of an anti-pattern. IMO.
-Fred
--
On Wed, Apr 14, 2021 at 7:04 PM Jim J. Jewett wrote:
> I don't have a deep answer, but I do think __version__ should be specified
> (or at least mentioned) at
> https://docs.python.org/3/reference/datamodel.html
Given the intent to reject PEP 394, I can't imagine any good would come of
that.
D
I found this article about what's up with FreeNode:
https://arstechnica.com/gadgets/2021/05/freenode-irc-has-been-taken-over-by-the-crown-prince-of-korea/
-Fred
On Wed, May 26, 2021 at 11:48 AM Guido van Rossum wrote:
> Could someone provide more background on this event? Are there wars goin
On Sun, Feb 17, 2013 at 1:45 PM, Daniel Holth wrote:
> Not likely to matter for a while as the current md v1 tools don't understand
> this new obsolescence rule :-)
Using a separate file for post-obsolescence-rule metadata versions would
allow coexistance, which would likely improve adoption.
On Sun, Feb 17, 2013 at 4:21 PM, Nick Coghlan wrote:
> As Daniel pointed out, easy_install and pip also don't follow this rule yet,
> so it won't really have any impact if we never get to metadata 3.0.
Actually, my point was that using a separate filename for version 2.0 would
allow provision of
On Tue, Feb 19, 2013 at 6:19 PM, Donald Stufft wrote:
> Let's not add anything to the stdlib till it has real world usage. Doing
> otherwise is putting the cart before the horse.
I'd posit that anything successful will no longer need to be added to
the standard
library, to boot. Packaging hasn't
On Wed, Feb 20, 2013 at 5:45 PM, R. David Murray wrote:
> (Wikipedia says: "Programs for reading documents may not be required to
> read the external subset.", which would seem to confirm that.)
Validating parsers are required to read the external subset; this doesn't
apply to the parsers distrib
On Wed, Feb 20, 2013 at 7:38 PM, Nick Coghlan wrote:
> Christian's suggested approach sounds sane to me:
Definitely. A strong +1 from me, FWIW these days.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Py
On Wed, Feb 27, 2013 at 8:30 AM, Antoine Pitrou wrote:
> I don't think extra-strong typing of constants is really useful in
> practice; it smells a bit like private methods to me.
I think checking that a value comes from a particular enum *is* a degree of
hand-holding. For libraries or framework
On Thu, Mar 14, 2013 at 9:33 PM, Terry Reedy wrote:
> Is the code change an all-version bugfix or a default-only enhancement?
> I can see it both ways, but a decision is required to act.
This is actually backward-incompatible, so should not be considered a
simple bugfix. If determined to be desi
On Tue, May 28, 2013 at 9:07 AM, Nick Coghlan wrote:
> Unfortunately, I don't know any other short word for "things with main
> functions that we ship to end users" :)
We used to call such things "programs", but that term may no longer be
in popular parlance. :-) Or is it just too long?
-Fr
On Thu, Aug 1, 2013 at 9:10 AM, Antoine Pitrou wrote:
> Something magic about 99?
I'm guessing it's short enough you can say you tried, but long
enough to annoy traditionalists anyway.
I'm annoyed already. :-)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Ein
On Tue, Aug 6, 2013 at 3:51 PM, Antoine Pitrou wrote:
> I definitely agree, but this is part of our failure too.
I'd say this is strictly our failure, not the students'. This isn't
really a new problem, I don't think, though the shape of this collection
of patches makes it obvious.
I haven't be
On Thu, Sep 5, 2013 at 4:29 PM, Oleg Broytman wrote:
> I have seen exactly 0 (zero) sites that support Persona. Can you
> point me?
We have an internal app that uses Persona, but we did that mostly to
play with it.
I've not run across any sites that use Persona in the wild, either.
-Fred
--
On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald wrote:
> It would be great if the docstring contained a link to the online
> documentation.
The docstring itself, or the presentation generated by help() ?
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
__
On Mon, Sep 23, 2013 at 3:01 PM, Terry Reedy wrote:
> 'Return' versus 'Returns', exact uppercase word match, is a little over 3 to
> 1. I am sure I have seen 'Return' and similiar directive forms ('Print',
> 'Store', 'Compare', etc) recommended as current doc style, as prefered by
> the current do
On Wed, Jun 8, 2016 at 5:33 PM, Ryan Gonzalez wrote:
> What about something like "unpythonic" or similar?
Or perhaps... antipythy?
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
Pyt
On Thu, Jun 9, 2016 at 6:16 PM, Ethan Furman wrote:
> That's awfully close to antipathy [1], my path module on PyPI.
Good point. Increasing confusion would not help.
> Besides, I liked the suggestion from the -ideas list: Python 2therescue. ;)
Nice; I like that too. :-)
-Fred
--
Fred L.
On Mon, Oct 10, 2016 at 4:17 AM, Larry Hastings wrote:
> Given that the weakref doesn't have a reference to the object--merely a weak
> reference, different thing--whose reference is it borrowing?
As others have said, it doesn't really matter who's reference it was;
just that there was another at
On Fri, Sep 4, 2020 at 11:02 AM Antoine Pitrou wrote:
> While I agree with the general suggestion of deprecating distutils as a
> publicly-visible module (in favour of encouraging users to rely on
> setuptools), it seems to me that the argument of facilitating the
> development of third-party buil
asurements 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.
#x27;m actually 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
_
usually comes down 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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.o
ce we're using Python
2.4). How should we write that in a version-agnostic way if we want
to use the standard library version of that module with newer Pythons?
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http
;t know if the RPM packagers (or others) use that information.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-d
tself
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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.
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
e in this way having unexpected side effects in
some library.
-Fred
--
Fred Drake
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/pytho
tive.
The overload problem is one we *don't* have for developer
documentation; the difficulty is in discovering what exists at all.
+1 on moving the developer docs to subversion
+0 on exposing them online
-0 on adding another domain name
-Fred
--
Fred Drake
On Tue, Sep 29, 2009 at 9:30 PM, Barry Warsaw wrote:
> Maybe. I haven't been following this entire thread, but I don't see much
> point in making it easy to go from getopt to argparse.
I'm with you on this; specific getopt uses are more likely to be
switched to opt/argparse than to shift gradual
On Mon, Oct 5, 2009 at 4:58 AM, Fredrik Lundh wrote:
> Oh, it was just yet another Zope developer behaving like an ass. Why
> am I not surprised?
Actually, most of us Zope developers prefer sdist packages, not eggs.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is
On Mon, Oct 5, 2009 at 1:54 PM, Guido van Rossum wrote:
> User ratings and comments are the
> future for "app store" style sites such as PyPI
Interestingly, I consider sites like PyPI as developer resources
rather than the more end-user-centric "App Store" sites.
While I don't consider it bad to
On Mon, Oct 5, 2009 at 4:24 PM, Nick Coghlan wrote:
> When it comes to comments and recommendations for selecting software
> packages, developers *are* the end users :)
Yes, most certainly. But developers as consumers are very different
from application users as consumers, which is what I was ge
On Wed, Oct 7, 2009 at 10:34 AM, Swapnil Talekar wrote:
> 1) Is the byte-compiled .pyc file and optimized .pyo file
> platform-independent?(including python versions 3.x)
Yes.
> If yes, is it
> guaranteed to stay that way in future?
Yes.
> 2) If the the generation of .pyc file fails (say, due
On Sat, Oct 10, 2009 at 8:02 PM, Greg Ewing wrote:
> That's no reason to squander it, though. Quoting the entire
> message every time makes the size of the thread grow as
> O(n**2), and makes things harder to read as well. That's
> just senseless.
Most importantly, insufficient trimming makes man
On Thu, Oct 15, 2009 at 11:06 AM, Antoine Pitrou wrote:
> We have trouble staying
> compatible with lots of build options (see how --without-threads is little
> exercised).
I don't know if folks deploying on embedded platforms are using these
options (directly or indirectly), but expect that's th
On Wed, Nov 4, 2009 at 5:16 PM, David Lyon wrote:
> I would even go so far as to use the python 3 as a carrot for
> the new work.
The packaging story is in such bad shape that it needs the work
regardless, and keeping it to Python 3 would significantly reduce the
set of potential volunteers.
> i
On Wed, Nov 11, 2009 at 12:59 PM, Echo wrote:
> We just need a PyEmacs. Written in python, extensible in elist and
> python. Nice and simple ;-D
I'd even give up the elisp support if I could have Python in my Emacs.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is w
On Wed, Dec 9, 2009 at 11:29 AM, Benjamin Peterson wrote:
> Could you mention what specific changes are causing problems?
I'd be glad to head Lennart confirm this, but I suspect this is
primarily changes in exception messages; 2.7 in many places provides
better messages.
I found some of this wit
On Wed, Dec 9, 2009 at 12:23 PM, Lennart Regebro wrote:
> You remember which one?
Sorry, that was several months back.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Python-Dev mailing list
P
On Sun, Dec 27, 2009 at 8:28 PM, Arfrever Frehtes Taifersar Arahesis
wrote:
> 'Requires-Python: 3*' (or '3.*') would be better than 'Requires-Python: >=3,
> <4'.
Maybe.
MRAB wrote:
> Requires-Python: 3 ~ 4
Ugh. -1
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is
The traceback support from the zc.twist package might be interesting
as well; not sure how well that's isolated from the rest of the
package though:
http://pypi.python.org/pypi/zc.twist/
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
__
On Thu, Feb 18, 2010 at 7:41 AM, anatoly techtonik wrote:
> It will still require workarounds and bridges to make API in user
> scripts convenient, i.e.
I'm not entirely sure what you intended the "It" to refer to here.
My take on this is that bundling a version of pytz in the standard
library w
On Fri, Feb 26, 2010 at 3:59 PM, Lennart Regebro wrote:
> I'm worrying that adding such a
> thing to stdlib will do so in an unfinished state, and we'll just en
> up with yet another state of semi-brokenness.
I valid worry, and compelling.
As I've alluded to before, leaving it out and allowing a
Regarding: http://bugs.python.org/issue7540
The change made in response to this issue report breaks existing uses
of Python 2.6.4.
The mechanize library frequently re-initializes the data in the
request without re-using the request. This worked fine in the past,
and does not trigger the problem
On Thu, Mar 4, 2010 at 3:20 PM, Brett Cannon wrote:
> 1) I miss not having the affected files listed in the subject line.
> 2) The To field is set to h...@python.org which gets rejected as an invalid
> email address if you reply. Would be better to set it to python-checkins so
> that the habitual
On Wed, Mar 10, 2010 at 7:46 AM, Nick Coghlan wrote:
> All of this discussion about the class names is ignoring the main
> benefit of using the string names:
Another benefit of strings is that data-driven argparse configuration
will usually be slightly simpler.
Some of us find things like that u
On Thu, Mar 25, 2010 at 2:16 PM, Larry Hastings wrote:
> My understanding is that requiring a recompile is okay
This has always been a point of contention. I'm not even sure what
the current official position is.
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is wri
On Tue, Apr 27, 2010 at 4:38 PM, "Martin v. Löwis" wrote:
> Done!
Thanks, Martin!
-Fred
--
Fred L. Drake, Jr.
"Chaos is the score upon which reality is written." --Henry Miller
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On Mon, May 3, 2010 at 11:30 AM, Barry Warsaw wrote:
> but in fact, the scripts make Resolution optional (it's kind of a pain to make
> it required just for Standards Track PEPs - contributions welcome).
It will also be a pain to retroactively update older PEPs with the
newly-required metadata; l
On Wed, Jun 9, 2010 at 12:30 AM, Senthil Kumaran wrote:
> it would still be a good idea to
> introduce some of them in minor releases in 2.7. I know, this
> deviating from the process, but it could be an option considering that
> 2.7 is the last of 2.x release.
I disagree.
If there are going to
On Tue, Jun 22, 2010 at 2:21 AM, Raymond Hettinger
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 obscure & mysterious ways
On Tue, Jun 22, 2010 at 12:56 PM, Benjamin Peterson 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 simplejson works with o
On Tue, Jun 22, 2010 at 7:17 PM, Raymond Hettinger
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.
"A storm broke loose in my mind." --Albert Einstein
_
On Thu, Jun 24, 2010 at 4:55 PM, Barry Warsaw 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. Drake, Jr.
"A s
On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou 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 of this, includi
On Wed, Jul 7, 2010 at 2:27 PM, Georg Brandl 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 to provide ext
On Wed, Jul 7, 2010 at 4:58 PM, Georg Brandl 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 platform-specific m
On Thu, Jul 8, 2010 at 5:21 PM, Georg Brandl 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 still imagine in
On Thu, Jul 8, 2010 at 5:42 PM, Alexander Belopolsky
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. See:
http://www.python
On Fri, Jul 9, 2010 at 2:51 AM, Georg Brandl 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 substantial ways.
It ma
On Fri, Jul 9, 2010 at 2:04 PM, Bill Janssen 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 work
that I'd ex
On Fri, Jul 9, 2010 at 3:35 PM, MRAB 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
in mind that the sre imp
On Sat, Jul 10, 2010 at 11:56 PM, Senthil Kumaran 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 removed.
I'm not tr
On Mon, Jul 12, 2010 at 4:12 PM, Oleg Broytman 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.
"A storm broke loo
On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord
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 solution, since I
consider
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 wrote:
> Except that modules can often be executed as scripts...
Rest assured, I'm well aware of the history, and don't seriou
On Tue, Jul 13, 2010 at 9:00 AM, Nick Coghlan 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 references are pickled,
On Tue, Jul 13, 2010 at 5:02 PM, Nick Coghlan 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 "application" is defined
On Tue, Jul 20, 2010 at 9:09 AM, Steven D'Aprano 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 given a variable
v
On Tue, Jul 20, 2010 at 12:47 PM, Ron Adam 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 the type of the
Switching to "python -m" is generally good where it applies (as in this case).
The original intent for :option: and :program: were in their use as
references rather than in sample command lines.
Georg should be the final arbiter, but I'd be in favor of ``...`` for
command lines.
_
On Tue, Aug 3, 2010 at 1:01 AM, Ray Allen wrote:
> Is the tracker OK now?
It's working for me.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python
2010/8/4 Łukasz Langa :
> 1. The patch makes KeyError behave analogically to IOError so that the first
> arg is now a message and the second is the actual key.
I agree with Antoine; there's no point to this.
> 2. Some people suggest adding e.key to KeyError. I like the idea but in my
> opinion cu
On Wed, Aug 4, 2010 at 5:57 PM, Nick Coghlan wrote:
> and use a default message of
> "'Key not found: %r' % key" if the key argument is supplied without an
> explicit message
I suspect you meant a default message of
'Key not found: %r' % (key,)
since `key` might be a 1-tuple. :-)
-Fred
2010/8/4 Łukasz Langa :
> Shall we do an e.index for IndexErrors as well?
I don't recall stumbling over that need, but the parallel makes it
tempting. I expect is should be a separate patch, though.
Antoine's right about using keyword args from C, though. I'd expect a
new helper function that h
On Mon, Aug 9, 2010 at 8:56 AM, Nick Coghlan wrote:
> Longer term, the buildbot setup should be modified to run the cleanup
> step even if the compilation step fails.
Running "make clean" after checkout/update should work as well.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mi
On Wed, Aug 11, 2010 at 11:22 AM, Éric Araujo wrote:
> Tarek, Antoine, RDM, MAL were +1 on using ~/.python (whether to use
> .pythonx.y or .python/x.y is a subissue to discuss after general agreement).
+0.5
I'd like to see a more complete proposal, including:
- what to do with Windows, Mac OS X
On Wed, Aug 11, 2010 at 11:28 AM, Mark Dickinson wrote:
> Well, perhaps I'm the only person bothered by this (and when I say
> 'bothered', it's not exactly keeping me up at nights).
I'm not going to lose sleep over it either, but the logo-link is
generally considered very non-discoverable. Keepi
On Wed, Aug 11, 2010 at 10:58 PM, Éric Araujo wrote:
> Considering the FHS or the XDG Base
> Directory specifications, there is a precedent in distinguishing user
> config (edited by the user through a text editor or settings graphical
> window), program data (state) and cache (files for speedups
1 - 100 of 240 matches
Mail list logo
