Re: [Python-Dev] Migrate python-dev to Mailman 3?

[Nick Coghlan]

On 27 October 2017 at 00:28, Wes Turner  wrote:

>
> On Thursday, October 26, 2017, Paul Moore  wrote:
>
>> So basically, what I'm asking is what would be the support for the use
>> case "Find a permanent link to an archived article as fast as possible
>> based on subject/author or a Google search".
>
>
> The complexity of this process is also very wastefully frustrating to me.
> (Maybe it's in the next month's message tree? No fulltext search? No way to
> even do an inurl: search because of the URIs?!)
>
> Isn't there a way to append a permalink to the relayed message footers?
> Google Groups and Github do this and it saves a lot of time.
>

MM3 injects an Archived-At header, as the permalink URLs for individual
messages are generated based on a hash of a suitable subset of the message
headers (I don't know if it's possible to opt-in to including those in the
message footer or not, though).

As Barry explained, this isn't possible with pipermail, as those archive
URLs are dynamically generated and are completely independent of the
message contents and metadata (this is also why you can't safely delete
messages from MM2 archives: doing so will renumber the archive URLs for all
subsequent messages).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 561: Distributing and Packaging Type Information

[Guido van Rossum]

Heh, you're right that was the reasoning. But I think python-list is much
less valuable than python-ideas for PEP authors. So let's change it.


On Thu, Oct 26, 2017 at 6:38 PM, Barry Warsaw  wrote:

> On Oct 26, 2017, at 20:03, Guido van Rossum  wrote:
> >
> > I think python-ideas does count here. Many PEPs evolve mostly there.
>
> True, but there was some discussion of this way back when.
>
> The way I remember it was that, while there are many outlets to discuss
> PEPs (including those pointed to by the optional Discussions-To header),
> python-dev is the “forum of record”.  This means that python-dev is the
> only mailing list you *have* to follow if you want to be informed of a
> PEP’s status in a timely manner.  Thus Post-History is supposed to reflect
> the history of when the PEP is sent to python-dev.  python-list is included
> because it’s the primary mailing list followed by people who aren’t
> developing Python but are still interested in it.
>
> Maybe this needs to be reconsidered here in 2017, but that’s the rationale
> for the wording of PEP 1.
>
> Cheers,
> -Barry
>
>
> ___
> 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/
> guido%40python.org
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
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] Migrate python-dev to Mailman 3?

[Barry Warsaw]

On Oct 26, 2017, at 10:01, Donald Stufft  wrote:

> Pipermail is *horrible*

Pipermail also has a fatal flaw, and we have been hit by it several times in 
our past.  It’s fundamental to Pipermail’s design and can’t be fixed.  
Fortunately, HyperKitty was designed and implemented correctly so it doesn’t 
suffer this flaw.

Pipermail indexes messages sequentially, and if you ever regenerate the archive 
from the source mbox, it’s is almost guaranteed that your messages will get 
different URLs.  Worse, you can’t even automate a mapping from new URLs to old 
URLs.  This is especially likely in archives that go back as far as python-dev 
does, because there was a bug back in the day where even the source mbox file 
got corrupted, where the separator between messages was broken.  We tried to 
implement a fix for that, but it’s a heuristic and it’s not perfect.

We say that Pipermail does not have “stable urls”.  Thankfully HyperKitty does! 
 So even if you regenerate the HyperKitty archive, your messages will end up 
with the same URLs.

This let’s us implement Archived-At stably, and the algorithm at [1] even lets 
us pre-calculate the URL, so we can even include the URL to where the message 
*will* be once it’s archived, even without talking to HyperKitty, or any of the 
other archivers that are enabled (and support the algorithm of course).

So HyperKitty is miles ahead of Pipermail in design and implementation.  Sure 
it’s different, but people also forget how really buggy Pipermail was for a 
long time.  (And trust me, you really don’t even want to look at the code. ;)

Cheers,
-Barry

[1] https://wiki.list.org/DEV/Stable%20URLs


signature.asc
Description: Message signed with OpenPGP
___
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] Migrate python-dev to Mailman 3?

[Barry Warsaw]

On Oct 26, 2017, at 06:15, Victor Stinner  wrote:

> I don't think that Mailman 3 gives the choice of the UI for archives.

Technically, it does.

Mailman 3 has a pluggable architecture and supports multiple archives enabled 
site-wide and opt-in by individual lists.  HyperKitty is the default archiver, 
and the one we promote, but it doesn’t have to be the only archiver enabled.  
In fact, we come with plugins for mail-archive.com and MHonarc.  It *might* 
even be possible to enable a standalone Pipermail and route messages to that if 
one were so inclined.  The choice of archivers is not mutually exclusive.

Practically speaking though, there just aren’t a ton of well maintained FLOSS 
archivers to choose from.  HyperKitty *is* well maintained.  Frankly speaking, 
Pipermail is not.

Cheers,
-Barry




signature.asc
Description: Message signed with OpenPGP
___
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 561: Distributing and Packaging Type Information

[Barry Warsaw]

On Oct 26, 2017, at 20:03, Guido van Rossum  wrote:
> 
> I think python-ideas does count here. Many PEPs evolve mostly there.

True, but there was some discussion of this way back when.

