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

[Fred Drake]

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 going
> on between different IRC providers?!?
>
> On Wed, May 26, 2021 at 6:43 AM Victor Stinner 
> wrote:
>
>> By the way, #python also moved to Libera Chat:
>> https://www.pound-python.org/
>>
>> The PSF (Group Contact) owns  #python*, #pypa* and #psf* channels on
>> Libera.
>>
>> I updated the IRC informations in the Python devguide.
>>
>> I'm still migrating #python-dev-notifs bots to Libera.
>>
>> Victor
>>
>> On Wed, May 26, 2021 at 12:46 PM Victor Stinner 
>> wrote:
>> >
>> > Hi,
>> >
>> > The #python-dev IRC channel moves from Freenode to Libera Chat:
>> > https://libera.chat/ I'm connected as vstinner, see you there ;-) Join
>> > the channel if you would like to talk about the development of Python
>> > itself (the VM, bytecode, stdlib, etc.)!
>> >
>> > Moreover, bots notifications (GitHub, buildbots, bugs.python.org) are
>> > now in a new dedicated channel #python-dev-notifs so humans can talk
>> > together again! :-) The migration is on-going, right now some
>> > notifications are still on Freenode.
>> >
>> > --
>> >
>> > Yesterday evening, Freenode admins decided to take the control of the
>> > #python-fr channel on Freenode (which now redirects to a new
>> > ##python-fr channel), only because the channel topic contained
>> > "libera"! The french Python association ("AFPy") managing #python-fr
>> > lost control and decided to migrate to Libera Chat (libera.chat).
>> > Announcement in french:
>> > https://www.afpy.org/posts/actualites/1622023152
>> >
>> > I'm disappointed by how the events are going. At least, it motivated
>> > me to move bots notfications ;-)
>> >
>> > Victor
>> > --
>> > Night gathers, and now my watch begins. It shall not end until my death.
>>
>>
>>
>> --
>> Night gathers, and now my watch begins. It shall not end until my death.
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/R3YTKHTUPMF3W5UH2YP4ACXHBXTQLQUE/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/IAIOXCDC32BB5OSEK6HUEU244EW7B6DT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Fred L. Drake, Jr.
"There is nothing more uncommon than common sense."
  --Frank Lloyd Wright
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZN4VQ2ZOBQ2R7SNHCWLGBICR5CVFWMT4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Fred Drake]

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.

Drop a __version__ in your modules if you find it valuable, but otherwise,
there's nothing to do here.


  -Fred

-- 
Fred L. Drake, Jr.
"There is nothing more uncommon than common sense."
  --Frank Lloyd Wright
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3QHBGEIDDJEHZP5Q2I3ZGQ73FZ6SPDAQ/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Fred Drake]

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

-- 
Fred L. Drake, Jr.
"There is nothing more uncommon than common sense."
  --Frank Lloyd Wright
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HPAU4PMIGPPG2R7RJIL6QDS2WYACBCRV/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Fred Drake]

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 running the per-package tears.
>

Sometimes, auto-correct really does understand!

Your point is right on target, and really can't be understated.


  -Fred

-- 
Fred L. Drake, Jr.
"There is nothing more uncommon than common sense."
  --Frank Lloyd Wright
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KZX2DOJBICJWJ3Y6EMUA2F675TMSYSPV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove formatter module

[Fred Drake]

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 recall using the
API, but... it definitely doesn't belong in the stdlib.


  -Fred

-- 
Fred L. Drake, Jr.
"There is nothing more uncommon than common sense."
  --Frank Lloyd Wright
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2IBAT5XCAX4WZ4RHUR22IZ5A2B3U7KPW/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Fred Drake]

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 build systems is what already encouraged the
> official policy of not adding features to distutils (more than 10
> years ago, IIRC).

My recollection is that we decided to stop changing distutils because
too many 3rd party extensions (often included directly in the packages
that needed them) using undocumented parts fo distutils directly
(since there was no substantially documented API for distutils in the
beginning).  Every time anything changed, something was broken for
somebody.  Since that affected not only the developers hooking in to
distutils but the users of their packages, touching distutils caused
too much pain.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6SO72DJWM7F77FFWGMIHCD2IWRMD5JAP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Fred Drake]

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 welcome! :)

