[Python-Dev] Re: OT: Other fun contribution [was: Python-Announce floods and delays]

[Jonathan Goble]

On Tue, Jul 9, 2019 at 12:35 AM Stephen J. Turnbull
 wrote:
>
> Jonathan Goble writes:
>
>  > As for me, I'll continue to lurk and learn as I continue my sophomore
>  > year as a college student majoring in computer science, with hopes of
>  > becoming more active in contributing to Python as I gain more
>  > experience and skills.
>
> Evidently you have ambition to acquire a "commit bit".  That's a
> worthy goal (heaven knows we need more reviewers!),

Ha, I don't have any kind of grand ambitions like that (at least not
yet). To date I've contributed exactly one commit, that being a
trivial typo fix in a PEP. My real goal is get to the point in a year
or two where I can periodically contribute non-trivial code to fix
real bugs and such, but I'm going through a major transition right now
(graduating community college and transferring to a four-year
university next month) and don't have the spare time to wade in
currently. I also haven't taken any real computer courses yet other
than a basic freshman-level Java sequence, so my general skills are
lacking, but this upcoming academic year is when I will get elbow-deep
in the more advanced courses, including algorithms, so once I settle
in to the university over the next few months I plan to try to
contribute more.

> but there are
> plenty of other ways to contribute.  Some of the obvious ones (like
> documentation and teaching) may not be your thing, but there's
> probably a PyCon or Python meetup near you.  Especially for the larger
> ones, there are all kinds of "social volunteer" tasks, such as swag
> bag stuffing and registration desk, where even an hour or so of
> contribution is appreciated and you can interact with other people who
> are there for the same reasons you are.

I cannot afford a lot of travel, and as a college student, I have
limited dates to do so. For example, this year's PyCon was
inaccessible to me despite living "nearby" in Southwest Ohio partially
because of inability to afford gas and a hotel, but more importantly,
because it was held during final exam week. Next year's PyCon, a
similar distance away, will be during the last week of classes before
final exams, so I can't attend it either. I wish I could, but the
schedules don't work. From a financial perspective, even a single
night in a hotel is something I have to plan and budget for at least a
month or two in advance.

> (Beware: volunteering can be
> addictive, and you may find yourself running for PSF Board before you
> know it!)

The day that happens will be the day hell freezes over. :P

> "Contribution" doesn't have to involve "skills" or deskwork, and
> everyone can find ways that are lots of fun for them!
>
> Steve

What's fun for me is writing code. ;) When I have the free time (which
isn't much lately), I like to play around with writing random personal
projects, a couple of which I have published rough betas to PyPI (that
probably have been downloaded by nobody except me). I need to find
time between semesters to sit down and polish some of them up to
create a portfolio for internship applications, and I'm sure that the
next year of college will help me improve the quality significantly.

That said, if I could get to a PyCon or other meetup (which is a
function of both money and scheduling), I would be more than willing
to sign up for a volunteer shift. The difficulty is getting there
without disrupting my education or breaking the bank.
___
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/H4TOJPKULU2MQM436TJOF27MHUNFA2G2/

[Python-Dev] OT: Other fun contribution [was: Python-Announce floods and delays]

[Stephen J. Turnbull]

Jonathan Goble writes:

 > As for me, I'll continue to lurk and learn as I continue my sophomore
 > year as a college student majoring in computer science, with hopes of
 > becoming more active in contributing to Python as I gain more
 > experience and skills.

Evidently you have ambition to acquire a "commit bit".  That's a
worthy goal (heaven knows we need more reviewers!), but there are
plenty of other ways to contribute.  Some of the obvious ones (like
documentation and teaching) may not be your thing, but there's
probably a PyCon or Python meetup near you.  Especially for the larger
ones, there are all kinds of "social volunteer" tasks, such as swag
bag stuffing and registration desk, where even an hour or so of
contribution is appreciated and you can interact with other people who
are there for the same reasons you are.  (Beware: volunteering can be
addictive, and you may find yourself running for PSF Board before you
know it!)

"Contribution" doesn't have to involve "skills" or deskwork, and
everyone can find ways that are lots of fun for them!

Steve
___
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/FTV4VR6FYT4XP7IQRSMTP73NB3DMK3GT/

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

[Jonathan Goble]

On Mon, Jul 8, 2019 at 5:23 PM Barry Warsaw  wrote:
>
> On Jul 8, 2019, at 12:56, Barry Warsaw  wrote:
>
> > Volunteers are welcome! :)
>
> Wow, that was fast!  Thanks for the offers for help.  I’ll add everyone who’s 
> stepped up so far to the list moderators.  Yes, you do get a notification 
> every day with a link right to the moderation page.
>
> Cheers,
> -Barry

