[Python-Dev] Re: IRC #python-dev channel is now on Libera Chat (bye bye Freenode)

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

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

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.

[Python-Dev] Re: Revive PEP 396 -- Module Version Numbers ?

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

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

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

[Python-Dev] Re: Remove formatter module

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

[Python-Dev] Re: PEP 632: Deprecate distutils module

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

[Python-Dev] Re: [Possibly off-topic] Python-Announce floods and delays

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

Re: [Python-Dev] datetime.timedelta total_microseconds

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

Re: [Python-Dev] PEP 572: Do we really need a ":" in ":="?

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

Re: [Python-Dev] iso8601 parsing

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

Re: [Python-Dev] Reminder: snapshots and releases coming up in the next several days

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

Re: [Python-Dev] PEP 553: Built-in debug()

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

Re: [Python-Dev] PyWeakref_GetObject() borrows its reference from... whom?

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

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

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. :-)

Re: [Python-Dev] Smoothing the transition from Python 2 to 3

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 ___

Re: [Python-Dev] Adding NewType() to PEP 484

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

Re: [Python-Dev] pathlib - current status of discussions

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 >

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

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()

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

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.

Re: [Python-Dev] PEP 257 and __init__

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 >

Re: [Python-Dev] hg vs Github [was: PEP 481 - Migrate Some Supporting Repositories to Git and Github]

On Mon, Dec 1, 2014 at 12:37 PM, Jim J. Jewett jimjjew...@gmail.com 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

Re: [Python-Dev] ConfigParser mangles keys with special chars

On Sat, Apr 26, 2014 at 1:34 AM, Steven D'Aprano st...@pearwood.info 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

Re: [Python-Dev] ConfigParser mangles keys with special chars

On Sat, Apr 26, 2014 at 7:23 AM, Steven D'Aprano st...@pearwood.info 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

Re: [Python-Dev] ConfigParser mangles keys with special chars

On Fri, Apr 25, 2014 at 10:22 AM, Florian Bruhin m...@the-compiler.org 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

Re: [Python-Dev] ConfigParser mangles keys with special chars

On Fri, Apr 25, 2014 at 2:45 PM, Terry Reedy tjre...@udel.edu 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

Re: [Python-Dev] ConfigParser mangles keys with special chars

On Fri, Apr 25, 2014 at 3:12 PM, Ethan Furman et...@stoneleaf.us 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

Re: [Python-Dev] Negative timedelta strings

On Fri, Mar 28, 2014 at 5:19 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, Sep 23, 2013 at 7:27 AM, Walter Dörwald wal...@livinglogic.de 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.fred at fdrake.net A storm broke

Re: [Python-Dev] Best practice for documentation for std lib

On Mon, Sep 23, 2013 at 3:01 PM, Terry Reedy tjre...@udel.edu 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

Re: [Python-Dev] Offtopic: OpenID Providers

On Thu, Sep 5, 2013 at 4:29 PM, Oleg Broytman p...@phdru.name 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.

Re: [Python-Dev] Our failure at handling GSoC students

On Tue, Aug 6, 2013 at 3:51 PM, Antoine Pitrou solip...@pitrou.net 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

Re: [Python-Dev] PEP 8 modernisation

On Thu, Aug 1, 2013 at 9:10 AM, Antoine Pitrou solip...@pitrou.net 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.fred at fdrake.net A storm

Re: [Python-Dev] Structural cleanups to the main CPython repo

On Tue, May 28, 2013 at 9:07 AM, Nick Coghlan ncogh...@gmail.com 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

Re: [Python-Dev] Matching __all__ to doc: bugfix or enhancement?

On Thu, Mar 14, 2013 at 9:33 PM, Terry Reedy tjre...@udel.edu 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

Re: [Python-Dev] [Python-checkins] peps: Pre-alpha draft for PEP 435 (enum). The name is not important at the moment, as

On Wed, Feb 27, 2013 at 8:30 AM, Antoine Pitrou solip...@pitrou.net 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

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

On Wed, Feb 20, 2013 at 5:45 PM, R. David Murray rdmur...@bitdance.com 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

Re: [Python-Dev] XML DoS vulnerabilities and exploits in Python

On Wed, Feb 20, 2013 at 7:38 PM, Nick Coghlan ncogh...@gmail.com wrote: Christian's suggested approach sounds sane to me: Definitely. A strong +1 from me, FWIW these days. -Fred -- Fred L. Drake, Jr.fred at fdrake.net A storm broke loose in my mind. --Albert Einstein

Re: [Python-Dev] Fwd: PEP 426 is now the draft spec for distribution metadata 2.0

On Tue, Feb 19, 2013 at 6:19 PM, Donald Stufft donald.stu...@gmail.com 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

Re: [Python-Dev] PEP 426 is now the draft spec for distribution metadata 2.0

On Sun, Feb 17, 2013 at 1:45 PM, Daniel Holth dho...@gmail.com 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

Re: [Python-Dev] PEP 426 is now the draft spec for distribution metadata 2.0