Does Mailman 3 notify moderators when candidates for moderation enter
the queue?  If so, I'll step up to help out.  MM3 knows me as
"f...@fdrake.net".


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VRQSQMPOH5NTJN46N6W5CAPTAGPHWSF3/

Re: [Python-Dev] datetime.timedelta total_microseconds

[Fred Drake]

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 bunch of timedelta values using sum([d0, d1, ..., dn]).

Given we already have total_seconds(), it's not clear avoiding
additional methods is meaningful, unless we're going to deprecate
total_seconds().  Not really a win in my book.

I'd rather stick with the existing pattern, if anything even needs to
be done.  I'm quite happy to use d.total_seconds() * 100 as long
as the accuracy is sufficient.  Someone with more floating point
expertise can probably think of a reason that's not good enough, in
which case... an appropriate method wouldn't be poorly named as
total_microseconds.

> I might prefer one method, .convert? with an argument
> specifying the conversion unit, 'microseconds', 'seconds', ... .

Using a function that takes a units indicator (as
d.convert(units='microseconds')) seems like a poor choice; most uses
will hard-code exactly one value for the units, rather than passing in
a variable.  Getting a more specific name seems reasonable.

> It is also not obvious is answer is rounded to nearest second
> or not.

No, but that's a problem we have now with total_seconds().  Best
handled by maintaining the pattern and documenting the behavior.
While fractional microseconds aren't a thing with timedelta values now
(and probably not in any near future), it seems good to keep these
floats so things stay consistent if we can ever get better clocks.
:-)


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 that Python
offers them, they still really want some of the hand-holding languages
like Java give them.  What exactly they identify as "compelling"
varies based on their past experiences, but it's not completely
without reason.  The reasoning is often tied to providing APIs
"less-experienced" programmers can use without breaking things.

Some of these programmers at least claim to understand that bigger
risks come from not dealing with API boundaries that check input
values carefully, or that don't deal cleanly with exception
propagation; that seems to be fairly difficult for many.  The
idiomatic models I've found most desirable in Python are not as widely
valued as I'd hope.

It's hard to say what that tells us, and I think we'd want more
quantifiable evidence before drawing conclusions.  The prevalence of
expectation that an API constrains the mechanics of how it is used is
something I find surprising.  While I can suspect that it's misguided,
I keep running into situations where code needs to be maintained by
people who just aren't as familiar with the idioms I'm accustomed to,
so... considering the issue has value.


  -Fred

--
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] iso8601 parsing

[Fred Drake]

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 both space and "T".

> Would all of that string parsing logic be a performance regression
> from the current constructor? Does it accept None or empty string?

It's an alternate constructor, so should not impact the existing
constructor (though it could employ the existing constructor to get
work done).

It should not accept anything but a valid ISO 8601 string.

> Should the date time constructor support nanos= (just like time_ns())?

No.  It should support exactly up to 6 decimal digits to populate the
microsecond field.

> ENH: Add nanosecond support to the time and datetime constructors

This should be left for a separate change, if we determine it should
be implemented for the datetime and timedelta types.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 this schedule that's
currently maintained?


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 python run with actual or
> simulated stdin and stdout.  IDLE's idb is specific to working with IDLE. So
> one could not set an EV to 'idlelib.idb.start' and leave it while switching
> between IDLE and console.

Would it work for IDLE to set the environment variable for the child process?

The user certainly should not need to be involved in that.

That doesn't address the issue of setting up the communications
channel before breakpoint() is called, but allows the breakpointhook
that gets used to work with whatever has been arranged.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 the time it was returned.  Clearly it
can't be considered valid once additional Python code might be run.

> FWIW, yes, this is playing merry hell with the Gilectomy.  If there are two
> threads, and one calls PyWeakref_GetObject(obj), and there's only one
> reference to obj, and the other thread blows it away... now what?  It's my
> contention that this API is simply untenable under the Gilectomy, and that
> it needs to change to returning a new (strong) reference.

+1 for this change.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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