I'll echo the "wow". :) Happy to see people jumping at the chance to
help. Hopefully this leads to quicker moderation (which seems likely)
that doesn't flood inboxes like today.

As for me, I'll continue to lurk and learn as I continue my sophomore
year as a college student majoring in computer science, with hopes of
becoming more active in contributing to Python as I gain more
experience and skills.

Thanks everyone! :D
___
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/2OAJ35YVR6N54O6WKJE6OQ2CBUGWUJQH/

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

[Tim Peters]

[Inada Naoki , trying mimalloc]
>>> Hmm, it is not good.  mimalloc uses MADV_FREE so it may affect to some
>>> benchmarks.  I will look it later.

>> ...
>> $ ./python  -m pyperf compare_to pymalloc-mem.json mimalloc-mem.json -G
>> Slower (60):
>> - logging_format: 10.6 MB +- 384.2 kB -> 27.2 MB +- 21.3 kB: 2.58x
>> slower (+158%)
>> - logging_simple: 10028.4 kB +- 371.2 kB -> 22.2 MB +- 24.9 kB: 2.27x
>> slower (+127%)

> I think I understand why the mimalloc uses more than twice memory than the
> pymalloc + glibc malloc in logging_format and logging_simple benchmarks.
>
> These two benchmarks does like this:
>
> buf = [] # in StringIO
> for _ in range(10*1024):
> buf.append("important: some important information to be logged")
> s = "".join(buf)  # StringIO.getvalue()
> s.splitlines()
>
> mimalloc uses size segregated allocator for ~512KiB.  And size class
> is determined top three bits.
> On the other hand, list increases capacity by 9/8.  It means next size
> class is used on each realloc.

Often, but not always (multiplication by 9/8 may not change the top 3
bits - e.g., 128 * 9/8 = 144).

>  At last, all size classes has1~3 used/cached memory blocks.

No doubt part of it, but hard to believe it's most of it.  If the loop
count above really is 10240, then there's only about 80K worth of
pointers in the final `buf`.  To account for a difference of over 10M,
it would need to have left behind well over 100 _full_ size copies
from earlier reallocs.

in fact the number of list elements across resizes goes like so:

0, 4, 8, 16, 25, 35, 46, ..., 7671, 8637, 9723, 10945

Adding all of those sums to 96,113, so accounts for less than 1M of
8-byte pointers if none were ever released.  mimalloc will, of course,
add its own slop on top of that - but not a factor of ten's worth.
Unless maybe it's using a dozen such buffers at once?