The way I remember it was that, while there are many outlets to discuss PEPs 
(including those pointed to by the optional Discussions-To header), python-dev 
is the “forum of record”.  This means that python-dev is the only mailing list 
you *have* to follow if you want to be informed of a PEP’s status in a timely 
manner.  Thus Post-History is supposed to reflect the history of when the PEP 
is sent to python-dev.  python-list is included because it’s the primary 
mailing list followed by people who aren’t developing Python but are still 
interested in it.

Maybe this needs to be reconsidered here in 2017, but that’s the rationale for 
the wording of PEP 1.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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 561: Distributing and Packaging Type Information

[Oleg Broytman]

Proposed pull request: https://github.com/python/peps/pull/441

On Thu, Oct 26, 2017 at 05:21:57PM -0700, Mariatta Wijaya 
 wrote:
> Ok I created an issue https://github.com/python/peps/issues/440, maybe
> someone can work on updating the wordings in PEP 1 and PEP 12.
> Thanks :)
> 
> Mariatta Wijaya
> 
> On Thu, Oct 26, 2017 at 5:03 PM, Guido van Rossum 
> wrote:
> 
> > I think python-ideas does count here. Many PEPs evolve mostly there.

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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 561: Distributing and Packaging Type Information

[Mariatta Wijaya]

Ok I created an issue https://github.com/python/peps/issues/440, maybe
someone can work on updating the wordings in PEP 1 and PEP 12.
Thanks :)

Mariatta Wijaya

On Thu, Oct 26, 2017 at 5:03 PM, Guido van Rossum 
wrote:

> I think python-ideas does count here. Many PEPs evolve mostly there.
>
>
>
___
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 561: Distributing and Packaging Type Information

[Guido van Rossum]

I think python-ideas does count here. Many PEPs evolve mostly there.

On Oct 26, 2017 4:59 PM, "Oleg Broytman"  wrote:

> On Thu, Oct 26, 2017 at 04:48:23PM -0700, Mariatta Wijaya <
> mariatta.wij...@gmail.com> wrote:
> > >
> > > Not sure if postings to python-ideas count,
> >
> > PEP 1 says:
> >
> > Post-History is used to record the dates of when new versions of the PEP
> > are posted to python-list and/or python-dev.
>
>That's was added in 2003:
> https://hg.python.org/peps/annotate/96614829c145/pep-0001.txt
> https://github.com/python/peps/commit/0a690292ffe2cdc547dbad3bdbdb46
> 672012b536
>I don't remember if python-ideas has already been created. ;-)
>
> > So, no ?
>
>I'm not so sure. :-)
>
> > Mariatta Wijaya
>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> 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/
> guido%40python.org
>
___
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 561: Distributing and Packaging Type Information

[Ethan Smith]

On Thu, Oct 26, 2017 at 4:48 PM, Mariatta Wijaya 
wrote:

> Not sure if postings to python-ideas count,
>
>
> PEP 1 says:
>
> Post-History is used to record the dates of when new versions of the PEP
> are posted to python-list and/or python-dev.
>
> So, no ?
>


Reading PEP 12, https://www.python.org/dev/peps/pep-0012/#id24


   -

   Leave Post-History alone for now; you'll add dates to this header each
   time you post your PEP to python-l...@python.org or python-dev@python.org.
   If you posted your PEP to the lists on August 14, 2001 and September 3,
   2001, the Post-History header would look like:

   Post-History: 14-Aug-2001, 03-Sept-2001

   You must manually add new dates and check them in. If you don't have
   check-in privileges, send your changes to the PEP editors.

Perhaps it is outdated and needs to have python-ideas added? python-ideas
was created around 2006 (according to the archives), so after PEP 1/12 were
written.


> This PEP adds a new item to the
> ``*.distinfo/METADATA`` file

   *.dist-info/

Thank you for catching that. I will fix that with my next round of edits.
___
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 561: Distributing and Packaging Type Information

[Oleg Broytman]

On Thu, Oct 26, 2017 at 04:48:23PM -0700, Mariatta Wijaya 
 wrote:
> >
> > Not sure if postings to python-ideas count,
> 
> PEP 1 says:
> 
> Post-History is used to record the dates of when new versions of the PEP
> are posted to python-list and/or python-dev.

   That's was added in 2003:
https://hg.python.org/peps/annotate/96614829c145/pep-0001.txt
https://github.com/python/peps/commit/0a690292ffe2cdc547dbad3bdbdb46672012b536
   I don't remember if python-ideas has already been created. ;-)

> So, no ?

   I'm not so sure. :-)

> Mariatta Wijaya

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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 561: Distributing and Packaging Type Information

[Mariatta Wijaya]

>
> Not sure if postings to python-ideas count,


PEP 1 says:

Post-History is used to record the dates of when new versions of the PEP
are posted to python-list and/or python-dev.

So, no ?

Mariatta Wijaya
___
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 561: Distributing and Packaging Type Information

[Oleg Broytman]

Hi!

On Thu, Oct 26, 2017 at 03:42:19PM -0700, Ethan Smith  wrote:
> Post-History:

   Not sure if postings to python-ideas count, but

Post-History: 10-Sep-2017, 12-Sep-2017, 26-Oct-2017

   Refs:
https://mail.python.org/pipermail/python-ideas/2017-September/047015.html
https://mail.python.org/pipermail/python-ideas/2017-September/047083.html

> This PEP adds a new item to the
> ``*.distinfo/METADATA`` file

   *.dist-info/

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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

[Python-Dev] PEP 561: Distributing and Packaging Type Information

[Ethan Smith]

Hello all,

I have completed an implementation for PEP 561, and believe it is time to
share the PEP and implementation with python-dev

