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 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
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 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 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 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
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, 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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, 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, 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, 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 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 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 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 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 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 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 Mon, Feb 11, 2013 at 7:16 AM, Developer Developer
wrote:
> Wouldn't it be better to do the following?
...
> Otherwise I think we are scanning rawdata[j:] twice.
Yes, that would be better, and avoids a string object creation as well.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in
On Tue, Apr 24, 2012 at 2:34 PM, Benjamin Peterson 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 languages, and there
On Wed, Mar 21, 2012 at 3:13 PM, Ned Batchelder 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
> out the baby wit
On Wed, Mar 21, 2012 at 2:46 PM, Guido van Rossum 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 size in pixles or
On Mon, Mar 12, 2012 at 11:43 AM, PJ Eby wrote:
> I wish Gmail defaulted to reply-all in the edit box.
There's a lab for that. :-)
-Fred
--
Fred L. Drake, Jr.
"A person who won't read has no advantage over one who can't read."
--Samuel Langhorne Clemens
_
On Tue, Feb 7, 2012 at 11:46 PM, Eli Bendersky 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 façade"? When I l
On Tue, Feb 7, 2012 at 11:31 PM, Eli Bendersky 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 took this to
On Fri, Jan 20, 2012 at 5:49 AM, Mark Shannon 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 developers now writ
On Thu, Dec 29, 2011 at 8:19 AM, Christian Heimes 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 any applicatio
On Thu, Sep 15, 2011 at 12:23 PM, Éric Araujo wrote:
> I think it would make more sense to
> push 2.x-compatible and 3.x-compatible sdists to PyPI (with an
> appropriate 'Programming Language :: Python :: 2' or '3' classifier) and
> have the download tools be smart.
FWIW, I prefer this as well.
On Tue, Sep 6, 2011 at 3:36 PM, Steven D'Aprano wrote:
> pERSONNALLY, i THINK THAT A SWAPCASE COMMAND IS ESSENTIAL FOR TEXT EDITOR
> APPLICATIONS, TO AVOID THOSE LITTLE cAPS lOCK ACCIDENTS.
There's a better solution to that, but the caps lock lobby has a stranglehold
on keyboard manufacturers.
On Wed, Aug 17, 2011 at 11:00 PM, Nick Coghlan wrote:
> It's actually for the same reason that unittest changes are backported
> under the unittest2 name - the distutils2 name can be used in the
> future to get Python 3.4 packaging features in Python 3.3, but that
> would be difficult if the backp
On Wed, Aug 17, 2011 at 9:15 PM, Chris McDonough wrote:
> I'll throw this out there.. why is it going to have a different name on
> python2 than on python3?
So it can be a drop-in replacement for the existing distutils2, I'd expect.
"packaging" is new with Python3, and is the Guido-approved name
I think either
Command-line option- and argument-parsing library.
or
Command-line option and argument parsing library.
would be acceptable.
-Fred
--
Fred L. Drake, Jr.
"A person who won't read has no advantage over one who can't read."
--Samuel Langhorne Clemens
___
On Tue, Jun 28, 2011 at 6:54 AM, Michael Foord
wrote:
> Added to which there are other descriptors, notably property, that are not
> directly callable but are not provided as normal "data attributes" (although
> the access syntax is the same). Properties are much closer to methods as
> they are im
On Tue, Jun 28, 2011 at 2:33 AM, Nick Coghlan wrote:
> The two terms I've got out of this thread are "callable attributes"
> (instance/static/class methods, etc) and "data attributes" (everything
> else). Both seem reasonable to me, creating two largely disjoint sets
> that together cover all the
Egads.
Back when I wrote
"Members and methods" should just be "attributes".
I used quotes to specifically indicate that this applied to the phrase
"members and methods", not their separate use. I guess I wasn't obvious
enough.
The general & Python-historical uses of "members" is unfortunat
On Mon, May 23, 2011 at 10:40 AM, Barry Warsaw wrote:
> You're not required to run the default desktop (Unity) of course. There are
> several options out of the box, including the classic desktop and Unity 2D,
> and there are a wide range of supported derivatives of Ubuntu offering
> additional d
2011/5/23 Łukasz Langa :
> The new Ubuntu already ships with Python 3.2.
Uptake on Ubuntu 11.04 will take longer than 10.10 uptake, given the
reliability issues and the reaction to the new user interface.
That's not to say it won't be significant, but the strength of the
indicator may be less sig
On Tue, May 10, 2011 at 6:38 PM, Steven D'Aprano wrote:
> I don't know why it was thought necessary to distinguish between them in the
> first place.
New users almost constantly expressed confusion by NameError when the name
was clearly bound at global scope, and a subsequent assignment caused it
On Thu, Apr 28, 2011 at 10:37 AM, Barry Warsaw wrote:
> I would agree. Use asserts for "this can't possibly happen "
> conditions.
Maybe we should rename "assert" to "wink", just to be clear on the usage. :-)
-Fred
--
Fred L. Drake, Jr.
"Give me the luxuries of life and I will willing
On Mon, Apr 25, 2011 at 8:04 AM, haael wrote:
> Sorry if I am asking the obvious, but why are the aliases of set types not
> included in the 'types' module? I thought for a moment that they are just
> classes, but no, they introduce themselves as built-in types, just like any
> other standard Pyth
On Sun, Apr 17, 2011 at 7:48 AM, Antoine Pitrou wrote:
> A separate announcement channel (mailing-list or newsgroup) would be better,
> where people can subscribe knowing they will only get a couple of e-mails a
> year.
Sounds like python-announce to me, with a matching entry on the front
of www.
On Fri, Apr 15, 2011 at 8:59 AM, Antoine Pitrou wrote:
> Relying on a vendor distribution (such as a Linux distro, or
> ActiveState) is hopefully enough to get these security updates in time
> without patching anything by hand. I don't think many people compile
> Python for production use, but man
On Wed, Mar 30, 2011 at 10:08 PM, Terry Reedy wrote:
> Yes, there is a good reason why database records are routinely displayed in
> labeled and located fields rather than in variable length natural language
> sentences with a monochrome font. Form letters, of course, are an exception.
Yep.
Whil
On Tue, Mar 22, 2011 at 10:25 AM, Barry Warsaw wrote:
> I'm curious: what are the benefits of the Mercurial model?
If we're all left confused and unable to use the tools to change the
software, we won't break things. This is good. :-)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in
On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran wrote:
> A new function, which can given this behavior is also a good idea.
I'm strongly in favor of this approach. I know we've been bitten by
changes made in the past, and have had to introduce Python-version
specific handling. (I don't have t
On Sat, Mar 5, 2011 at 3:08 AM, Toshio Kuratomi wrote:
> Some of them can be annoying as hell when dealing with a system that also
> installs multiple versions of a module. But one could argue that's the
> fault of setuptools' version handling rather than the entry-points
> handling.
Agreed; I d
On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
wrote:
> That (below) is not distutils it is setuptools. distutils just uses
> `scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Right; distutils scripts are just sad.
OTOH, entry-point based scripts are something setuptools got very
On Fri, Mar 4, 2011 at 10:59 AM, wrote:
> Something to consider here is how this will interact with Python files which
> are _not_ modules. I'm a little uneasy about having sys.modules["trial"]
> refer to the module defined by /usr/bin/trial.
I've long held the position that modules and scripts
On Thu, Jan 27, 2011 at 3:38 PM, Brett Cannon wrote:
> Linking to the 2.7.0 release page seems off since it is
> out of date, but linking to 2.7.1 also seems silly as that will become
> out of date as the newest release of Python 2.7 at some point as well.
I'd love to see something like this as w
On Mon, Jan 24, 2011 at 4:59 PM, Tres Seaver wrote:
> It might matter if we want to enable third-party package installation
> into a namespace also used by the stdlib: ISTR that the 'xml' package
> had such installs at one point.
Almost, but not quite.
The xml package at one point allowed itsel
On Mon, Jan 24, 2011 at 2:46 PM, Raymond Hettinger
wrote:
> P.S. I've discussed this with Michael and his preference is against
> going back to the Py3.1 style where the tests were under Lib/test. He
> thinks the current tree makes it easier to sync with Py2.7 and the
> unittest2 third-party mod
On Mon, Jan 24, 2011 at 2:04 PM, Raymond Hettinger
wrote:
> ISTM, that if we're going to use python packages as "namespace containers" for
> categorizing modules, then the top level __init__ namespace should be left
> empty.
This is only an issue if the separate components are distributed
separa
On Thu, Dec 16, 2010 at 1:30 PM, wrote:
> I doubt this makes a difference to the point being discussed, but it
> _could_. I suggest performing your tests with telnet, instead.
I received similar results using telnet earlier today.
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my
On Thu, Dec 16, 2010 at 10:52 AM, André Malo wrote:
> I'd vote for removing it from the client code and keeping it in the server.
If it must be maintained anywhere, it should be in the client,
according to the basic principle of "accept what you can, generate
carefully."
Python.org's HTTP/0.9 re
On Wed, Dec 15, 2010 at 1:39 PM, Antoine Pitrou wrote:
> I would like to remove HTTP 0.9 support from http.client and
> http.server.
+1
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
___
Python-Dev mailing list
On Tue, Dec 14, 2010 at 6:24 AM, Steven D'Aprano wrote:
> The good thing about that idea is that maintenance of buggy.py will be so
> simple!
It's self-describing, and needs no further documentation. :-)
-Fred
--
Fred L. Drake, Jr.
"A storm broke loose in my mind." --Albert Einstein
__
On Wed, Dec 8, 2010 at 9:27 AM, Antoine Pitrou wrote:
> The thing is, they don't *want* to configure them, but you force them
> to do some configuration if they don't want error messages to be
> silenced.
As I tried to explain earlier, a NullHandler doesn't silence anything
except the message abo
On Wed, Dec 8, 2010 at 8:19 AM, Paul Moore wrote:
> But you don't because the library developer added a NullHandler which
> you have to switch off!!!
I'm suspecting there's misunderstanding on this point.
If I have a logger "myns.mypackage" for my library, and register a
NullHandler for that, th
On Mon, Dec 6, 2010 at 4:02 PM, Raymond Hettinger
wrote:
> IIRC, pprint has a safe_repr() and string.Template has safe_substitute()
> and pydoc has a safe import.
pprint.saferepr
Ok, this one's my fault as well. Probably should just be named repr.
string.Template.safe_substitute
Agree o
On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger
wrote:
> We really ought to stop with the SafeFoo naming convention.
> It is only descriptive to the person who wrote the class or function,
> not to the user who will immediately wonder, "safe from what?"
Safe from bad vampire movies, of course!
2010/12/5 Łukasz Langa :
> On a related note, if you're sure logging users don't use any interpolation,
> you can also use SafeConfigParser(interpolation=None) so then all values
> become raw by default (e.g. people can use Python string formatting
> directives, % signs etc.). We can discuss this l
On Tue, Nov 23, 2010 at 9:35 PM, Raymond Hettinger
wrote:
> The least worst option is to do nothing at all.
For the standard library, I agree.
There are enough variants that are needed/desired in different
contexts, and there isn't a single clear winner. Nor is there any
compelling reason to ha
On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou wrote:
> Enumerations aren't a type at all (they have no distinguishing
> property).
In any given language, this may be true, or not. Whether they should
be distinct in Python is core to the current discussion.
>From a backward-compatibility pers
On Thu, Nov 18, 2010 at 6:41 AM, Michael Foord
wrote:
> Along with the others +1
I agree with keeping these distinct and orthogonal as well.
> What is more important is that we have a clearly stated policy for new
> modules and adding names to existing modules so that we don't have to repeat
> t
On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl wrote:
> So it comes down again to what we'd like __all__ to mean foremost:
> public API, or just a list for "import *"?
It is and has been since its inception *the* list for "import *".
Any additional meaning will have to accommodate that usage as w
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
> The library documentation is *not* the right place for quibbling about
> what constitutes a public API when using other means than the library
> documentation to find APIs to call.
Quibbling can happen on the mailing list, where it can be ign
2010/11/17 Michael Foord :
> So -1 on splitting Python development style guide into multiple documents.
I don't think that the publicness or API stability promises of the
standard library are part of a style guide. They're an essential part
of the library documentation. They aren't a guide for 3
On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney wrote:
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequently
On Fri, Nov 12, 2010 at 3:57 AM, georg.brandl
wrote in a commit:
> Add a deprecated-removed directive that allows to give the version of removal
> for deprecations.
This sounds pretty general-purpose rather than Python-specific. Any
chance this will move into Sphinx? I know a few projects that
On Thu, Nov 11, 2010 at 8:23 AM, Alexander Belopolsky
wrote:
> I don't dispute that these are *the* rules, but my question was
> whether it is ok to break them in specific cases such as
> trace.rx_blank. If not, how can we deprecate trace.rx_blank which is
> a regex constant?
Since trace is docu
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 Tue, Nov 2, 2010 at 12:37 PM, Jacob Kaplan-Moss 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.
"A storm broke loose in my mind." --Albert Einstein
__
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 Fri, Oct 8, 2010 at 9:22 AM, Tarek Ziadé wrote:
> pkg_manager ?
1. Underscores are evil. Don't do that.
2. Mixed shortened + written-out names are just nasty.
> Mmm.. setup.py is gone in D2, and setup.py will be the marker of d1.
Did we finally decide it could be done without setup.py enti
On Fri, Oct 8, 2010 at 7:24 AM, Dirkjan Ochtman wrote:
> It doesn't seem very nice to have a version in the script. Can we just
> call it distutils? Or py-dist?
If we go this route, then
- "make altinstall" should include the version number in the name of *any*
scripts it installs.
- "make in
On Fri, Oct 1, 2010 at 12:31 PM, Barry Warsaw wrote:
> I should note one other thing, in reference to my previous posting about
> reviews. Launchpad does have a backdoor for getting changes in without
> formal review. It's called "rubber stamping" and shows up in commit messages,
This makes a l
On Wed, Sep 29, 2010 at 5:57 PM, Nick Coghlan wrote:
> Would it be possible to sync up the reitveld issue numbers with the
> roundup ones if you did that? Or would the fact that a single issue
> can have multiple attached patches prevent that?
Another quirk would be that often several pieces are
On Wed, Sep 29, 2010 at 5:41 PM, Daniel Stutzbach
wrote:
> Obviously, it would not be possible to write hooks that reject changesets
Of course, this is one of the more interesting ways to use hooks.
Since there's no current expectation that running our own will be a
problem, why don't we convert
1 - 100 of 240 matches
Mail list logo