But does it really matter? ;-)  mimalloc "should have" done MADV_FREE
on the pages holding the older `buf` instances, so it's not like the
app is demanding to hold on to the RAM (albeit that it may well show
up in the app's RSS unless/until the OS takes the RAM away).


> This is almost worst case for mimalloc.  In more complex application,
> there may be more chance to reuse memory blocks.
>
> In complex or huge application, this overhead will become relatively small.
> It's speed is attractive.
>
> But for memory efficiency, pymalloc + jemalloc / tcmalloc may be better for
> common cases.

The mimalloc page says that, in their benchmarks:

"""
In our benchmarks (see below), mimalloc always outperforms all other
leading allocators (jemalloc, tcmalloc, Hoard, etc), and usually uses
less memory (up to 25% more in the worst case).
"""

obmalloc is certainly more "memory efficient" (for some meanings of
that phrase) for smaller objects:  in 3.7 it splits objects of <= 512
bytes into 64 size classes.  mimalloc also has (close to) 64 "not
gigantic" size classes, but those cover a range of sizes over a
thousand times wider (up to about half a meg).  Everything obmalloc
handles fits in mimalloc's first 20 size classes.  So mimalloc
routinely needs more memory to satisfy a "small object" request than
obmalloc does.

I was more intrigued by your first (speed) comparison:

> - spectral_norm: 202 ms +- 5 ms -> 176 ms +- 3 ms: 1.15x faster (-13%)

Now _that's_ interesting ;-)  Looks like spectral_norm recycles many
short-lived Python floats at a swift pace.  So memory management
should account for a large part of its runtime (the arithmetic it does
is cheap in comparison), and obmalloc and mimalloc should both excel
at recycling mountains of small objects.  Why is mimalloc
significantly faster?  This benchmark should stay in the "fastest
paths" of both allocators most often, and they both have very lean
fastest paths (they both use pool-local singly-linked sized-segregated
free lists, so malloc and free for both should usually amount to just
popping or pushing one block off/on the head of the appropriate list).

 obmalloc's `address_in_range()` is definitely a major overhead in its
fastest `free()` path, but then mimalloc has to figure out which
thread is doing the freeing (looks cheaper than address_in_range, but
not free).  Perhaps the layers of indirection that have been wrapped
around obmalloc over the years are to blame?  Perhaps mimalloc's
larger (16x) pools and arenas let it stay in its fastest paths more
often?  I don't know why, but it would be interesting to find out :-)
___
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/554D4PU6LBBIKWJCQI4VKU2BVZD4Z3PM/

[Python-Dev] [RELEASE] Python 3.7.4 is now available

[Ned Deily]

Python 3.7.4 is now available. 3.7.4 is the next maintenance release of
Python 3.7, the latest feature release of Python. You can find the
release files, a link to the changelog, and more information here:
https://www.python.org/downloads/release/python-374/

See the "What’s New In Python 3.7" document for more information about
the many new features and optimizations included in the 3.7 series.
Detailed information about the changes made in 3.7.4 can be found in its
change log:
https://docs.python.org/3.7/whatsnew/changelog.html#python-3-7-4-final
https://docs.python.org/3.7/whatsnew/3.7.html

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation:
https://www.python.org/psf/

--
  Ned Deily
  n...@python.org -- []
___
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/RYEXOIFHMEM4F2YQZAEVWWIQ3U2KUZ7M/

[Python-Dev] Re: [RELEASE] Python 3.8.0b2 is now available for testing

[Barry Warsaw]

I’ve updated the official images to include 3.8.0b2:

https://gitlab.com/python-devs/ci-images/tree/master

Cheers,
-Barry

> On Jul 4, 2019, at 15:05, Łukasz Langa  wrote:
> 
> Signed PGP part
> After a few days of delay, but somewhat cutely timed with the US Independence 
> Day, I present you Python 3.8.0b2:
> 
> https://www.python.org/downloads/release/python-380b2/ 
> 
> 
> This release is the second of four planned beta release previews. Beta 
> release previews are intended to give the wider community the opportunity to 
> test new features and bug fixes and to prepare their projects to support the 
> new feature release. The next pre-release of Python 3.8 will be 3.8.0b3, 
> currently scheduled for 2019-07-29.
> 
> Call to action
> 
> We strongly encourage maintainers of third-party Python projects to test with 
> 3.8 during the beta phase and report issues found to the Python bug tracker 
>  as soon as possible. While the release is planned 
> to be feature complete entering the beta phase, it is possible that features 
> may be modified or, in rare cases, deleted up until the start of the release 
> candidate phase (2019-09-30). Our goal is have no ABI changes after beta 3 
> and no code changes after 3.8.0rc1, the release candidate. To achieve that, 
> it will be extremely important to get as much exposure for 3.8 as possible 
> during the beta phase.
> 
> Please keep in mind that this is a preview release and its use is not 
> recommended for production environments.
> 
> No more non-bugfixes allowed on the “3.8” branch
> 
> The time has come, team. Please help make Python 3.8 as stable as possible 
> and keep all features not currently landed for Python 3.9. Don’t fret, it’ll 
> come faster than you think.
> 
> 
> - Ł
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
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/JRX5LSDAUVU6JELT26WACVNGVDSIGZNK/

[Python-Dev] Re: Further off-topic: webmaster@ volunteers

[Ethan Furman]

On 07/08/2019 03:12 PM, Steve Holden wrote:


[even further off-topic]

While I have the attention of so many community-spirited individuals, I might 
mention that webmaster@ could do with a few lurkers to get used to the traffic. 
At present it's solely maintained by Mats Wichmann and me, and I'm planning to 
step back from all PSF duties soon. The duties aren't heavy, but the traffic is 
fairly regular and most of it benefits from being answered sooner rather than 
later.


What kind of traffic?  Actually answering questions or the same type of 
gate-keeper duties as the list mods?

--
~Ethan~
___
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/MEQPOPC5AQV5EGPDC6EP7WMQ6YR4DB4A/

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

[Steve Holden]

[even further off-topic]

While I have the attention of so many community-spirited individuals, I
might mention that webmaster@ could do with a few lurkers to get used to
the traffic. At present it's solely maintained by Mats Wichmann and me, and
I'm planning to step back from all PSF duties soon. The duties aren't
heavy, but the traffic is fairly regular and most of it benefits from being
answered sooner rather than later. So if anyone wants to pitch in, you'll
be welcomed.

Kind regards,
Steve Holden


On Mon, Jul 8, 2019 at 10:28 PM Barry Warsaw  wrote:

> On Jul 8, 2019, at 12:56, Barry Warsaw  wrote:
>
> > Volunteers are welcome! :)
>
> Wow, that was fast!  Thanks for the offers for help.  I’ll add everyone
> who’s stepped up so far to the list moderators.  Yes, you do get a
> notification every day with a link right to the moderation page.
>
> Cheers,
> -Barry
>
> ___
> 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/ETXCK6VHF6S3D6WOVYRDCXRSWCZRUVPW/
>
___
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/NCQQXZMHV5TNPTHPDSG45PFX3AKLLYUC/