Python-ideas threads:
 * PEP 561: Distributing and Packaging Type Information
 * PEP 561 v2 - Packaging Static Type Information
 * PEP 561: Distributing Type Information V3

The live version is here: https://www.python.org/dev/peps/pep-0561/

As always, duplicated below.

Ethan Smith

---

PEP: 561
Title: Distributing and Packaging Type Information
Author: Ethan Smith 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 09-Sep-2017
Python-Version: 3.7
Post-History:


Abstract


PEP 484 introduced type hinting to Python, with goals of making typing
gradual and easy to adopt. Currently, typing information must be distributed
manually. This PEP provides a standardized means to package and distribute
type information and an ordering for type checkers to resolve modules and
collect this information for type checking using existing packaging
architecture.


Rationale
=

Currently, package authors wish to distribute code that has
inline type information. However, there is no standard method to distribute
packages with inline type annotations or syntax that can simultaneously
be used at runtime and in type checking. Additionally, if one wished to
ship typing information privately the only method would be via setting
``MYPYPATH`` or the equivalent to manually point to stubs. If the package
can be released publicly, it can be added to typeshed [1]_. However, this
does not scale and becomes a burden on the maintainers of typeshed.
Additionally, it ties bugfixes to releases of the tool using typeshed.

PEP 484 has a brief section on distributing typing information. In this
section [2]_ the PEP recommends using ``shared/typehints/pythonX.Y/`` for
shipping stub files. However, manually adding a path to stub files for each
third party library does not scale. The simplest approach people have taken
is to add ``site-packages`` to their ``MYPYPATH``, but this causes type
checkers to fail on packages that are highly dynamic (e.g. sqlalchemy
and Django).


Specification
=

There are several motivations and methods of supporting typing in a package.
This PEP recognizes three (3) types of packages that may be created:

1. The package maintainer would like to add type information inline.

2. The package maintainer would like to add type information via stubs.

3. A third party would like to share stub files for a package, but the
   maintainer does not want to include them in the source of the package.

This PEP aims to support these scenarios and make them simple to add to
packaging and deployment.

The two major parts of this specification are the packaging specifications
and the resolution order for resolving module type information. The packaging
spec is based on and extends PEP 345 metadata. The type checking spec is
meant to replace the ``shared/typehints/pythonX.Y/`` spec of PEP 484 [2]_.

New third party stub libraries are encouraged to distribute stubs via the
third party packaging proposed in this PEP in place of being added to
typeshed. Typeshed will remain in use, but if maintainers are found, third
party stubs in typeshed are encouraged to be split into their own package.

Packaging Type Information
--
In order to make packaging and distributing type information as simple and
easy as possible, the distribution of type information, and typed Python code
is done through existing packaging frameworks. This PEP adds a new item to the
``*.distinfo/METADATA`` file to contain metadata about a package's support for
typing. The new item is optional, but must have a name of ``Typed`` and have a
value of either ``inline`` or ``stubs``, if present.

Metadata Examples::

Typed: inline
Typed: stubs


Stub Only Packages
''

For package maintainers wishing to ship stub files containing all of their
type information, it is prefered that the ``*.pyi`` stubs are alongside the
corresponding ``*.py`` files. However, the stubs may be put in a sub-folder
of the Python sources, with the same name the ``*.py`` files are in. For
example, the ``flyingcircus`` package would have its stubs in the folder
``flyingcircus/flyingcircus/``. This path is chosen so that if stubs are
not found in ``flyingcircus/`` the type checker may treat the subdirectory as
a normal package. The normal resolution order of checking ``*.pyi`` before
``*.py`` will be maintained.

Third Party Stub Packages
'

Third parties seeking to distribute stub files are encouraged to contact the
maintainer of the package about distribution alongside the package. If the
maintainer does not wish to maintain or package stub files or type information
inline, then a "third party stub package" should be created. The structure is
similar, but slightly different from that of stub only packages

Re: [Python-Dev] Migrate python-dev to Mailman 3?

[Wes Turner]

On Thursday, October 26, 2017, Mark Sapiro  wrote:

> On 10/26/2017 07:28 AM, Wes Turner wrote:
> >
> >
> > On Thursday, October 26, 2017, Paul Moore  > wrote:
> >
> > On 26 October 2017 at 10:24, Victor Stinner
> > > wrote:
> > > We are using Mailman 3 for the new buildbot-status mailing list
> and it
> > > works well:
> > >
> > >
> > https://mail.python.org/mm3/archives/list/buildbot-status@
> python.org/
> > >
> ...
> >
> > My only use of the pipermail archives is to find permanent URLs for
> > mails I want to refer people to. My usage goes as follows:
> >
> > 1. Google search for a post.
> > 2. Paste in the URL to an email.
> >
> > Or, if I have the post already (usually in my email client).
> >
> > 1. Check the date and subject of the post.
> > 2. Go to the pipermail article by month, and scan the list for the
> > subject and author.
> > 3. Click on the link, check it's the right email, copy the URL.
> > 4. Paste it into my email.
> >
> > I don't use the archives for reading. If the above two usages are
> > still available, I don't care. But in particular, the fact that
> > individual posts are searchable from Google is important to me.
>
>
> A Google search narrowed with "site:mail.python.org" and perhaps
> "inurl:listn...@python.org " works for HyperKitty archives
> as well. Also,
> the archive itself has a "search this list" box.


Gmail also supports "list:python.org" now.