+1 for this variant; I really don't like masking errors inside the
__fspath__ implementation.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 returning bytes (not
sure that ever makes sense on Windows, since I don't use Windows),
then I'd be happy with os.fsbytespath().


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 first choice as it is simplicity itself to know when
> looking at it if bytes might be coming back by the presence or absence of a
> second argument to the call; otherwise one has to keep straight in one's
> head which is str-only and which might allow bytes (I'm not very good at
> keeping similar sounding functions separate -- what's the difference between
> shutil.copy and shutil.copy2?  I have to look it up every time).

I do the same, but... this is one of those cases where a caller will
usually be passing a constant directly. If passed as a positional
argument, it'll just be confusing ("what's True?" is my usual reaction
to a Boolean positional argument). If passed as a keyword argument
with a descriptive name, it'll be longer than I'd like to see:

path_str = os.fspath(path, allow_bytes=True)

Names like os.fspath() and os.fssyspath() seem good to me.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 257 and __init__

[Fred Drake]

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 described in the class' docstring
> itself, right?

__init__ is not always the only constructor for a class; each
constructor's arguments should be documented as part of the
constructor.  The class docstring should provide summary information
for the class as a whole.

I can also imagine cases where the __init__ isn't considered public,
though I suspect that's exceedingly rare in practice.  (Can't think of
a case I've actually run across like that.)

> Should we remove "__init__" (the class method, *not* the package file)
> as to require docstrings in the PEP?

I don't think so.  The advice seems sound to me.


  -Fred

-- 
Fred L. Drake, Jr.
"A storm broke loose in my mind."  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 differences (though I don't often use
Github myself), but the Bitbucket UIs have a much cleaner feel to
them.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 paragraph here could be strengthened a little:
https://docs.python.org/3/library/configparser.html#supported-ini-file-structure

But that seems clear to me.  Lines starting with the comment prefix
are comments.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 there's no way to escape comment characters, I think it
 is a bug that you can insert illegal keys into the cp object in the
 first place.

Fair enough.

I'm not trying to argue that it isn't a bug, but that risk of breaking
currently-working applications with data they consider acceptable is
high.  Many use configparser for input only, and make no use of the
serialization feature.  Those applications can be broken by adding a
constraint on the data that's allowed, regardless of what we think of
their keys.

Chaning this in an application for which it's safe (easier to know at
the application level) is easy enough:

import configparser
import re

class ProtectionistParser(configparser.RawConfigParser):

_rx = re.compile(r[a-z]([-a-z]*[a-z])?$)  # or whatever
makes sense for your app

def optionxform(self, opt):
if self._rx.match(opt) is None:
raise ValueError(don't like this: %r % opt)
return opt

Maybe the strict mode is considered new enough that this isn't as
significant a risk, and it could be allowed when that's enabled; I'm
sure Łukasz will have a carefully considered opinion (and I'll defer
to him in the end).


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 same
 configparser to *always* result in the same data, as long as writing
 worked without error.

 Thoughts? Should I submit a bug report?

I believe you should, if only to provide a place to record why no
change gets made.

Had ConfigParser been more careful from the beginning, that would have
been really good.

At this point, it would be a backward-incompatible change, so it's
unlikely such a change could be allowed to affect existing code.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 sensible set of INI styles available. So I wonder whether the
 thought-to-be-buggy behavior is actually buggy with respect to *all* the
 supported styles or just some of them.

Given that most variants are completely undocumented, answering this
is sufficiently intractable for me to call it intractable.

We've also run into compatibility issues because some applications
treated the parser object as an in-memory configuration database
throughout the process lifetime, updating values with non-string
values of various sorts.  Given the age of the module, the existing
number of uses of undocumented accidents of implementation is very
large.  Fixing bugs like this has an excellent track record of
uncovering these uses, so... we've grown a bit wary.  It's not unheard
of for projects to fork their own copies of configparser because of
changes to the stdlib version.  (No, I haven't done a census of such
cases, but I do know of at least one in a popular package.)


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 you're using and override the
``optionxform`` method to perform the checks you want for option
names.  I don't know if current versions provide a similar hook to
validate section names; providing *that* would be an excellent
enhancement.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Negative timedelta strings

[Fred Drake]

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 confuse the notions of duration and delta.  Notionally, a delta
contains more information than a duration.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
 the current doc crew.

I don't know about the current crew, but this dates way back to
Guido's initial LaTeX documentation, and Guido's strong preference on
this.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Offtopic: OpenID Providers

[Fred Drake]

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.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 obvious.

I haven't been active with GSoC the last couple of years, but if we don't
have any sort of guide for mentors, we probably should, and this is an
issue that should be mentioned as one that requires discussion with the
students.  That's our role as a community and as mentors when it comes to
GSoC.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 8 modernisation

[Fred Drake]

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 broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 long?


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 determined to be desirable, it should not be applied
to any version before 3.4.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 libraries or frameworks whose users aren't expected to
know them exhaustively, making reasonable checks of parameters can
substantially reduce the number of ways it can be used incorrectly.  Outside
performance critical code, this is a win.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 the parsers distributed for Python today.

Even when loading external resources, I don't think there's anything in the
XML specification that says how they have to be loaded, or how to deal with
an error when they are (and refusing to load because of resource limits is
reasonably just another error with respect to the parser).

While I'd hate to make XML processing more painful than it often is, there's
no injunction not to be reasonable.  Security concerns and resource limits
are cross-cutting concerns, so it's not wrong to provide safe defaults.

Doing so *will* be backward incompatible, and I'm not sure there's a good
way to gauge the extent of the breakage.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 boot.  Packaging hasn't done well there.

I'd rather see a successful packaging story develop than bundle it into the
standard library.  The later just isn't that interesting any more.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 improve adoption.


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
allow provision of both 1.x and 2.0, so version 2.0 metadata can be deployed
as tool support becomes available, instead of having to wait until 1.x tools
are replaced.

Once tools are following the new rule about version compatibility, there's
less worry about this (at least on my part).


  -Fred

-- 
Fred L. Drake, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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, Jr.fred at fdrake.net
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 languages, and there's soup.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 size in pixles or (if we're lucky) points.