[Python-Dev] Re: Removing dead bytecode vs reporting syntax errors

[Pablo Galindo Salgado]

>. If it doesn't, could this one optimization
be left in the peephole optimizer at bytecode level?

Sadly no, because at that time there is not enough information left to do 
things correctly. The problem manifest with constructs like

if something or __debug__:
  ...

You cannot just look at the bytecode before the POP_JUMP_IF_FALSE (or similar) 
because you don't know reliably which bytecodes correspond to the entire 
condition (at least that I know of).

My proposal (it seem that works, but is being reviewed still) is basically 
doing a compiler pass that just check for errors over the blocks that we don't 
want to generate bytecode instead of not visiting them at all. I think is the 
less intrusive and faster solution that I can think off.
___
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/22SLXBQI6RSVUSCKW25YGQFESD5OCEBV/

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

[Barry Warsaw]

On Jul 8, 2019, at 12:56, Barry Warsaw  wrote:

> Volunteers are welcome! :)

Wow, that was fast!  Thanks for the offers for help.  I’ll add everyone who’s 
stepped up so far to the list moderators.  Yes, you do get a notification every 
day with a link right to the moderation page.

Cheers,
-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/ETXCK6VHF6S3D6WOVYRDCXRSWCZRUVPW/

[Python-Dev] Re: Removing dead bytecode vs reporting syntax errors

[Guido van Rossum]

On Mon, Jul 8, 2019 at 1:51 PM Brett Cannon  wrote:

> Hopefully Pablo's proposed solution works.


I'm sure it will.


> If it doesn't, could this one optimization be left in the peephole
> optimizer at bytecode level? Otherwise is another solution to follow
> through with
> https://discuss.python.org/t/switch-pythons-parsing-tech-to-something-more-powerful-than-ll-1/379
> and switch the parser so it can handle all syntax errors on its own without
> support from the AST analyzer?
>

Thinking about this, that's possible, but it would require bloating the
grammar with variants that allow continue/break or not, allow return/yield
or not, allow await or not. So I think this particular thing is still best
handled by a separate check. (The PEG-based parser I am contemplating would
be able to tell an expression statement from an assignment statement
without a separate pass to make sure you don't try to assign to a call, and
it would allow a much more elegant approach to keyword arguments and the
walrus operator.)

--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(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/QQTQKVK73CETNX73FZDFVUBB7TQ6L6KD/

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

[Ivan Pozdeev via Python-Dev]

On 08.07.2019 23:10, Jonathan Goble wrote:

On Mon, Jul 8, 2019, 3:56 PM Barry Warsaw mailto:ba...@python.org>> wrote:

On Jul 8, 2019, at 12:27, Jonathan Goble mailto:jcgob...@gmail.com>> wrote:

> Is there a solution to this that would enable moderators to approve
> more frequently?

Volunteers are welcome! :)

-Barry


I'd offer to volunteer, but I am merely a lurker and not active in the community, and I feel like someone more active and known in the 
community should take that role. Speaking of which, it looks like an -ideas mod has volunteered for -announce, so maybe that will help. :)



The requirement here is not prior fame but free time for the job (and a minimal 
amount of common sense if that could be called a requirement).



___
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/DIPEU26LK5JE5B2QH3LSHVSC44FGDMP7/


--
Regards,
Ivan

___
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/PYIZNVIGHSPSQ6T37UN62SSWHDAOI4N7/

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

[Brett Cannon]

Fred Drake wrote:
> On Mon, Jul 8, 2019 at 3:59 PM Barry Warsaw ba...@python.org... 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?

Yes!
___
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/2RTBHGIAM6FNUGUJU3RMUFWXOOWKGINJ/

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

[Ethan Furman]

On 07/08/2019 12:56 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! :)


Sign me up!  Looks like much less of a burden than -list is (and probably about 
the same as core-mentorship).  :-)

--
~Ethan~
___
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/ESE3KMJERJBROYNXVJDWBK44BWYL73ZD/

[Python-Dev] Re: Removing dead bytecode vs reporting syntax errors

[Brett Cannon]

Hopefully Pablo's proposed solution works. If it doesn't, could this one 
optimization be left in the peephole optimizer at bytecode level? Otherwise is 
another solution to follow through with 
https://discuss.python.org/t/switch-pythons-parsing-tech-to-something-more-powerful-than-ll-1/379
 and switch the parser so it can handle all syntax errors on its own without 