>
>
> ...> The complexity of this process is also very wastefully frustrating to
> > me. (Maybe it's in the next month's message tree? No fulltext search? No
> > way to even do an inurl: search because of the URIs?!)
>
>
> I don't see these issues. There is a full text search box on the archive
> page and I don't see the problem with Google inurl:


This URL style would work with inurl:

inurl:x.TLD/THREADID/msgid

These can't span across the year-month or otherwise catch other threads in
the result set:

inurl:mail.python.org/pipermail/astropy/2017-September/0001.html
inurl:mail.python.org/pipermail/astropy/2018-January/0002.html



>
>
> > Isn't there a way to append a permalink to the relayed message footers?
> > Google Groups and Github do this and it saves a lot of time.
>
>
> As you note below, there is an Archived-At: header. I have just
> submitted an RFE at  to
> enable placing this in the message header/footer.
>
>
> > [Re-searches for things]
> >
> > Mailman3 adds an RFC 5064 "Archived-At" header with a link that some
> > clients provide the ability to open in a normal human browser:
> >
> > http://dustymabe.com/2016/01/10/archived-at-email-header-
> from-mailman-3-lists/
> >
> > I often click the "view it on Github" link in GitHub issue emails. (It's
> > after the '--' email signature delimiter, so it doesn't take up so much
> > room).
> >
> > "[feature] Add permalink to mail message to the footer when delivering
> > email"
> > https://gitlab.com/mailman/hyperkitty/issues/27
>
>
> This needs to be in Mailman Core, not HyperKitty. As I note above, I
> filed an RFE with core and also referenced it in the HyperKitty issue


Thanks!


>
>
> > Finally, how would a transition be handled? I assume the old archives
> > would be retained, so would there be a cut-off date and people would
> > have to know to use the old or new archives based on the date of the
> > message?
> >
> >
> > Could an HTTP redirect help with directing users to the new or old
> archives?
>
>
> What we did when migrating security-sig is we migrated the archive but
> kept the old one and added this message and link to the old archive page.
>
> "This list has been migrated to Mailman 3. This archive is not being
> updated. Here is the new archive including these old posts."
>
> We also redirected
>  to
> .
>
> We purposely didn't redirect the old archive so that saved URLs would
> still work.
>
> We did the same things for security-announce and clearly can do the same
> for future migrations.


Great.


>
> Finally note that Mailman 3 supports archivers other than HyperKitty.
> For example, one can configure a list to archive at
> www.mail-archive.com, in such a way that the Archived-At: permalink
> points to the message at www.mail-archive.com.


Someday someone will have the time to implement this in e.g. posterious or
hyperkitty or from a complete mbox:
https://github.com/westurner/wiki/wiki/ideas#open-source-mailing-list-extractor

Thanks again!


>
> --
> Mark Sapiro >The highway is for
> gamblers,
> San Francisco Bay Area, Californiabetter use your sense - B. Dylan
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python

Re: [Python-Dev] iso8601 parsing

[Wes Turner]

On Thursday, October 26, 2017, Chris Barker  wrote:

> On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner  > wrote:
>
>> ISO 8601 support offsets, but not time zones -- presumably the __str__
>>> supports the full datetime tzinfo somehow. Which may be why .isoformat()
>>> exists.
>>>
>>
>> ISO8601 does support timezones.
>> https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
>>
>
> No, it doesn't -- it may call them "timezones", but it only supports
> offsets -- that is, and offset of -6 could be US Eastern Standard Time or
> US Central Daylight TIme (or I got that backwards :-)  )
>
> The point is that an offset is really easy, and timezones (with Daylight
> savings and all that) are a frickin' nightmare, but ARE supported by
> datetime
>
> Note that the vocabulary is not precise here, as I see this in the Pyton
> docs:
>
> *class *datetime.timezone
>
> A class that implements the tzinfo
>  abstract
> base class as a fixed offset from the UTC.
> So THAT is supported by iso8601, and, indeed maps naturally to it.
>

Got it, thanks.


>
> Which means we can round trip isp8601 datetimes nicely, but can't round
> trip a datetime with a "full featured" tzinfo attached.
>

Because an iso8601 string only persists the offset.


>
> I don't think this really has any impact on the proposal, though: it's
> clear what to do when parsing a iso Datetime.
>
> I might be wrong, but I think many of the third party libraries listed
>> here default to either UTC or timezone-naieve timezones:
>> https://github.com/vinta/awesome-python/blob/master/README.
>> md#date-and-time
>>
>
> This is a key point that I hope is obvious:
>
>

> If an ISO string has NO offset or timezone indicator, then a naive
> datetime should be created.
>


>
> (I say, I "hope" it's obvious, because the numpy datetime64 implementation
> initially (and for years) would apply the machine local timezone to a bare
> iso string -- which was a f-ing nightmare!)
>

astropy.time.Time supports numpy.


>
>
>> Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it
>> with my local time.
>>
>> Here's an example with a *custom* GMT1 tzinfo subclass:
>> https://docs.python.org/3/library/datetime.html#datetime.time.tzname
>>
>
> Here it is:
>
> class GMT1(tzinfo):
> def utcoffset(self, dt):
> return timedelta(hours=1)
> def dst(self, dt):
> return timedelta(0)
> def tzname(self,dt):
> return "Europe/Prague"
>
> I hope Prague doesn't do DST, or that would be just wrong ...
>

Pendulum seems to have a faster timezone lookup than pytz:

https://pendulum.eustace.io/blog/a-faster-alternative-to-pyz.html

Both pendulum and pytz are in conda-forge (the new basis for the anaconda
distribution).


>
> What would you call the str argument? Does it accept strptime args or only
>> ISO8601?
>>
>
> I think Fred answered this, but iso 8601 only. we already have strptime if
> you need to parse anything else.
>
> Would all of that string parsing logic be a performance regression from
>> the current constructor? Does it accept None or empty string?
>>
>
> I suppose you need to do a little type checking first, so a tiny one.
>
> Though maybe just catching an Exception, so really tiny.
>
> The current constructor only takes numbers, so yes the string parsing
> version would be slower, but only if you use it...
>
> Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601))
>> types is nasty, regardless (try/except, *custom* schema awareness). And
>> pickle is dangerous.
>>
>> AFAIU, we should not ever eval(repr(dt: datetime)).
>>
>
> why not? isn't that what __repr__ is supposed to do?
>

repr(dict) now returns ellipses ... for cyclical dicts; so I'm assuming
that repr only MAY be eval'able.


>
> Or do you mean not that it shouldn't work, but that we shouldn't do it?
>

That
We shouldn't ever eval untrusted data / code.
(That's why we need package hashes, signatures, and TUF).


>
> -CHB
>
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE
> 
>   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
> 
>
___
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] Migrate python-dev to Mailman 3?

[Mark Sapiro]

On 10/26/2017 07:28 AM, Wes Turner wrote:
> 
> 
> On Thursday, October 26, 2017, Paul Moore  wrote:
> 
> On 26 October 2017 at 10:24, Victor Stinner
>  wrote:
> > We are using Mailman 3 for the new buildbot-status mailing list and it
> > works well:
> >
> >
> https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
> >
...
> 
> My only use of the pipermail archives is to find permanent URLs for
> mails I want to refer people to. My usage goes as follows:
> 
> 1. Google search for a post.
> 2. Paste in the URL to an email.
> 
> Or, if I have the post already (usually in my email client).
> 
> 1. Check the date and subject of the post.
> 2. Go to the pipermail article by month, and scan the list for the
> subject and author.
> 3. Click on the link, check it's the right email, copy the URL.
> 4. Paste it into my email.
> 
> I don't use the archives for reading. If the above two usages are
> still available, I don't care. But in particular, the fact that
> individual posts are searchable from Google is important to me.


A Google search narrowed with "site:mail.python.org" and perhaps
"inurl:listn...@python.org" works for HyperKitty archives as well. Also,
the archive itself has a "search this list" box.


...> The complexity of this process is also very wastefully frustrating to
> me. (Maybe it's in the next month's message tree? No fulltext search? No
> way to even do an inurl: search because of the URIs?!)


I don't see these issues. There is a full text search box on the archive
page and I don't see the problem with Google inurl:


> Isn't there a way to append a permalink to the relayed message footers?
> Google Groups and Github do this and it saves a lot of time.


As you note below, there is an Archived-At: header. I have just
submitted an RFE at  to
enable placing this in the message header/footer.


> [Re-searches for things]
> 
> Mailman3 adds an RFC 5064 "Archived-At" header with a link that some
> clients provide the ability to open in a normal human browser:
> 
> http://dustymabe.com/2016/01/10/archived-at-email-header-from-mailman-3-lists/
> 
> I often click the "view it on Github" link in GitHub issue emails. (It's
> after the '--' email signature delimiter, so it doesn't take up so much
> room).
>  
> "[feature] Add permalink to mail message to the footer when delivering
> email"
> https://gitlab.com/mailman/hyperkitty/issues/27


This needs to be in Mailman Core, not HyperKitty. As I note above, I
filed an RFE with core and also referenced it in the HyperKitty issue


> Finally, how would a transition be handled? I assume the old archives
> would be retained, so would there be a cut-off date and people would
> have to know to use the old or new archives based on the date of the
> message?
> 
> 
> Could an HTTP redirect help with directing users to the new or old archives?


What we did when migrating security-sig is we migrated the archive but
kept the old one and added this message and link to the old archive page.

"This list has been migrated to Mailman 3. This archive is not being
updated. Here is the new archive including these old posts."

We also redirected
 to
.

We purposely didn't redirect the old archive so that saved URLs would
still work.

We did the same things for security-announce and clearly can do the same
for future migrations.

Finally note that Mailman 3 supports archivers other than HyperKitty.
For example, one can configure a list to archive at
www.mail-archive.com, in such a way that the Archived-At: permalink
points to the message at www.mail-archive.com.

-- 
Mark Sapiro The highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
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

[Alex Walters]

 

 

From: Python-Dev [mailto:python-dev-bounces+tritium-list=sdamon@python.org] 
On Behalf Of Chris Barker
Sent: Thursday, October 26, 2017 12:46 PM
To: Wes Turner 
Cc: Python-Dev 
Subject: Re: [Python-Dev] iso8601 parsing

 

> No, it doesn't -- it may call them "timezones", but it only supports offsets 
> -- that is, and offset of -6 could be US Eastern Standard Time or US Central 
> Daylight TIme (or I got that backwards :-)  )

 

US Central Standard, Mountain Daylight.  (Eastern is -5/-4DST)

___
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

[Chris Barker]

On Wed, Oct 25, 2017 at 7:37 PM, Wes Turner  wrote:

> ISO 8601 support offsets, but not time zones -- presumably the __str__
>> supports the full datetime tzinfo somehow. Which may be why .isoformat()
>> exists.
>>
>
> ISO8601 does support timezones.
> https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators
>

No, it doesn't -- it may call them "timezones", but it only supports
offsets -- that is, and offset of -6 could be US Eastern Standard Time or
US Central Daylight TIme (or I got that backwards :-)  )

The point is that an offset is really easy, and timezones (with Daylight
savings and all that) are a frickin' nightmare, but ARE supported by
datetime

Note that the vocabulary is not precise here, as I see this in the Pyton
docs:

*class *datetime.timezone

A class that implements the tzinfo
 abstract
base class as a fixed offset from the UTC.
So THAT is supported by iso8601, and, indeed maps naturally to it.

Which means we can round trip isp8601 datetimes nicely, but can't round
trip a datetime with a "full featured" tzinfo attached.

I don't think this really has any impact on the proposal, though: it's
clear what to do when parsing a iso Datetime.

I might be wrong, but I think many of the third party libraries listed here
> default to either UTC or timezone-naieve timezones:
> https://github.com/vinta/awesome-python/blob/master/
> README.md#date-and-time
>

This is a key point that I hope is obvious:

If an ISO string has NO offset or timezone indicator, then a naive datetime
should be created.

(I say, I "hope" it's obvious, because the numpy datetime64 implementation
initially (and for years) would apply the machine local timezone to a bare
iso string -- which was a f-ing nightmare!)


> Ctrl-F for 'tzinfo=' in the docs really doesn't explain how to just do it
> with my local time.
>
> Here's an example with a *custom* GMT1 tzinfo subclass:
> https://docs.python.org/3/library/datetime.html#datetime.time.tzname
>

Here it is:

class GMT1(tzinfo):
def utcoffset(self, dt):
return timedelta(hours=1)
def dst(self, dt):
return timedelta(0)
def tzname(self,dt):
return "Europe/Prague"

I hope Prague doesn't do DST, or that would be just wrong ...

What would you call the str argument? Does it accept strptime args or only
> ISO8601?
>

I think Fred answered this, but iso 8601 only. we already have strptime if
you need to parse anything else.

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

I suppose you need to do a little type checking first, so a tiny one.

Though maybe just catching an Exception, so really tiny.

The current constructor only takes numbers, so yes the string parsing
version would be slower, but only if you use it...

Deserializing dates from JSON (without #JSONLD and xsd:dateTime (ISO8601))
> types is nasty, regardless (try/except, *custom* schema awareness). And
> pickle is dangerous.
>
> AFAIU, we should not ever eval(repr(dt: datetime)).
>

why not? isn't that what __repr__ is supposed to do?

Or do you mean not that it shouldn't work, but that we shouldn't do it?

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Migrate python-dev to Mailman 3?

[Wes Turner]

On Thursday, October 26, 2017, Paul Moore  wrote:

> On 26 October 2017 at 10:24, Victor Stinner  > wrote:
> > We are using Mailman 3 for the new buildbot-status mailing list and it
> > works well:
> >
> > https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
> >
> > I prefer to read archives with this UI, it's simpler to follow
> > threads, and it's possible to reply on the web UI!
> >
> > To be honest, we got some issues when the new security-announce
> > mailing list was quickly migrated from Mailman 2 to Mailman 3, but
> > issues were quicky fixed as well.
> >
> > Would it be possible to migrate python-dev to Mailman 3? Do you see
> > any blocker issue?
> >
> > I sent to email to the Python postmaster as well.
>
> My only use of the pipermail archives is to find permanent URLs for
> mails I want to refer people to. My usage goes as follows:
>
> 1. Google search for a post.
> 2. Paste in the URL to an email.
>
> Or, if I have the post already (usually in my email client).
>
> 1. Check the date and subject of the post.
> 2. Go to the pipermail article by month, and scan the list for the
> subject and author.
> 3. Click on the link, check it's the right email, copy the URL.
> 4. Paste it into my email.
>
> I don't use the archives for reading. If the above two usages are
> still available, I don't care. But in particular, the fact that
> individual posts are searchable from Google is important to me. And in
> the second usage, having a single scrollable webpage with no
> extraneous data just subject/author and a bit of threading by
> indentation speeds up my usage a lot - the UI you linked to (and the
> monthly archive page with the initial lines of postings on it) is FAR
> too cluttered to be usable for my purposes.
>
>
This:


> So basically, what I'm asking is what would be the support for the use
> case "Find a permanent link to an archived article as fast as possible
> based on subject/author or a Google search".


The complexity of this process is also very wastefully frustrating to me.
(Maybe it's in the next month's message tree? No fulltext search? No way to
even do an inurl: search because of the URIs?!)

Isn't there a way to append a permalink to the relayed message footers?
Google Groups and Github do this and it saves a lot of time.

[Re-searches for things]

Mailman3 adds an RFC 5064 "Archived-At" header with a link that some
clients provide the ability to open in a normal human browser:

http://dustymabe.com/2016/01/10/archived-at-email-header-from-mailman-3-lists/

I often click the "view it on Github" link in GitHub issue emails. (It's
after the '--' email signature delimiter, so it doesn't take up so much
room).

"[feature] Add permalink to mail message to the footer when delivering
email"
https://gitlab.com/mailman/hyperkitty/issues/27


> Finally, how would a transition be handled? I assume the old archives
> would be retained, so would there be a cut-off date and people would
> have to know to use the old or new archives based on the date of the
> message?


Could an HTTP redirect help with directing users to the new or old archives?


>
> Paul
> ___
> 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/
> wes.turner%40gmail.com
>
___
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] Migrate python-dev to Mailman 3?