Not sure there's any lesson to be learned from this, aside from designers
really having it out for anyone who needs to read.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
 out the baby with the bathwater.

I get that.  I'm not bad-mouthing actual design, and there are definitely
good designers out there.

It's unfortunate they're so seriously outnumbered.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 took this to be an observation rather than a declaration
of intent by the package owner (Fredrik Lundh).

 P.S. Would declaring that xml.etree is now independently maintained by
 pydev be a bad thing? Why?

So long as Fredrik owns the package, I think forking it for the standard
library would be a bad thing, though not for technical reasons.  Fredrik
provided his libraries for the standard library in good faith, and we still
list him as the external maintainer.  Until *that* changes, forking would
be inappropriate.  I'd much rather see a discussion with Fredrik about the
future maintenance plan for ElementTree and cElementTree.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 façade?  When I look in Lib/xml/etree/, I see the ElementTree,
ElementPath, and ElementInclude modules, and a wrapper for cElementTree's
extension module.

There isn't any sort of façade for ElementTree; are you proposing to add
one, perhaps in xml.etree/__init__.py?


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 developers now write tests of what's actually important rather
than relying on implementation details of the Python runtime.

A hash function that changes more often than during an occasional major
version update will encourage more developers to write better tests.  We
can think of it as an educational tool.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 any application
to rely on a stable hash would cause problems when updating Python versions.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 this as well.  I'd certainly appreciate the option to do it
this way.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 manufacturers.


-- 
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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 Guido-approved name.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 difficult if the backport shadowed the standard library name.

Ah, yes... the old too bad we stuck it in the standard library problem.

For some things, an easy lament, but for foundational packaging-related
things, it's hard to get around.


  -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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 Clemens
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 cover all the different kinds of attribute you're likely
 to encounter.

But callable attributes aren't the same thing as methods; most are methods,
but not all.  Sometimes, they're data used by the object.  The fact that
data attributes can be callable is irrelevant.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 methods as
 they are implemented on the class and fetched via the descriptor protocol.
 Instead of data attributes I prefer the term instance attributes
 although that doesn't include class attributes (or more precisely it
 doesn't cover class attributes that aren't descriptors).

Given the availability of __getattr__ and __getattribute__, I consider
properties an implementation detail for some attributes.  The fact that
Python code is called on access is only marginally interesting.

 The problem with data attributes is that it doesn't mean *anything*, which
 I suppose is useful for invented terminology, but it means it doesn't convey
 anything precise to those who haven't heard the term before. If it becomes
 widely used then that changes I guess. I'd still normally just use
 attributes though...