support from the AST analyzer?
___
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/LN236JC6M3IGPC6GT43TCEOJRDNLO53T/

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

[C. Titus Brown]

On Mon, Jul 08, 2019 at 03:27:50PM -0400, Jonathan Goble wrote:
> (I don't know the best list to post this to, so if this is not it,
> please forgive me and point me in the right direction. Thanks.)
> 
> So my inbox, and probably many of yours, was flooded this afternoon
> with a dozen-plus emails from the Python-Announce list. I understand
> that this list requires every email to be manually approved by a
> moderator. The problem is that this is done infrequently. Prior to
> today, the last round of approvals was June 26, almost two weeks ago.
> This is not an atypical delay; on the contrary, it seems that
> moderators only look at the queue once every one to two weeks.
> 
> There are several problems with these delays:
> 
> 1. They result in floods of emails, with a large number of emails in a
> short period of time. This makes inbox management difficult on the
> days that approvals are done. Before you argue that "it's fine if you
> have the right tools configured in the right way", consider that there
> are probably many people who are subscribed to Python-Announce who
> have no interest in and are not subscribed to any of the actual
> discussion lists where such tools are most beneficial. Complex tool
> configurations should not be a requirement for managing incoming
> emails from what is essentially (to those people) a notification-only
> mailing list. These people would be better served by frequent
> approvals several times a week, allowing them to get fewer emails at
> one time, but in a more timely manner.
> 
> 2. Speaking of a more timely manner, the lengthy delays result in
> redundant and outdated emails going through after the point where they
> are no longer relevant. One such issue exemplified by today's set of
> approvals (and seen on previous occasions before) is an announcement
> of a new release of a PyPI package not being approved until after
> there has already been a subsequent release to that same package. In
> this case I am referring to the pytest 5.0.0 announcement sent to the
> list on June 28 (according to the headers), followed by the pytest
> 5.0.1 announcement sent to the list on July 5. Neither was approved
> and delivered to subscribers until today.
> 
> 3. More importantly in terms of delays, on July 3 an announcement was
> sent to the list regarding the impending switch of EuroPython ticket
> rates to the late registration rate on July 6. This is an example of a
> time-sensitive announcement that needs to not be delayed. Instead, the
> email was not approved and delivered to subscribers until today, July
> 8, after the conference has already begun, and not in time for list
> subscribers to react and avoid the late registration rates.
> 
> Is there a solution to this that would enable moderators to approve
> more frequently? I understand that they are probably volunteers and
> need to find spare time to wade through the queue, but if approvals
> are done more frequently (even daily), then it will consume much less
> time on each occasion. It would go from a task requiring an entire
> hour (as it apparently did today based on the delivery timestamps) to
> something that can be done on a coffee break.

I already help moderate python-ideas and would be happy to help moderate
announce.

best,
--titus
-- 
C. Titus Brown, ctbr...@ucdavis.edu
___
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/SJIXMHD734APMOANNTFHE7QDNHZZXO6U/

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

[Jonathan Goble]

On Mon, Jul 8, 2019, 3:56 PM Barry Warsaw  wrote:

> On Jul 8, 2019, at 12:27, Jonathan Goble  wrote:
>
> > Is there a solution to this that would enable moderators to approve
> > more frequently?
>
> Volunteers are welcome! :)
>
> -Barry
>

I'd offer to volunteer, but I am merely a lurker and not active in the
community, and I feel like someone more active and known in the community
should take that role. Speaking of which, it looks like an -ideas mod has
volunteered for -announce, so maybe that will help. :)

>
___
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/DIPEU26LK5JE5B2QH3LSHVSC44FGDMP7/

[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/

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

[Barry Warsaw]

On Jul 8, 2019, at 12:27, Jonathan Goble  wrote:

> So my inbox, and probably many of yours, was flooded this afternoon
> with a dozen-plus emails from the Python-Announce list. I understand
> that this list requires every email to be manually approved by a
> moderator.

I cleared the queue this morning, and unfortunately let one spam through.  
Apologies for that.

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.

> Is there a solution to this that would enable moderators to approve
> more frequently?

Volunteers are welcome! :)

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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/QFWQTV4ISG52AB7EKX7I7LAPR3QZTVYJ/

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

[Jonathan Goble]

(I don't know the best list to post this to, so if this is not it,
please forgive me and point me in the right direction. Thanks.)

So my inbox, and probably many of yours, was flooded this afternoon
with a dozen-plus emails from the Python-Announce list. I understand
that this list requires every email to be manually approved by a
moderator. The problem is that this is done infrequently. Prior to
today, the last round of approvals was June 26, almost two weeks ago.
This is not an atypical delay; on the contrary, it seems that
moderators only look at the queue once every one to two weeks.

There are several problems with these delays:

1. They result in floods of emails, with a large number of emails in a
short period of time. This makes inbox management difficult on the
days that approvals are done. Before you argue that "it's fine if you
have the right tools configured in the right way", consider that there
are probably many people who are subscribed to Python-Announce who
have no interest in and are not subscribed to any of the actual
discussion lists where such tools are most beneficial. Complex tool
configurations should not be a requirement for managing incoming
emails from what is essentially (to those people) a notification-only
mailing list. These people would be better served by frequent
approvals several times a week, allowing them to get fewer emails at
one time, but in a more timely manner.

2. Speaking of a more timely manner, the lengthy delays result in
redundant and outdated emails going through after the point where they
are no longer relevant. One such issue exemplified by today's set of
approvals (and seen on previous occasions before) is an announcement
of a new release of a PyPI package not being approved until after
there has already been a subsequent release to that same package. In
this case I am referring to the pytest 5.0.0 announcement sent to the
list on June 28 (according to the headers), followed by the pytest
5.0.1 announcement sent to the list on July 5. Neither was approved
and delivered to subscribers until today.

3. More importantly in terms of delays, on July 3 an announcement was
sent to the list regarding the impending switch of EuroPython ticket
rates to the late registration rate on July 6. This is an example of a
time-sensitive announcement that needs to not be delayed. Instead, the
email was not approved and delivered to subscribers until today, July
8, after the conference has already begun, and not in time for list
subscribers to react and avoid the late registration rates.

Is there a solution to this that would enable moderators to approve
more frequently? I understand that they are probably volunteers and
need to find spare time to wade through the queue, but if approvals
are done more frequently (even daily), then it will consume much less
time on each occasion. It would go from a task requiring an entire
hour (as it apparently did today based on the delivery timestamps) to
something that can be done on a coffee break.
___
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/XOQZK7KNXNUC2EC65FDDX7GSMLUUHHDU/

[Python-Dev] Re: Steering Council Update for July 2019

[Simon Cross]

Is there a way for people to give input to the challenges facing Python
discussion? I'm picturing something like people writing short statements of
perceived challenges and submitting them so that the SC has more ideas on
its radar.
___
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/SJJ5JY5LPL3OQF2GSZVUJ5PZSVW5USO3/

[Python-Dev] Re: Steering Council Update for July 2019

[Carol Willing]

Hi Simon,

There are several ways to share constructive feedback. You may email the 
steering council, file an issue on the public steering council repo, or create 
a discussion thread on Discourse or python-dev.

Thanks!

Carol

On Mon, Jul 8, 2019, at 12:35 PM, Simon Cross wrote:
> Is there a way for people to give input to the challenges facing Python 
> discussion? I'm picturing something like people writing short statements of 
> perceived challenges and submitting them so that the SC has more ideas on its 
> radar.
___
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/LM2VJKOQKPBGZ6G2NWL6C7BQ4QFZULEA/