[Antoine Pitrou]

Le 26/10/2017 à 16:01, Donald Stufft a écrit :
> 
>> On Oct 26, 2017, at 6:19 AM, Antoine Pitrou > > wrote:
>>
>> The pipermail UI isn't perfect (the monthly segregation can be annoying
>> as you point out), but at least it has a synthetic and easy-to-navigate
>> tree view.
> 
> Pipermail is *horrible* and it’s tree view makes things actively harder
> to read in large part because once the depth of the tree gets beyond
> like,, 3? or so, it just gives up trying to make it a tree and starts
> rendering all descendants past a certain point as siblings in a
> nonsensical order making it impossible to follow along on a discussion
> as everything ends up out of order.

You're right.  It shows that I'm used to pipermail's deficiencies, and
don't notice them as much as I used to do.

However, MM3 seems to be doing the exact same thing that pipermail does
when it comes to capping the tree view indentation to a certain limit.

If you scroll down the following page enough (or you can search for
example the sentence "I don't believe anyone outside of Firefox
enthusiasts and the package maintainer were even aware there was an
issue to discuss"), you'll see some replies displayed at the same
indentation level as the message they reply to:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/K5HSROMAIMNYSJONB5EIAQKWKYNFYSHK/

Regards

Antoine.
___
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] Migrate python-dev to Mailman 3?

[Donald Stufft]

> On Oct 26, 2017, at 6:19 AM, Antoine Pitrou  wrote:
> 
> The pipermail UI isn't perfect (the monthly segregation can be annoying
> as you point out), but at least it has a synthetic and easy-to-navigate
> tree view.

Pipermail is *horrible* and it’s tree view makes things actively harder to read 
in large part because once the depth of the tree gets beyond like,, 3? or so, 
it just gives up trying to make it a tree and starts rendering all descendants 
past a certain point as siblings in a nonsensical order making it impossible to 
follow along on a discussion as everything ends up out of order.___
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] Migrate python-dev to Mailman 3?

[Paul Moore]

On 26 October 2017 at 10:24, Victor Stinner  wrote:
> We are using Mailman 3 for the new buildbot-status mailing list and it
> works well:
>
> https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
>
> I prefer to read archives with this UI, it's simpler to follow
> threads, and it's possible to reply on the web UI!
>
> To be honest, we got some issues when the new security-announce
> mailing list was quickly migrated from Mailman 2 to Mailman 3, but
> issues were quicky fixed as well.
>
> Would it be possible to migrate python-dev to Mailman 3? Do you see
> any blocker issue?
>
> I sent to email to the Python postmaster as well.

My only use of the pipermail archives is to find permanent URLs for
mails I want to refer people to. My usage goes as follows:

1. Google search for a post.
2. Paste in the URL to an email.

Or, if I have the post already (usually in my email client).

1. Check the date and subject of the post.
2. Go to the pipermail article by month, and scan the list for the
subject and author.
3. Click on the link, check it's the right email, copy the URL.
4. Paste it into my email.

I don't use the archives for reading. If the above two usages are
still available, I don't care. But in particular, the fact that
individual posts are searchable from Google is important to me. And in
the second usage, having a single scrollable webpage with no
extraneous data just subject/author and a bit of threading by
indentation speeds up my usage a lot - the UI you linked to (and the
monthly archive page with the initial lines of postings on it) is FAR
too cluttered to be usable for my purposes.

So basically, what I'm asking is what would be the support for the use
case "Find a permanent link to an archived article as fast as possible
based on subject/author or a Google search".

Finally, how would a transition be handled? I assume the old archives
would be retained, so would there be a cut-off date and people would
have to know to use the old or new archives based on the date of the
message?

Paul
___
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] Migrate python-dev to Mailman 3?

[Antoine Pitrou]

Le 26/10/2017 à 14:40, Nick Coghlan a écrit :
> 
> If folks want to see MM3 in action with some more active lists, I'd
> suggest looking at the Fedora MM3 instance, especially the main dev
> list:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org>
> There's a 100 message thread about Firefox 57 here, and it's no harder
> to read than a long thread on any other web forum:
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/K5HSROMAIMNYSJONB5EIAQKWKYNFYSHK/
> (if you switch to the strictly chronological display, it's almost
> *identical* to a web forum)

Thanks for posting these examples.  The comparison with "other" web
forums is irrelevant, though, since we're talking about replacing the
pipermail UI (which is not laid out like a web forum, but as a dense
synthetic tree view).  IMHO, common web forums (I assume you're talking
the phpBB kind) are unfit for presenting a structured discussion and
they're not a very interesting point of comparison :-)

> Pages for individual messages do exist (e.g.
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/HBA3O755BWRZMTDBBOCUHCKC3RREGTII/
> ), and I'd expect Aurelian to be amenable to accepting a PR at
> https://gitlab.com/mailman/hyperkitty if anyone was particularly keen to
> add pipermail style forward/back buttons to those pages.

I have no doubt that it's possible to submit PRs to improve MM3's
current UI.  Still, someone has to do the work, and until it is done I
find that a migration would be detrimental to my personal use of the ML
archives.  YMMV :-)

Regards

Antoine.
___
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] Migrate python-dev to Mailman 3?