I'd read data attributes the same as non-method attributes.  For readers,
calling them attributes is typically sufficient.  It's rare to need to
distinguish them from methods.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 current position on this is that we should avoid the use of members,
because either use will confuse a large set of readers.

As Nick points out, these are all attributes, regardless of their
implementation or type of the value.  Methods is a convenient and widely
understood term to refer to a general class of attributes, when that actually
matches the meaning.

For non-method or not-necessarily-a-method attributes, I'm inclined to just
stick with calling them attributes at this point.

Even more important, we need to decide what to call them, and add appropriate
words to the glossary.  And then make the documentation match that.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 may be less significant than in the past.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
 additional desktops, such as KDE (Kubuntu) and Xfce (Xubuntu).

Of course, but I still think the default affects the rate of uptake.  I'm not
attacking Ubuntu, but I think the uptake rate is relevant to our current
discussion.

That said, the multi-monitor issues prevent my updating to 11.04.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 assignment caused it to be
considered a local in their function.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 standard Python type.

The types module pre-dates the time when classes were actually types in their
own right, and many of the built-in constructors, like float, int, and
list, were simply functions.  When that was the case:

 import types
 types.IntType == int
False

For types that have always been types, there's no corresponding entry in the
types module, nor is there any need for any, since the type itself is already
accessible.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 the front
of www.python.org.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 production use, but many do use our Windows installers.

Antoine,

I actually expect many companies build their own Python for production use;
relying on the system Python has long been considered a stability vulnerability
by many of us.  This is especially the case for large deployments,
where machines
are less likely to receive updates quickly.

I'd strongly recommend making sure releases are available for download quickly
in cases like this, even if (in any particular case) we think a vulnerability is
unlikely to affect many users.  Whenever we think something like that, we're
always wrong.


  -Fred

-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 exception.

Yep.

While I'm fine with folding away some of the verbose fields, the
current implementation is jarring.  I also get the flicker before the
fold happens, but the sentence describing status doesn't seem like a
good idea for regular users.  I would expect only the second box
from the top to get folded.

Making folding a per-user setting would be appropriate.


-- 
Fred L. Drake, Jr.    fdrake at acm.org
Give me the luxuries of life and I will willingly do without the necessities.
   --Frank Lloyd Wright
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 handling.  (I don't have the details handy, but vaguely
recall the two versions involved being 2.4 and 2.6.)


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
 handling.

Agreed; I don't use setuptools to manage versions of packages.  I've
found zc.buildout much nicer to work with, and entirely predictable
when applied properly.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 that modules and scripts are distinct, and
should never share a source file.  All the work that's going into
dealing with this just reinforces my position.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 something setuptools got very,
very right.  Probably not perfect, but... I've not yet needed anything
different in practice.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 like this as well.  Part of the problem is
that when we want URLs to specific versions (which might even mean
2.7.0), we use the version number as released, and... there's really
not a 2.7.0.  I'd love for us to include .0 in the actual release
number, instead of calling it just 2.7.  Then we could much more
easily handle this for docs, downloads, and anywhere else we want to
multi-plex multiple versions.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 are distributed
separately; for the standard library, we're not using it as a
namespace package in the same sense that is done with (for example)
the zope package.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
 unittest2 third-party module.  Also, he likes grepping the regular source
 and tests all at once.

I'm with Michael on this.

-1 on pushing all the tests into Lib/test/.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 point allowed itself to be overridden by
another package (_xmlplus specifically), however that was define.
Experience proved that this was a mistake.

Namespace packages, as originally defined by setuptools and applied
for the hurry, zc, and zope packages (and many others), are a very
different thing than what was done for the xml/_xmlplus package, and
have proven significantly more useful and usable.

While I heartily approve of namespace packages of that sort, I see
no reason to support installing into the same package namespace as the
standard library.  The primary disadvantage I see is that it would be
too easy to foster confusion over what's in the standard library among
newcomers.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove HTTP 0.9 support

[Fred Drake]

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 HTTP/0.9 responses appear to be in response to HTTP/0.9
requests only.  A request claiming to be HTTP 1.0, but without a Host:
header, gets a redirect to the same page.

I'm still in favor of removing HTTP 0.9 support entirely.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove HTTP 0.9 support

[Fred Drake]

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.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Remove HTTP 0.9 support