On Sun, Feb 17, 2013 at 4:21 PM, Nick Coghlan ncogh...@gmail.com 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

Re: [Python-Dev] Question regarding: Lib/_markupbase.py

On Mon, Feb 11, 2013 at 7:16 AM, Developer Developer just_another_develo...@yahoo.de 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,

Re: [Python-Dev] cpython (2.7): #14538: HTMLParser can now parse correctly start tags that contain a bare /.

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

Re: [Python-Dev] Playing with a new theme for the docs

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

Re: [Python-Dev] Playing with a new theme for the docs

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

Re: [Python-Dev] Fwd: [Import-SIG] Where to discuss PEP 382 vs. PEP 402 (namespace packages)?

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

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

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

Re: [Python-Dev] folding cElementTree behind ElementTree in 3.3

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

Re: [Python-Dev] Changing the order of iteration over a dictionary

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

Re: [Python-Dev] Hash collision security issue (now public)

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

Re: [Python-Dev] Packaging in Python 2 anyone ?

On Thu, Sep 15, 2011 at 12:23 PM, Éric Araujo mer...@netwok.org 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

Re: [Python-Dev] Maintenance burden of str.swapcase

On Tue, Sep 6, 2011 at 3:36 PM, Steven D'Aprano st...@pearwood.info 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

Re: [Python-Dev] Packaging in Python 2 anyone ?

On Wed, Aug 17, 2011 at 9:15 PM, Chris McDonough chr...@plope.com 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

Re: [Python-Dev] Packaging in Python 2 anyone ?

On Wed, Aug 17, 2011 at 11:00 PM, Nick Coghlan ncogh...@gmail.com 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

Re: [Python-Dev] [Python-checkins] cpython (3.2): Use real word in English text (i.e. not code)

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.    fdrake at acm.org A person who won't read has no advantage over one who can't read.    --Samuel Langhorne

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Tue, Jun 28, 2011 at 2:33 AM, Nick Coghlan ncogh...@gmail.com 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

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

On Tue, Jun 28, 2011 at 6:54 AM, Michael Foord fuzzy...@voidspace.org.uk 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

Re: [Python-Dev] Issue10403 - using 'attributes' instead of members in documentation

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 unfortunate. My

Re: [Python-Dev] the distutils2 repo and 3to2

2011/5/23 Łukasz Langa luk...@langa.pl: 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

Re: [Python-Dev] the distutils2 repo and 3to2

On Mon, May 23, 2011 at 10:40 AM, Barry Warsaw ba...@python.org 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

Re: [Python-Dev] more timely detection of unbound locals

On Tue, May 10, 2011 at 6:38 PM, Steven D'Aprano st...@pearwood.info 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

Re: [Python-Dev] the role of assert in the standard library ?

On Thu, Apr 28, 2011 at 10:37 AM, Barry Warsaw ba...@python.org wrote: I would agree.  Use asserts for this can't possibly happen wink conditions. Maybe we should rename assert to wink, just to be clear on the usage. :-) -Fred -- Fred L. Drake, Jr.    fdrake at acm.org Give me the

Re: [Python-Dev] Why are there no 'set' and 'frozenset' types in the 'types' module?

On Mon, Apr 25, 2011 at 8:04 AM, haael ha...@interia.pl 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

Re: [Python-Dev] Releases for recent security vulnerability

On Sun, Apr 17, 2011 at 7:48 AM, Antoine Pitrou solip...@pitrou.net 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

Re: [Python-Dev] Releases for recent security vulnerability

On Fri, Apr 15, 2011 at 8:59 AM, Antoine Pitrou solip...@pitrou.net 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

Re: [Python-Dev] Please revert autofolding of tracker edit form

On Wed, Mar 30, 2011 at 10:08 PM, Terry Reedy tjre...@udel.edu 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

Re: [Python-Dev] Finally switch urllib.parse to RFC3986 semantics?

On Wed, Mar 16, 2011 at 12:03 AM, Senthil Kumaran orsent...@gmail.com 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

Re: [Python-Dev] PEP 395: Module Aliasing

On Sat, Mar 5, 2011 at 3:08 AM, Toshio Kuratomi a.bad...@gmail.com 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

Re: [Python-Dev] PEP 395: Module Aliasing

On Fri, Mar 4, 2011 at 10:59 AM, exar...@twistedmatrix.com 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

Re: [Python-Dev] PEP 395: Module Aliasing

On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord fuzzy...@voidspace.org.uk 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

Re: [Python-Dev] getting stable URLs for major.minor versions

On Thu, Jan 27, 2011 at 3:38 PM, Brett Cannon br...@python.org 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

Re: [Python-Dev] Keeping __init__.py empty for Python packages used for module grouping.

On Mon, Jan 24, 2011 at 2:04 PM, Raymond Hettinger raymond.hettin...@gmail.com 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

Re: [Python-Dev] Location of tests for packages

On Mon, Jan 24, 2011 at 2:46 PM, Raymond Hettinger raymond.hettin...@gmail.com 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

Re: [Python-Dev] Keeping __init__.py empty for Python packages used for module grouping.