[Python-Dev] Re: obmalloc (was Have a big machine and spare time? Here's a possible Python bug.)

[Inada Naoki]

On Thu, Jul 4, 2019 at 11:32 PM Inada Naoki  wrote:
>
> On Thu, Jul 4, 2019 at 8:09 PM Antoine Pitrou  wrote:
> >
> > Ah, interesting.  Were you able to measure the memory footprint as well?
> >
>
> Hmm, it is not good.  mimalloc uses MADV_FREE so it may affect to some
> benchmarks.  I will look it later.
>
> ```
> $ ./python  -m pyperf compare_to pymalloc-mem.json mimalloc-mem.json -G
> Slower (60):
> - logging_format: 10.6 MB +- 384.2 kB -> 27.2 MB +- 21.3 kB: 2.58x
> slower (+158%)
> - logging_simple: 10028.4 kB +- 371.2 kB -> 22.2 MB +- 24.9 kB: 2.27x
> slower (+127%)

I think I understand why the mimalloc uses more than twice memory than the
pymalloc + glibc malloc in logging_format and logging_simple benchmarks.

These two benchmarks does like this:

buf = [] # in StringIO
for _ in range(10*1024):
buf.append("important: some important information to be logged")
s = "".join(buf)  # StringIO.getvalue()
s.splitlines()

mimalloc uses size segregated allocator for ~512KiB.  And size class
is determined
top three bits.
On the other hand, list increases capacity by 9/8.  It means next size
class is used
on each realloc.  At last, all size classes has1~3 used/cached memory blocks.

This is almost worst case for mimalloc.  In more complex application,
there may be
more chance to reuse memory blocks.

In complex or huge application, this overhead will become relatively small.
It's speed is attractive.

But for memory efficiency, pymalloc + jemalloc / tcmalloc may be better for
common cases.

Regards,
-- 
Inada Naoki  
___
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/ORVLH5FAEO7LVE7SK44TQR6XK4YRRZ7L/

[Python-Dev] Re: Steering Council Update for July 2019

[Carol Willing]

Sorry for the incorrect link. Here is the corrected link:

https://github.com/python/steering-council/blob/master/updates/2019-07-08_steering-council-update.md

On Mon, Jul 8, 2019, at 7:16 AM, Carol Willing wrote:
> I've posted an update from the Steering Council to our repo:

> https://github.com/python/steering-council/blob/master/updates/2019-07-08_steering-council
> 
> I will also link to this on python-dev and on Discourse (discuss.python.org ).

> 
> For completeness, below is the full text.
> 
> 
> # Steering Council Update


## Date: 2019-07-08

Steering Council updates will be posted irregularly and as needed.
We provide these updates to foster open and transparent communication about
Steering Council activity. We strive to post at least once every month.


# Message from the Steering Council

Sorry we've been silent for a while! With PyCon in Cleveland, the Language
Summit, Sprints, PEP activity, and a Python 3.8 beta release, it's been a busy
and productive May and June. Thank you all for your contributions. Below are
some of the outcomes of our weekly Steering Council conversations.

---

## Mandate

This section organizes Steering Council (SC) activity and projects
using the mandates listed in PEP 13.


### Language

> Maintain the quality and stability of the Python language and CPython 
> interpreter

- Inspired by Russell Keith-Magee's PyCon keynote about Black Swan events, the
  Steering Council is looking at what may impact Python for the next
  decade. We have been discussing this within the Steering Council and writing
  up some thoughts on major challenges facing Python. We'll continue to edit
  and polish this vision document and share it when we are ready for wider 
comment.


### Contributors

> Make contributing as accessible, inclusive, and sustainable as possible

- **Communications channels:** We are very pleased with the move of
  python-dev, etc. to Mailman 3. We now have a modern UI and easy search across
  mailing lists.

  Just a reminder to recap where announcements and conversations are taking 
place:

  - To reach core committers specifically, we will use
python-committ...@python.org.

  - To reach the entire Python developer community, we will use
python-dev@python.org.

  - For specific requests to the SC (e.g., PEP reviews), please use
our public GitHub tracker at 
https://github.com/python/steering-council/issues.

  - To reach just the SC, you can email us at
steering-coun...@python.org.

  - We will also occasionally use Discourse, at
https://discuss.python.org (for example, Discourse is useful for
polls and votes).


### PEPs

> Establish appropriate decision-making processes for PEPs

- To request a PEP review, please file an issue on the
  [SC issue tracker](https://github.com/python/steering-council/issues).

PEP highlights include:

- PEP 570, "Python Positional-Only Parameters", by Larry Hastings, Pablo
  Galindo and others. *Appointed Guido van Rossum as BD.* "Completed."
- PEP 574, "Pickle protocol 5 with out-of-band data", Antoine Pitrou.
  *Appointed Nick Coghlan as BD.* "Marked Final."
- PEPs 576, 579, 580, 590 (competing PEPs on C function call optimizations by
  Mark Shannon and Jeroen Demeyer; note that PEP 576 is withdrawn in favor of
  PEP 590). *Appointed Petr Viktorin as BD.* "Accepted 590."
- PEP 578, "Python Runtime Audit Hooks", Steve Dower.
  *Appointed Christian Heimes as BD.* "Landed, about to be marked Final."


### Interaction with PSF

> Formalize and maintain the relationship between the core team and the PSF

- We began discussions about fundraising ideas for CPython projects and 
administrative support.

- A [donation 
page]([https://www.python.org/psf/donations/python-dev/](https://www.python.org/psf/donations/python-dev/))
 was created by the PSF and was linked from the
 [CPython 
repo]([https://github.com/python/cpython](https://github.com/python/cpython)). 
Any funds that are donated will be used for Core Developers to attend the core 
development sprints (to start; future possibilities are dependent on the amount 
of funds gathered).

- At the Steering Council's recommendation, the PSF also is looking at hiring a 
Project Manager to manage communication and
  some logistics for the 2020 Python 2.7 End of Life.

- The PSF Code of Conduct Workgroup is working on a revision of the CoC and
  its approval by the PSF board. Brett and Carol serve on the Workgroup.


### Governance

> Seek consensus among contributors and the core team before acting in a formal 
> capacity,

> Act as a "court of final appeal" for decisions where all other methods have 
> failed.

- The weekly SC meeting cadence (Tuesdays 3-4pm US West Coast time) has been
  working out well.

---


## Reference

This reference section summarizes the Steering Council's mandate and powers.


### Mandate (PEP 13)

The steering council shall work to:

- Maintain the quality and stability of the Python language and
  CPython interpreter,
- Make contrib

[Python-Dev] Steering Council Update for July 2019

[Carol Willing]

I've posted an update from the Steering Council to our repo:

https://github.com/python/steering-council/blob/master/updates/2019-07-08_steering-council

I will also link to this on python-dev and on Discourse (discuss.python.org ).


For completeness, below is the full text.


# Steering Council Update


## Date: 2019-07-08

Steering Council updates will be posted irregularly and as needed.
We provide these updates to foster open and transparent communication about
Steering Council activity. We strive to post at least once every month.


# Message from the Steering Council

Sorry we've been silent for a while! With PyCon in Cleveland, the Language
Summit, Sprints, PEP activity, and a Python 3.8 beta release, it's been a busy
and productive May and June. Thank you all for your contributions. Below are
some of the outcomes of our weekly Steering Council conversations.

---

## Mandate

This section organizes Steering Council (SC) activity and projects
using the mandates listed in PEP 13.


### Language

> Maintain the quality and stability of the Python language and CPython 
> interpreter

- Inspired by Russell Keith-Magee's PyCon keynote about Black Swan events, the
  Steering Council is looking at what may impact Python for the next
  decade. We have been discussing this within the Steering Council and writing
  up some thoughts on major challenges facing Python. We'll continue to edit
  and polish this vision document and share it when we are ready for wider 
comment.


### Contributors

> Make contributing as accessible, inclusive, and sustainable as possible

- **Communications channels:** We are very pleased with the move of
  python-dev, etc. to Mailman 3. We now have a modern UI and easy search across
  mailing lists.

  Just a reminder to recap where announcements and conversations are taking 
place:

  - To reach core committers specifically, we will use
python-committ...@python.org.

  - To reach the entire Python developer community, we will use
python-dev@python.org.

  - For specific requests to the SC (e.g., PEP reviews), please use
our public GitHub tracker at 
https://github.com/python/steering-council/issues.

  - To reach just the SC, you can email us at
steering-coun...@python.org.

  - We will also occasionally use Discourse, at
https://discuss.python.org (for example, Discourse is useful for
polls and votes).


### PEPs

> Establish appropriate decision-making processes for PEPs

- To request a PEP review, please file an issue on the
  [SC issue tracker](https://github.com/python/steering-council/issues).

PEP highlights include:

- PEP 570, "Python Positional-Only Parameters", by Larry Hastings, Pablo
  Galindo and others. *Appointed Guido van Rossum as BD.* "Completed."
- PEP 574, "Pickle protocol 5 with out-of-band data", Antoine Pitrou.
  *Appointed Nick Coghlan as BD.* "Marked Final."
- PEPs 576, 579, 580, 590 (competing PEPs on C function call optimizations by
  Mark Shannon and Jeroen Demeyer; note that PEP 576 is withdrawn in favor of
  PEP 590). *Appointed Petr Viktorin as BD.* "Accepted 590."
- PEP 578, "Python Runtime Audit Hooks", Steve Dower.
  *Appointed Christian Heimes as BD.* "Landed, about to be marked Final."


### Interaction with PSF

> Formalize and maintain the relationship between the core team and the PSF

- We began discussions about fundraising ideas for CPython projects and 
administrative support.

- A [donation 
page]([https://www.python.org/psf/donations/python-dev/](https://www.python.org/psf/donations/python-dev/))
 was created by the PSF and was linked from the
 [CPython 
repo]([https://github.com/python/cpython](https://github.com/python/cpython)). 
Any funds that are donated will be used for Core Developers to attend the core 
development sprints (to start; future possibilities are dependent on the amount 
of funds gathered).

- At the Steering Council's recommendation, the PSF also is looking at hiring a 
Project Manager to manage communication and
  some logistics for the 2020 Python 2.7 End of Life.

- The PSF Code of Conduct Workgroup is working on a revision of the CoC and
  its approval by the PSF board. Brett and Carol serve on the Workgroup.


### Governance

> Seek consensus among contributors and the core team before acting in a formal 
> capacity,

> Act as a "court of final appeal" for decisions where all other methods have 
> failed.

- The weekly SC meeting cadence (Tuesdays 3-4pm US West Coast time) has been
  working out well.

---


## Reference

This reference section summarizes the Steering Council's mandate and powers.


### Mandate (PEP 13)

The steering council shall work to:

- Maintain the quality and stability of the Python language and
  CPython interpreter,
- Make contributing as accessible, inclusive, and sustainable as
  possible,
- Formalize and maintain the relationship between the core team and
  the PSF,
- Establish appropriate decision-making processes for PEPs,
- Seek consensus among contribu