[Fred Drake]

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
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
NullHandler for that, that doesn't need to be turned off for
applications.  What it accomplishes is that for all messages sent to
the myns.mypackage logger (and descendants) are handled by at least
one handler.  Log records are still propagated toward the root for
outer loggers to handle.  An application can also still choose to
install additional handlers for myns.mypackage if desired, and do
whatever output handling is appropriate.

The library-installed NullHandler on a library-scoped logger simply
ensures that the library doesn't trigger the message about un-handled
log records.

We seem to have consensus on not wanting that message triggered for
library logging is desirable, and this NullHandler trick provides a
way to handle that independent from other possible changes.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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
except the message about logging not being configured. Propagation is
not controlled by the handlers, but by the loggers.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Repo frozen for 3.2

[Fred Drake]

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 vampire movies, of course!

I'd not recognize the current Safe* class names as a pattern; there
are currently two in the py3k trunk:

configparser.SafeConfigParser
-- very much a poor name

xmlrpc.client.SafeTransport
-- perhaps should have been SSLTransport or HTTPSTransport

I agree the Safe prefix isn't meaningful.  SafeConfigParser might
even be my fault.

Michael Foord has lobbied to end up with the preferred configparser
class to be named (eventually) ConfigParser, with good reason.  It's
not clear to me that we want to do that for backward compatibility
reasons (as I've argued elsewhere).  Were it not for that issue, I'd
be in favor of using different/better names.  (And there's still space
for better names, if we can create new names that avoid the b/w
compatibility issues.)


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Repo frozen for 3.2

[Fred Drake]

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.

string.Template.safe_substitute
Agree on this as well.

pydoc.safeimport
Not documented, so I don't really care what it's called.

 Never new there was so much danger in the standard library :-)

You should have known this, Raymond!  It's software.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Repo frozen for 3.2

[Fred Drake]

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 discuss this later on  when the time comes
 for that.

This is the hard part, though.  So long as the users decide whether to
use the interpolation features, it has to be treated as an API
compatibility issue.

The interpolation syntax is a feature of the language being parsed
more than a code-level feature.  It's actually a good thing logging is
using the ancient ConfigParser, since the interpolation handling is so
broken there's unlikely to be any affected uses of '%' in working
configurations.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 backward-compatibility perspective, what makes sense depends on
whether they're used to implement existing constants (socket.AF_INET,
etc.) or if they reserved for new features only.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 any
compelling reason to have a winner.

I'm generally in favor of enums (or whatever you want to call them),
and I'm in favor of importing support for the flavor you need, or just
defining constants in whatever way makes sense for your library or
application.

I don't see any problems that aren't solved by that.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Fred Drake]

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 don't have to repeat
 this debate in five years time.

Agreed again.

 My suggestion, which fits in with the use of __all__ by the language and
 also the convention widely in use by the community already boils down to:

 * If __all__ exists it is definitive

I think this is overly vague.  :-)

Specifically, if something is mentioned in __all__, it's public.
Non-inclusion in __all__ doesn't imply privateness.

 * Names with leading underscores are private unless in __all__ (and if you
 want to export leading underscore names as part of a public API you should
 define __all__ or import * won't export them)

We shouldn't confuse non-export via import * with non-public, however.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Fred Drake]

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.  They aren't a guide for 3rd-party code,
and are specific to the standard library.

If we can't come up with something reasonable for the standard
library, we *certainly* shouldn't be making recommendations on the
matter for 3rd party code.  If we do come up with something
reasonable, we can recommend it to others later (once field-proven),
and without duplication.  (Possibly by referring to the standard
library documentation, and possibly by refactoring.  That's not
important until we have something, though.)


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Fred Drake]

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, where it can be ignored by
those who aren't interested.

But the documentation is the right place to document what we come up
with for the standard library.  I expect what the tools do will inform
any decisions, and the tools (those in the stdlib) will henceforth be
maintained with that in mind.

I *am* suggesting that the scope of this be restricted to what's
appropriate for the standard library, rather than a general
recommendation for others.  Third-party projects are free to use what
we come up with, or provide their own policies.  That's theirs to
decide, and I see no value in interfering with that.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Fred Drake]

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 usage as well.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Fred Drake]

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 same documents frequently just to see if the set of recommendations
 I already know has changed recently.

Agreed.