On Mon, Jan 24, 2011 at 4:59 PM, Tres Seaver tsea...@palladion.com 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

Re: [Python-Dev] Remove HTTP 0.9 support

On Thu, Dec 16, 2010 at 10:52 AM, André Malo n...@perlig.de 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

Re: [Python-Dev] Remove HTTP 0.9 support

On Thu, Dec 16, 2010 at 1:30 PM, exar...@twistedmatrix.com 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.   

Re: [Python-Dev] Remove HTTP 0.9 support

On Wed, Dec 15, 2010 at 1:39 PM, Antoine Pitrou solip...@pitrou.net wrote: I would like to remove HTTP 0.9 support from http.client and http.server. +1   -Fred -- Fred L. Drake, Jr.    fdrake at acm.org A storm broke loose in my mind.  --Albert Einstein

Re: [Python-Dev] configparser 1.1 - one last bug fix needed

On Tue, Dec 14, 2010 at 6:24 AM, Steven D'Aprano st...@pearwood.info 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.    fdrake at acm.org A storm broke loose

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, Dec 8, 2010 at 8:19 AM, Paul Moore p.f.mo...@gmail.com 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

Re: [Python-Dev] Using logging in the stdlib and its unit tests

On Wed, Dec 8, 2010 at 9:27 AM, Antoine Pitrou solip...@pitrou.net 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

Re: [Python-Dev] Repo frozen for 3.2

On Mon, Dec 6, 2010 at 2:21 PM, Raymond Hettinger raymond.hettin...@gmail.com 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

Re: [Python-Dev] Repo frozen for 3.2

On Mon, Dec 6, 2010 at 4:02 PM, Raymond Hettinger raymond.hettin...@gmail.com 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.

Re: [Python-Dev] Repo frozen for 3.2

2010/12/5 Łukasz Langa luk...@langa.pl: 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

Re: [Python-Dev] constant/enum type in stdlib

On Tue, Nov 23, 2010 at 12:37 PM, Antoine Pitrou solip...@pitrou.net 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

Re: [Python-Dev] constant/enum type in stdlib

On Tue, Nov 23, 2010 at 9:35 PM, Raymond Hettinger raymond.hettin...@gmail.com 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

Re: [Python-Dev] Breaking undocumented API

On Thu, Nov 18, 2010 at 6:41 AM, Michael Foord fuzzy...@voidspace.org.uk 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

Re: [Python-Dev] Breaking undocumented API

2010/11/17 Michael Foord fuzzy...@voidspace.org.uk: 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.

Re: [Python-Dev] Breaking undocumented API

On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan ncogh...@gmail.com 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,

Re: [Python-Dev] Breaking undocumented API

On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl g.bra...@gmx.net 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

Re: [Python-Dev] Breaking undocumented API

On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney ben+pyt...@benfinney.id.au 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

Re: [Python-Dev] [Python-checkins] r86429 - python/branches/py3k/Doc/tools/sphinxext/pyspecific.py

On Fri, Nov 12, 2010 at 3:57 AM, georg.brandl python-check...@python.org 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

Re: [Python-Dev] Breaking undocumented API

On Thu, Nov 11, 2010 at 8:23 AM, Alexander Belopolsky alexander.belopol...@gmail.com 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

Re: [Python-Dev] Cleaning-up the new unittest API

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

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

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

Re: [Python-Dev] On breaking modules into packages Was: [issue10199] Move Demo/turtle under Lib/

On Tue, Oct 26, 2010 at 4:46 PM, Michael Foord fuzzy...@voidspace.org.uk wrote: I find the big-ball-of-mud style development, where everything lives inside huge monolithic modules, very painful. I also think that it is an extremely bad example for new developers. Gadzooks, Michael! Something

Re: [Python-Dev] Distutils2 scripts

On Fri, Oct 8, 2010 at 7:24 AM, Dirkjan Ochtman dirk...@ochtman.nl 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

Re: [Python-Dev] Distutils2 scripts

On Fri, Oct 8, 2010 at 9:22 AM, Tarek Ziadé ziade.ta...@gmail.com 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

Re: [Python-Dev] We should be using a tool for code reviews

On Fri, Oct 1, 2010 at 12:31 PM, Barry Warsaw ba...@python.org 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,

Re: [Python-Dev] Atlassian and bitbucket merge

On Wed, Sep 29, 2010 at 5:41 PM, Daniel Stutzbach dan...@stutzbachenterprises.com 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

Re: [Python-Dev] We should be using a tool for code reviews

On Wed, Sep 29, 2010 at 5:57 PM, Nick Coghlan ncogh...@gmail.com 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

Re: [Python-Dev] Moving the developer docs?

On Thu, Sep 23, 2010 at 2:40 AM, Georg Brandl g.bra...@gmx.net wrote: That's right.  It is true that it isn't branch-specific information, and that does cause a little bit of irritation for me too, but neither is Misc/developers.txt or Misc/maintainers.rst. Agreed. I'd rather those were

  1   2   3   >