[Nick Coghlan]

On 26 October 2017 at 20:19, Antoine Pitrou  wrote:

>
> Le 26/10/2017 à 12:15, Victor Stinner a écrit :
> > 2017-10-26 12:01 GMT+02:00 Antoine Pitrou :
> >> Is it possible to have a
> >> pipermail-style UI as an alternative?
> >
> > I don't know pipermail. Do you have an example?
>
> https://mail.python.org/pipermail/python-dev/ :-)
>
> > The main drawback of Mailman 2 archives is that discussions are
> > splitted between each month. It can be a pain to follow a long
> > discussion done in multiple months. Sadly, I don't know if Mailman 3
> > handles this case better :-D
>
> If I take
> https://mail.python.org/mm3/archives/list/buildbot-status@
> python.org/thread/MZ7QOZM6V7OALPSYSNSIHGGSLXMQHCF2/
> as an example, I don't think it will allow to follow a long discussion
> *at all*.  Can you imagine a 100-message thread displayed that way?
>

If folks want to see MM3 in action with some more active lists, I'd suggest
looking at the Fedora MM3 instance, especially the main dev list:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/

There's a 100 message thread about Firefox 57 here, and it's no harder to
read than a long thread on any other web forum:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/K5HSROMAIMNYSJONB5EIAQKWKYNFYSHK/
(if you switch to the strictly chronological display, it's almost
*identical* to a web forum)

https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/WKEB6M7J2WTFJBZYD7AZ4JB6J2O6VEWK/
is an example of a thread that was first posted back in July, but then
updated more recently when the change slipped from F27 into F28.

If you look at the activity for a month, as in
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/2017/10/?count=50,
the archiver will show you a single entry for each thread active in that
month, with a link through to the consolidate archive view.

Pages for individual messages do exist (e.g.
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/HBA3O755BWRZMTDBBOCUHCKC3RREGTII/
), and I'd expect Aurelian to be amenable to accepting a PR at
https://gitlab.com/mailman/hyperkitty if anyone was particularly keen to
add pipermail style forward/back buttons to those pages.

Similarly, I'd be surprised if anyone objected to a toggle on the thread
view page that allowed you to opt in to hiding the full message contents by
default (and hence get back to a more pipermail style
"Subject-lines-and-poster-details-only" overview).

Cheers,
Nick.

P.S. MM3 supports a multi-archiver design, so it would presumably also be
possible to write a static-HTML-only pipermail style archiver that ran in
parallel with the interactive web gateway.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] Migrate python-dev to Mailman 3?

[Antoine Pitrou]

Le 26/10/2017 à 12:15, Victor Stinner a écrit :
> 2017-10-26 12:01 GMT+02:00 Antoine Pitrou :
>> Is it possible to have a
>> pipermail-style UI as an alternative?
> 
> I don't know pipermail. Do you have an example?

https://mail.python.org/pipermail/python-dev/ :-)

> The main drawback of Mailman 2 archives is that discussions are
> splitted between each month. It can be a pain to follow a long
> discussion done in multiple months. Sadly, I don't know if Mailman 3
> handles this case better :-D

If I take
https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/thread/MZ7QOZM6V7OALPSYSNSIHGGSLXMQHCF2/
as an example, I don't think it will allow to follow a long discussion
*at all*.  Can you imagine a 100-message thread displayed that way?

The pipermail UI isn't perfect (the monthly segregation can be annoying
as you point out), but at least it has a synthetic and easy-to-navigate
tree view.

Regards

Antoine.
___
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] Migrate python-dev to Mailman 3?

[Victor Stinner]

2017-10-26 12:01 GMT+02:00 Antoine Pitrou :
> Is it possible to have a
> pipermail-style UI as an alternative?

I don't know pipermail. Do you have an example?

I don't think that Mailman 3 gives the choice of the UI for archives.
I didn't ask anyone to write a new software. I only proposed to use
what we already have.

And yeah, I expect that some people will complain, as each time that
we make any kind of change :-) Each UI has advantages and drawbacks.

The main drawback of Mailman 2 archives is that discussions are
splitted between each month. It can be a pain to follow a long
discussion done in multiple months. Sadly, I don't know if Mailman 3
handles this case better :-D

Victor
___
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] Migrate python-dev to Mailman 3?

[Antoine Pitrou]

On Thu, 26 Oct 2017 11:24:54 +0200
Victor Stinner  wrote:
> 
> We are using Mailman 3 for the new buildbot-status mailing list and it
> works well:
> 
> https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/
> 
> I prefer to read archives with this UI, it's simpler to follow
> threads, and it's possible to reply on the web UI!

Personally, I really don't like that UI.  Is it possible to have a
pipermail-style UI as an alternative?

(I don't care about buildbot-status, but I do care about python-dev)

Regards

Antoine.


___
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

[Python-Dev] Migrate python-dev to Mailman 3?

[Victor Stinner]

Hi,

We are using Mailman 3 for the new buildbot-status mailing list and it
works well:

https://mail.python.org/mm3/archives/list/buildbot-sta...@python.org/

I prefer to read archives with this UI, it's simpler to follow
threads, and it's possible to reply on the web UI!

To be honest, we got some issues when the new security-announce
mailing list was quickly migrated from Mailman 2 to Mailman 3, but
issues were quicky fixed as well.

Would it be possible to migrate python-dev to Mailman 3? Do you see
any blocker issue?

I sent to email to the Python postmaster as well.

Victor
___
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