Many style guides are written as extensions of PEP 8 in particular.
This has already bitten the Zope community, which was developing style
beyond what was even written in it's own extension, only to have PEP 8
change out from under it in a contrary manner.

Lessons we learned:

- If you refer to someone else's documents, refer to specific versions.
  References can be updated explicitly if desired.

- If you have even an advisory point of style, write it down in the style
  guide, so people who read the foundational documents you referred to
  without version information will be aware of the expectations.

Otherwise, you may as well not have one.


  -Fred

--
Fred L. Drake, Jr.fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 know a few projects that like to
deprecate things and would use this.  :-)


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Breaking undocumented API

[Fred Drake]

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 constant?

Since trace is documented and rx_blank isn't covered, I think it's
pretty clear it was never intended as API.  I'd be fine with changing
the visibility of rx_blank, and see no need to change its name.

 Another specific case is token.main.  See http://bugs.python.org/issue10386.

Yep.  Again, it's clear that it's not API, and that's a documented module.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 underscores as hints, and many others which
don't.

Other people consider the presence of a docstring on a non-underscored
name significant, while still others refer to the out-of-line
documentation as definitive.

For modules, an __all__ attribute is generally agreed on as definitive,
if present, but that's a fairly limited case.

At this point, there isn't a single clear way to determine if something
is public API.  I doubt it will be likely to agree on a single
definition now without engendering a lengthy discussion on whether names
can be changed to reflect such a policy (where backward compatibility is
sure to be lost).

I'm sticking to the out-of-line documentation to determine what's public.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 else we agree on.  2000-line modules are
a source of maintenance pain.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

[Fred Drake]

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 installs.

- make install would then add links without the version numbers.

This mirrors the name of the Python executable, so is likely as right as
it's going to get (*if* we install separate scripts).

Georg:
 What happened to python setup.py action?  Or is this a step towards
 not requiring setup.py at all?

I'm in favor of add a top-level setup module that can be invoked using
python -m setup   There will be three cases:

- d2 projects without a setup.py, where this will invoke the module from
  the standard library,

- d2 projects with a setup.py, where the local setup.py will be invoked,
  and

- d1 projects, which always have a setup.py, which will be invoked.

This would provide the most consistent story for package users, where the
only command they'll need to remember (for Python versions with the setup
module) will be

python -m setup ...


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Distutils2 scripts

[Fred Drake]

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 without setup.py entirely, in
all cases?  I guess I've been busy elsewhere lately.

 Some project might want to provide both setups for backward
 compatibility:

 - a setup.py (d1)
 - a setup,cfg (d2 and optionally some d1 options)

If a project requites setup.py for any reason, it can include the
compatibility it needs there, even if there is sometimes a need for d2
to use a setup.py:


try:
import distutils2
except ImportError:
import distutils.core
distutils.core.setup(...)
else:
distutils2.core.setup()

Anyway, the pysetup name offered in tis thread works for me as well.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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,

This makes a lot of sense; having to branch  get spelling corrections
in docs or comments would be a *huge* pain, and not provide value.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Atlassian and bitbucket merge

[Fred Drake]

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 a
problem, why don't we convert and see how it goes?  If we discover
problems doing so and think a hosted solution would solve them, we can
reconsider then.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 several pieces are uploaded which
really constitute a single change; often docs and/or tests are
provided separately, just because we've had to go back and ask for
them.  Sometimes they're provided by a separate contributor.

Keeping the numbers aligned could probably be done based on the file
number containing the patch, assuming those are never reused (I don't
think they are, but haven't dug deep enough into roundup).


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Fred Drake]

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 elsewhere as well, but I was paying
less attention at the time.

 Of course, we might consider a separate HG repository (I'm all in favor
 of many small repos, instead of a gigantic sandbox one).  The downside
 is that I really like the developer docs at docs.python.org, and it
 would complicate the build process a bit.

Perhaps someone here knows enough about our documentation toolchain to
figure out a way to generate a link from the docs to developer docs on
the website.  :-)

I expect only a very small part of the audience for the general Python
documentation  CPython docs are particularly interested in the
development process we use, and sending them to the website from a
convenient link is not a bad thing.  We won't even need a new
repository to do that.


  -Fred

--
Fred L. Drake, Jr.    fdrake at acm.org
A storm broke loose in my mind.  --Albert Einstein
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com