[Python-Dev] Re: Retiring this mailing list ?

[Steve Holden]

On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg  wrote:

> [...]
>
> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)
>
> [...]

Hi Marc-Andre,

Maybe just require senders to be members of the python.org domain, and
retain the release announcements?

Kind regards,
Steve

PS: Your mail triggered a visit to https://www.python.org/community/lists/
- it seems it could use some updates. For example,
comp.lang.python-announce is a news URL, which in this day and age will
baffle most visitors! At the very least the page could point to the
Discourse list.
___
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/SXLIZEV2Y6NHYYFWAMWL43JIIHR2AODD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: detecting statements which result is not stored

[Steve Holden]

Sounds like you might want the "Python Help" group on https;//
discuss.python.org - the dev conversation migrated there quite a while ago
now, so thighs channel is more or less announcements only.

Good luck with your project!

Kind regards,
Steve


On Thu, 5 Oct 2023 at 16:07, Guenther Sohler 
wrote:

>
> Hi Python Developers, after  some investigation i consider dev the correct
> mailing list.
> I got python embedded into OpenSCAD and i'd like to make more use out of
> it.
>
> statements like these do exactly what they should:
>
> width= 3*5
> solid = make_nice_solid(width)
> other_solid = solid.size(1)
> print(" Everything fine")
>
> But i'd like to be able to write lines like these:  These are expressions
> which create a value,
> which is apparently NOT stored in a variable
>
> solid *3
> other_solid - solid
>
> instead of wasting them, I'd like to collect them in an array and display
> send it to the display engine
> after  python evaluation has  finished.
>
> Is there some way how i can collect the orphaned expressions ?
>
>
>
> ___
> 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/D7GI2EAE73OSYOQI7QKQOCB6SRRYOUWV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/MOXK3OETDDEI24VOM2OY726REYBFOVSF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Some pattern annoyance

[Steve Holden]

Hi Chris,

Nice to see you on the list.

While this is definitely off-topic, I trust I might be given license by the
list's few remaining readers to point out that the match-case construct is
for _structural_ pattern matching. As I wrote in the latest Nutshell:
"Resist the temptation to use match unless there is a need to analyse the
_structure_ of an object."

I don't believe it's accidental that match-case sequence patterns won't
match str, bytes or bytearrray objects - regexen are the tool already
optimised for that purpose, so it's quite impressive that you are
managing to approach the same level of performance!

Kind regards,
Steve


On Wed, 2 Aug 2023 at 18:26, Christian Tismer-Sperling 
wrote:

> On 02.08.23 18:30, Paul Moore wrote:
> > On Wed, 2 Aug 2023 at 15:24, Stephen J. Turnbull
> >  > > wrote:
> >
> > Partly because that's where the other discussants are (the network
> > externality is undeniably powerful), and partly (I believe) because
> > effective use of email is a skill that requires effort to acquire.
> > Popular mail clients are designed to be popular, not to make that
> > expertise easy to acquire and exercise.  Clunky use of email makes
> > lists much less pleasant for everyone than they could be.
> >
> > I guess that's sad (I am, after all, a GNU Mailman developer), but
> > it's reality.
> >
> >
> > Personally, I'm sad because some people whose contributions I enjoy (you
> > being one of them :-)) didn't move to Discourse. But like you say, it's
> > how things are.
> >
> > Christian - you can make named constants using class attributes (or an
> > enum):
> >
> > class A:
> >  M = "M"
> >
> > match seq:
> >  case A.M, A.M, A.M, A.M, *r:
> >  return 4*1000, r
> >
> > Basically, the "names are treated as variables to assign to" rule
> > doesn't apply to attributes.
> >
> > I'm not sure how helpful that is (it's not particularly *shorter*) but I
> > think the idea was that most uses of named constants in a match
> > statement would be enums or module attributes. And compromises had to be
> > made.
> >
> > Cheers,
> > Paul
>
> Thanks a lot, everybody!
>
> I have tried a lot now, using classes which becomes more readable
> but - funnily - slower! Using the clumsy if-guards felt slow but isn't.
>
> Then I generated functions even, with everything as constants,
> and now the SPM version in fact out-performs the regex slightly!
>
> But at last, I found an even faster and correct algorithm
> by a different approach, which ends now this story :)
>
> Going to the Discourse tite, now.
>
> Cheers -- Chris
> --
> Christian Tismer-Sperling:^)   tis...@stackless.com
> Software Consulting  : http://www.stackless.com/
> Strandstraße 37  : https://github.com/PySide
> 24217 Schönberg  : GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
>
> ___
> 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/OFLAU34KWAKREKG4H2M5GES3PGT6VBAU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/DYTVT7CUFVVGIDPXG2MKIOELWJPG3W73/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Feature Request: Adding Way to Annotate Class Variables Distinct from Instance Variables

[Steve Holden]

Well, the first comment is that this isn't really the best list to ask such
questions on, since it was created for the Python developers to discuss the
development of the language and its implementation. Further, such
discussions nowadays take place on discuss.python.org, and you can find
more information at https://www.python.org/community/lists/.

However, I simplified your program a little, and would observe that the
following program raises no AssertionErrors under Python 3.10  and 3.11.

class Foo:
variable_both_class_and_instance: str | int = "descriptive string"

def __init__(self, value: int):
assert isinstance(self.variable_both_class_and_instance, str)
self.variable_both_class_and_instance = value
assert isinstance(self.variable_both_class_and_instance, int)

assert isinstance(Foo.variable_both_class_and_instance, str)
assert isinstance(Foo(42).variable_both_class_and_instance, int)

Union is now outdated, since we can use alternation (|) to offer
alternative types.

It's therefore not obvious to me from your email why ClassVar would need
any modification, or even why it needs to be used in your example. Perhaps
I've missed your point?

Kind regards,
Steve


On Wed, Dec 21, 2022 at 4:15 PM  wrote:

> Hello folks, I am Chihiro, a.k.a. Frodo821, and this is my first post to
> this group.
>
> I searched for a way to annotate both class variables and instance
> variables with different types and concluded that there is currently no way
> to do this.
>
> For example, what I want to:
> ```
> class Foo:
> variable_both_class_and_instance = Field(desc="descriptive string")
>
> def __init__(self, value: int):
> self.variable_both_class_and_instance = value
>
> assert isinstance(Foo.variable_both_class_and_instance, Field)
> assert isinstance(Foo().variable_both_class_and_instance, int)
> ```
>
> In this example, I want to annotate `Foo.variable_both_class_and_instance`
> with `Field` when it is accessed as a class variable. On the other hand, I
> want to annotate `Foo.variable_both_class_and_instance` with `int` when it
> is accessed as an instance variable.
>
> I don't have any smart ideas to accomplish this, but I think
> `typing.ClassVar` could be extended this like:
>
> ```
> class Foo:
> variable_both_class_and_instance: Union[ClassVar[Field], int] =
> Field(desc="descriptive string")
>
> def __init__(self, value: int):
> self.variable_both_class_and_instance = value
>
> assert isinstance(Foo.variable_both_class_and_instance, Field)
> assert isinstance(Foo().variable_both_class_and_instance, int)
> ```
>
> Do you have any ideas or comments about this?
> ___
> 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/7XFIE6YGRGO3XKCR7MZGDN6CCGUNN6MR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/MD37VH7ZWB4PZVQ4ZJY7IIIU7DMGFQC5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: problem with Distributed File System Replication and Namespacing and different versions of Python 3

[Steve Holden]

I don't remember it being mentioned, but much of the traffic recently
migrated from this list to https://discuss.python.org/c/core-dev/23, which
you may wish to keep in touch with.

Kind regards,
Steve


On Tue, Oct 25, 2022 at 7:53 AM Juan Cristóbal Quesada <
rainonthescarecrowhumanwhe...@gmail.com> wrote:

> Hi Steve,
> thanks! Will definitely have a look at it as soon as i can.
>
> Many thanks to all of you that replied. It was my first post in such
> python mailing lists and wasnt sure how accurate of a response i could
> have. You never know how active the mailing lists/forums are.
>
> Best Regards,
> JC
> ___
> 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/EJK5AFATVF6D44TVQRGSIXFHWTUDE6IS/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/HMEDAUC6O7NFVVMLEE3OLAVPPH6H67FV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Descriptions in unittest and avoiding confusion

[Steve Holden]

On Mon, Apr 4, 2022 at 4:13 PM Coyot Linden (Glenn Glazer) <
co...@lindenlab.com> wrote:

> I would like to point out another use case of triple quotes outside of
> docstrings. We do a lot of SQL here and so doing a parameterized query
> like:
>
> """SELECT foo
> FROM bar
> WHERE baz = %s"""
>
> is a whole lot cleaner and more natural than
>
> ("SELECT foo" +
> "FROM bar" +
> "WHERE baz = %s")
>
[...]

In the interests of fairness I should point out that the concatenation
operators are redundant in the second example, and without them (thanks to
the parentheses) the literals will be concatenated at compile time. I often
use

  (code of some sort)'''\
SELECT foo
FROM bar
WHERE baz = %s"""

to ensure the multiline string literal is correctly aligned, making
indentation issues easier to diagnose.

regards
 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/JL4TUDTSSSNSSFB7WJZTPXDUK6CPZDTG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Enhancing generic type documentation in the standard library

[Steve Holden]

Not defining the semantics of annotations was a brave move, but
inevitably led to the situation where different use cases, all
quite reasonable, would spring into being. Now they have, the development
team has to decide a) which ones to sanction and b) which will be left out
in the cold.

I wish them well.

Kind regards,
Steve


On Wed, Mar 30, 2022 at 5:24 PM Christopher Barker 
wrote:

> > I personally would love for a typing.python.org or equivalent
> subsection of docs.python.org to exist.
>
> +1
>
> There’s a wrinkle here, however. The type specs are Python, but how they
> are used/interpreted is up to third party packages.
>
> So it’s a bit tricky to know exactly what to document where.
>
> I don’t think that’s insurmountable, but something to keep in mind.
>
> For example, while the clear specs are the first step, what the community
> really could use is a good “recommended practices for static typing” doc —
> and that’s harder to do without reference to particular tools.
>
> -CHB
>
>
> --
> Christopher Barker, PhD (Chris)
>
> Python Language Consulting
>   - Teaching
>   - Scientific Software Development
>   - Desktop GUI and Web Development
>   - wxPython, numpy, scipy, Cython
> ___
> 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/YF5UIQIWNVIANFOCIQ2J4DJACQGJDGVM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/NW3SRUA2H3KNZBD4CICXY5QF2YWELUV5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Steve Holden]

Time for a __legacy__ package?

Kind regards,
Steve


On Sun, Mar 27, 2022 at 7:06 PM Paul Moore  wrote:

> On Sun, 27 Mar 2022 at 17:11, Christopher Barker 
> wrote:
> >
> > With the json package included, all they need to do is `import json`. If
> that wasn't there, they's look in PyPi for a JSON implementation, and find
> an absolutely astonishing number of options. I just did a search for "JSON"
> >  on PYPI, and it's HUGE -- most of them are for specialized JSON-using
> protocols of some sort. I was actually really surprised that couple I know
> about of the top of my head (ujson, orjson) are actually hard to find.
> >
> > "You can just pip install it" is really not a good solution.
> >
> > In fact, this is an example, I think, of where we should put some effort
> into making the included batteries better -- it's great to have a JSON lib
> built in, but it's too bad that it's not best-of-bread by pretty much any
> definition (speed, memory performance, flexibility) -- there are quite a
> few feature requests open for it -- it would be nice to actually implement
> some of those. (but yes, that's a lot of work that someone(s) would have to
> do)
> >
> > Back to the topic at hand, rather than remove urllib, maybe it could be
> made better -- an as-easy-to-use-as-requests package in the stdlib would be
> really great.
>
> I think that's where the mistake happens, though. Someone who needs
> "best of breed" is motivated (and likely knowledgeable enough) to make
> informed decisions about what's on PyPI. But someone who just wants to
> get the job done probably doesn't - and that's the audience for the
> stdlib. A stdlib module needs to be a good, reliable set of basic
> functionality that non-experts can use successfully. There can be
> better libraries on PyPI, but that doesn't mean the stdlib module is
> unnecessary, nor does it mean that the stdlib has to match the PyPI
> library feature for feature.
>
> So here, specifically, I'd rather see urlllib be the best urlllib it
> can be, and not demand that it turn into requests. Requests is there
> if people need/want it (as is httpx, and urllib3, and aiohttp). But
> urllib is for people who want to get a file from the web, and *not*
> have to deal with dependencies, 3rd party libraries, etc.
>
> The "batteries included" standard library and PyPI complement each
> other. Neither is redundant, and neither implies the other is
> unnecessary.
>
> Paul
> ___
> 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/E2FGXTYOEYLC6GSJGMWBQKHOO62LZPHQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/XGHKV3G5PJO3U4B6QTZRZSXIPNC4XDCL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

[Steve Holden]

On Tue, Jan 11, 2022 at 6:24 PM Guido van Rossum  wrote:

> I personally think F-strings should not be usable as docstrings. If you
> want a dynamically calculated docstring you should assign it dynamically,
> not smuggle it in using a string-like expression. We don't allow "blah {x}
> blah".format(x=1) as a docstring either, not "foo %s bar" % x.
>

I came to the conclusion that something like jinja2, operating on a Python
template, was a better way to go.
___
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/OK7HQ44SIWDRDHZPKPCNKUJ4YAZ5QGXK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The current state of typing PEPs

[Steve Holden]

On Tue, Nov 30, 2021 at 5:05 PM Steven D'Aprano  wrote:

> On Tue, Nov 30, 2021 at 02:30:18PM +, Paul Moore wrote:
> [...]
> Aside: I'm a little disappointed in the way the typing ecosystem has
> developed. What I understood was that we'd get type inference like ML or
> Haskell use, so we wouldn't need to annotate *everything*, only the bits
> needed to resolve ambiguity. But what we seem to have got is typing like
> C, Pascal and Java, except gradual. Am I being unreasonable to be
> disappointed? I'm not a heavy mypy user, I just dabble with it
> occasionally, so maybe I've missed something.
>
> You might be more comfortable with pytype, which I understand is much more
inferential than pypy.

>
> > Anyway, we're *way* off topic now, and I doubt there's much that the
> > SC or python-dev can do to change the community view on typing,
> > anyway.
>
> Heh. We could update PEP 8 to ban type annotations, then watch as the
> people who over-zealously apply PEP 8 to everything AND over-zealously
> insist on adding type annotations to everything have their heads
> explode.
>
> Cruel, but funny.
___
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/QX6MZXQRERQITQFPO7T5DLI4HHFXHX4B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

[Steve Holden]

On Mon, Nov 15, 2021 at 8:42 AM Kyle Stanley  wrote:

> On Sat, Nov 13, 2021 at 5:04 PM  wrote:
>
>>
>>
>> def 횑퓮햑풍표():
>>
> [... Python code it's easy to believe isn't grammatical ...]

> return ₛ
>>
>
> 0_o color me impressed, I did not think that would be legal syntax. Would
> be interesting to include in a textbook, if for nothing else other than to
> academically demonstrate that it is possible, as I suspect many are not
> aware.
>

I'm afraid the best Paul, Alex, Anna and I can hope to do is bring it to
the attention of readers of Python in a Nutshell's fourth edition (on
current plans, hitting the shelves about the same time as 3.11, please tell
your friends ;-) ). Sadly, I'm not aware of any academic classes that use
the Nutshell as a course text, so it seems unlikely to gain the
attention of academic communities.

Given the wider reach of this list, however, one might hope that by the
time the next edition comes out this will be old news due to the
publication of blogs and the like. With luck, a small fraction of the
programming community will become better-informed about Unicode and the
design or programming languages. It's interesting that the egalitarian wish
to allow use of native "alphabetics" has turned out to be such a viper's
nest.

Particular thanks to Stephen J. Turnbull for his thoughtful and
well-informed contribution above.

Kind regards,
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/FNSI6EXCWMMCXEJNYWVVR5LMFOM6M5ZB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove asyncore, asynchat and smtpd modules

[Steve Holden]

Speaking as the author of the doc pages, I think I can safely say that
anyone who was smart enough to use asyncore/asychat back in the day (I used
it in "Python Web Programming") is almost certainly smart enough to have
migrated away from them long ago. They were an interesting approach to
asynchronous networking, but I think it's safe to say that world has moved
on in 20 years.

Kind regards,
Steve


On Wed, Nov 17, 2021 at 6:13 AM Kyle Stanley  wrote:

> I think it would be fine to wait just one release, until 3.12. Makes no
> substantial maintenance difference and maybe easier for users with more
> advanced notice, especially for module removal.
>
> I also wonder if maybe we should scale delay between dep -> removal based
> on maintenance burden estimate, rather than 2 versions for all. Module
> removal certainly takes more effort to adjust in code vs simple function
> name change with 1:1 replacement.
>
> --
> --Kyle R. Stanley, Python Core Developer (what is a core dev?
> )
> *Pronouns: they/them **(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/F52UKISVFFGBNCL2AZ4XVX2KL35O6ZNH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/I6LJVGXIRNATRNAQG6RFMMPKXDANSBEL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should the definition of an "(async) iterator" include __iter__?

[Steve Holden]

I understood that _iterables_ are required to have an __iter__ method, not
iterators.

Therefore, are we simply discussing whether all iterators should be
iterable? At the moment the CPython implementation does't require that
AFAIK.

regards
 Steve

On Tue, Sep 14, 2021 at 8:39 PM Guido van Rossum  wrote:

> My view of this is:
>
> A. It's not an iterator if it doesn't define `__next__`.
>
> B. It is strongly recommended that iterators also define `__iter__`.
>
> In "standards" language, I think (A) is MUST and (B) is merely OUGHT or
> maybe SHOULD.
>
> On Tue, Sep 14, 2021 at 12:30 PM Brett Cannon  wrote:
>
>> Over in https://github.com/python/typeshed/issues/6030 I have managed to
>> kick up a discussion over what exactly an "iterator" is. If you look at
>> https://docs.python.org/3/library/functions.html#iter you will see the
>> docs say it "Return[s] an iterator
>>  object." Great,
>> but you go the glossary definition of "iterator" at
>> https://docs.python.org/3/glossary.html#term-iterator you will see it
>> says "[i]terators are required to have an __iter__()
>> 
>> method" which neither `for` nor `iter()` actually enforce.
>>
>> Is there something to do here? Do we loosen the definition of "iterator"
>> to say they *should* define __iter__? Leave it as-is with an
>> understanding that we know that it's technically inaccurate for iter() but
>> that we want to encourage people to define __iter__? I'm assuming people
>> don't want to change `for` and `iter()` to start requiring __iter__ be
>> defined if we decided to go down the "remove the __aiter__ requirement"
>> from aiter() last week.
>>
>> BTW all of this applies to async iterators as well.
>> ___
>> 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/3W7TDX5KNVQVGT5CUHBK33M7VNTP25DZ/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/OICGRBPLXO6WXO4CHTGUK46WIHO7PDUU/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/KHDMNMW6XEPYOZ5AQ22AN6YTN2POMHQE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Steve Holden]

I suspect it's the same motivation that makes us comment out a block of
code rather than deleting it, even though we know the VCS will let us
retirive it whenever we want. If I'm wrong it won't be fatal. Or surprising
;-)

Kind regards,
Steve


On Wed, Aug 25, 2021 at 8:53 PM Eric V. Smith  wrote:

> I think we’re better off removing them. 2.7 is completely unsupported by
> us.
>
> Why do you think they should still be kept?
>
> --
> Eric
>
> > On Aug 25, 2021, at 1:32 PM, Mike Miller 
> wrote:
> >
> > 
> > How about moving Python 2 notes into a section at the bottom?
> >
> >
> > -Mike
> > ___
> > 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/76JIO4AF7WMJ5475FTIHTK6GR2O52OOF/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> ___
> 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/235UK4OXI4CVBDQ5AFTS54OFCATSO7X4/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/6M3H2XQF6ULUVANZV7GAEUIJIS5XM3G7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: My apologies to the list

[Steve Holden]

You forgot:

5. When I just don't damned well feel like it.

Kind regards,
Steve


On Wed, Aug 25, 2021 at 8:25 PM Brett Cannon  wrote:

> I just wanted to apologize for any angst or noise my replies to Marco
> caused folks. I should have known that correcting Marco on how to address
> me would have triggered an outsized reply (the real intent of that overall
> email was to communicate the process of banning someone to the rest of the
> list so people didn't leave faster than we addressed it; obviously didn't
> work). It appears my judgement was more impaired than I realized while I
> have been sick.
>
> As such, I have amended my rules for when I *don't* read OSS emails (this
> excludes SC business):
>
>1. At least one day every weekend (to avoid having my whole week
>ruined by mean people)
>2. Outside of work hours one month out of the year (to prevent
>burn-out)
>3. On vacation (to unplug appropriately)
>4. While I am ill (to prevent impaired judgement)
>
> I have actually gone as far as to separate my personal email and OSS/
> python.org email accounts into separate email providers so that I can
> enforce this separation cleanly.
> ___
> 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/ONUW2TMLJPQ54FSQBC2IKYMBEXGCSJHR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/3QD6OO5YS7DCUYEL3YUGLWZDVGE7OXYS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Problems with dict subclassing performance

[Steve Holden]

Your inflated sense of your own significance is unfortunate, since it
appears to prohibit you from considering the possibility you might have
made a rather silly mistake here, and one which is calculated to move you
further away from your stated goals.

Kind regards,
Steve


On Tue, Aug 17, 2021 at 9:31 PM Marco Sulla 
wrote:

> On Sun, 15 Aug 2021 at 22:30, Marco Sulla 
> wrote:
> > Oh, this is enough. The sense of the phrase was very clear and you all
> > have understood it. Remarking grammatical errors is a gross violation
> > of the Netiquette. I ask __immediately__ the intervent of a moderator,
> > even if I quite sure, since I'm mister No One and you are Terry Reed
> > and Steven D'Aprano, that this will be against me X-D
>
> Ahahhaahh, call me Marco "Cassandra" Sulla.
>
> Mr. Cannon, I was sure about your response. Please ban me, it will be
> a pleasure to be banned by you for specious reasons. It's your
> specialty.
>
> I want to remember here that you banned me from the Py Forum because I
> said "Even a child can understand my code", and you _demanded_ my
> excuses. Since I found the accusation ridiculous, I've made my excuses
> to all children that do not understand my code. You banned me and even
> Steven defended me.
>
> I've been the moderator for a forum for years, and let me say, you are
> not a good moderator. You are hard-mannered. See Tim. He calmed me
> down with two posts. You all have to learn from him, as coders,
> moderators and human beings.
>
> That said, please ban me permanently, because I'll _never_ give you my
> excuses. What I said is the pure truth.
>
> PS: as a side note, I started to get downvotes from when this useless
> polemic started. Since, I repeat, I have more than 13k reputation on
> SO, and since the question had about 20 votes without dirty tricks, as
> Steven subtly insinuates, all of this makes me laugh. Do your worst,
> you all little men. As a Mister No One, I will be **PROUD** to be
> banned as Stephan Krah.
>
>
> On Mon, 16 Aug 2021 at 18:52, Brett Cannon  wrote:
> >
> >
> >
> > On Sun, Aug 15, 2021 at 2:55 PM Marco Sulla <
> marco.sulla.pyt...@gmail.com> wrote:
> >>
> >> On Sun, 15 Aug 2021 at 23:33, Tim Peters 
> >> wrote:ople have said now, including me, they had no idea what
> >> > you meant.by "I pretend your immediate excuses". It's not a complaint
> >> > that it's expressed inelegantly, but that they can't make _any_ sense
> >> > of it. By my count, this is at least the second time you've declined
> >> > to explain what you meant, but instead implied the person who said
> >> > they couldn't understand it was being dishonest.
> >>
> >> I repeat, even the worst AI will understand from the context what I
> >> meant. But let me do a very rude example:
> >
> >
> > Rude examples are never necessary and are not acceptable (don't forget
> we have kids who participate on this mailing list).
> >
> > I have referred the whole thread to the Conduct WG so they can settle
> who was out of line. Otherwise I advise everyone to mute this thread.
> ___
> 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/BM4AQR347MPNXRDF3FHBYPOOXPHMYQU2/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/LMWTDGYBRKO5BBL2MNRQB2VEXNQ6G426/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Steve Holden]

On Wed, Aug 11, 2021 at 7:09 AM Larry Hastings  wrote:

> On 8/10/21 11:15 AM, Thomas Grainger wrote:
>
> Although the co_annoations code could intercept the NameError and replace 
> return a ForwardRef object instead of the resolved name
>
>
> No, it should raise a NameError, just like any other Python code.
> Annotations aren't special enough to break the rules.
>
> I worry about Python-the-language enshrining design choices made by the
> typing module.  Python is now on its fourth string interpolation
> technology, and it ships with three command-line argument parsing
> libraries; in each of these cases, we were adding a New Thing that was
> viewed at the time as an improvement over the existing thing(s).  It'd be
> an act of hubris to assert that the current "typing" module is the
> ultimate, final library for expressing type information in Python.  But if
> we tie the language too strongly to the typing module, I fear we could
> strangle its successors in their cribs.
>
>
> Which would be unfortunate given the (explicit?) assurances that
annotations would be optional; they are casting their shadow over the whole
language.
___
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/XFR3KNKDYYXDXVQNDP6XPTGBBHA32AVI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 649: Deferred Evaluation Of Annotations

[Steve Holden]

On Wed, Aug 11, 2021 at 2:27 PM Guido van Rossum  wrote:

> As it happens, I have a working prototype of lazy in marshaling that would
> work well for this.
>
> Nice to see you keep the time machine in working order ...

Kind regards,
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/PIMCZCDZ2SN2QDAFE3ORZTURIURHYF4K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is the Python review process flawed?

[Steve Holden]

On Fri, Jul 2, 2021 at 12:47 AM  wrote:

> Okay so I just code a little bit and I used the multiprocessing module but
> my code didn't work and I found the solution on Stack Overflow and it
> turned out to be not my mistake (which has never happened before I think).
> Instead I found out it's a bug in Python and the issue on Github was linked
> so I opened it and I was surprised to see what's going on "behind the
> scenes".
>
> Yes I have basically no experience in maintaining any big project. So when
> you're saying "You don't know what it's like and therefore your complaint
> doesn't make sense" then you're not wrong and I just have to believe you.
> But I think this is a dangerous argument because it could also be used to
> shut up anything and anybody. (I'm not saying this is the case here.)
> Therefore, this argument should rarely be used in my opinion. From an
> outsider's perspective it just looks really weird that a bugfix from 2017
> hasn't become a priority to get merged, like the process is flawed. That's
> all. I didn't mean to attack any one of you. I want to make that clear
> because it feels like some of you got kinda defensive about it.
>
> I don't think anyone felt attacked. The hard-working devs are merely
trying to explain the facts of life, and if exasperation occasionally
creeps in that's probably because this is far from the first time this
issue has been raised here. (You'll note I refer to the core devs in the
third person, since I am not one of them and neither do I speak for them, I
am merely recording my observations).

"There's been quite a bit of discussion on both of them" - None of the
> discussions left any questions unanswered. Except for the question of when
> the pull request will get merged.
>
> "Merging something is also a responsibility to whoever does it" - And it's
> also a responsibility to fix bugs, no? I don't get why you're so afraid of
> (maybe!) introducing a new bug when there already (certainly!) is a bug.
>
> Whose "responsibility" do you think it should be to fix bugs?  Who do you
think should set priorities to determine which work is done first. Few core
developers are paid to work on Python, and even those that are (until the
PSF's developer is appointed) might expect to have their overall priorities
set by their employer. As a consumer of their work who's made little
contribution to the language I don't personally feel that I have much right
to dictate how devs spend their time. I'm just glad so many of them do.

The fact is that for any community-run open source project the only
reliable way to ensure PRs get merged is to acquire commit rights and do it
yourself. It's by no means ideal, but that's the current reality for Python.

"Oops. I'm really sorry for giving false hopes, then, because I don't think
> I'm motivated to review this PR. I'm not really maintaining multiprocessing
> these days, anymore" - No worries dude. This not about one person or one
> bug. I'm sorry that the issue that I stumbled upon turned out to be one
> where you said you'd put it on your list.
>
> "What if that one line change is even more wrong than before?" - Yes of
> course there's a risk. Just like there was a risk when you merged the
> original code which contained the bug, right?! At some point you have to
> say yes that looks okay let's merge it, even though there is a slight
> chance it could contain a mistake. And it is not obvious to me (and many
> other people who commented in those github threads) what else would
> possibly be needed. After all, there are currently actual people who are
> affected by the bug - and you're only talking about hypothetical people
> being affected by a possibly wrong bugfix.
>
> Let's assume that it takes an hour to properly review and merge a PR. If
someone only has five hours a week to work on Python they are hardly going
to consider spending 20% of their available time tht week on
sometthing unrelted to the work they've been doint of rk

> "When I got the shutil.which feature merged, the PR had been open for I
> believe 11 years" - Totally different topic. I explicitly said in my
> initial message, that I'm talking about a bugfix, not a new feature.
>
> "If you would like more value out of it or to speed up the process, you
> can provide your own reviews." - Seriously? I can't help but feel like that
> comment sounds kinda arrogant. I hope I'm misunderstanding you. Look at
> that link and Stack Overflow post again how many people commented and voted
> that the patch fixed their issues. How many more people do you want?
>
> It isn't a matter of summoning the desire, it's a matter of allocating
time.


> "*maintainer attention* is actually the scarcest resource in many open
> source projects, and Python is no exception." - Then get more people to do
> this? Don't tell me Python isn't big enough to find some companies or funds
> to sponsor a few people to work the dreaded reviewer job a few hours a
> week? Or let more amateur coders 

[Python-Dev] Re: name for new Enum decorator

[Steve Holden]

On Fri, May 28, 2021 at 10:26 PM Ethan Furman  wrote:

> On 5/28/21 12:43 AM, Petr Viktorin wrote:
>  > On 28. 05. 21 5:24, Ethan Furman wrote:
>
>  >>  class FlagWithMasks(IntFlag):
>  >>  DEFAULT = 0x0
>  >>
>  >>  FIRST_MASK = 0xF
>  >>  FIRST_ROUND = 0x0
>  >>  FIRST_CEIL = 0x1
>  >>  FIRST_TRUNC = 0x2
>  >>
>  >>  SECOND_MASK = 0xF0
>  >>  SECOND_RECALC = 0x00
>  >>  SECOND_NO_RECALC = 0x10
>  >>
>  >>  THIRD_MASK = 0xF00
>  >>  THIRD_DISCARD = 0x000
>  >>  THIRD_KEEP = 0x100
>  >>
>  >> Here we have three flags (FIRST_MASK, SECOND_MASK, THIRD_MASK) that
> are aliasing values
>  >> that don't exist, but it seems intentional and not an error.
>  >
>  > Are you looking for a decorator for the whole Enum, or a way to mark
> individual *values* as masks?
>
> The decorator is for whole enum.  The issue is not that some values are
> masks, but whether the absence of named bits
> covered by the mask is an error.
>
> If all masked bits must be defined by individual values then it's a
completely_masked  enum? This is quite a bikeshed we're painting here! ;-)

Kind regards,
Steve


> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/OM5M774MP5QPLFXZ7OVGBPR7ZFB6X35A/
>
___
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/QMTTXVEI6TDFBXLT62QZME3S6QT5QZ33/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Steve Holden]

On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano 
wrote:

> Steve
> (one of the other ones)
>

We are all other Steves!
___
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/NRESFICCEFQGUYUIQMMPO2E7SOUQDXRI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Steve Holden]

On Thu, May 13, 2021 at 9:18 AM Mark Shannon  wrote:

> Hi Terry,
>
> On 13/05/2021 5:32 am, Terry Reedy wrote:
> > On 5/12/2021 1:40 PM, Mark Shannon wrote:
> >
> >> This is an informational PEP about a key part of our plan to improve
> >> CPython performance for 3.11 and beyond.
> >
> >> As always, comments and suggestions are welcome.
> >
> > The claim that starts the Motivation section, "Python is widely
> > acknowledged as slow.", has multiple problems. While some people
> [...]

> different runtime.
>
> I broadly agree, but CPython is largely synonymous with Python and
> CPython is slower than it could be.
>
> The phrase was not meant to upset anyone.
> How would you rephrase it, bearing in mind that needs to be short?
>
> "There is broad interest in improving the performance of pure Python code.
[optionally: The integration of powerful numerical and other algorithms
already makes Python competitive at intensive computations, but programmers
whose main interest is in solving non-programming problems cannot
generally create such solutions.]"

[...]

hopefully make it less of a concern.
>
> Of course, compared to the environmental disaster that is BitCoin, it's
> not a big deal.


Every little helps. Please switch off the light as you leave the room.

[...]

> It is still important to speed up Python though.
>
> Agreed.


> If a program does 95% of its work in a C++ library and 5% in Python, it
> can easily spend the majority of its time in Python because CPython is a
> lot slower than C++ (in general).
>
> That's a pretty loose statement, but I see no reason to quibbe about the
details. There's room for improvement, and improvement will be welcome.
___
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/XCQ7OHDJRIR5WYIHHURHOJYW4NW6RNBZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Steve Holden]

On Fri, Apr 16, 2021 at 7:15 PM Denis Kotov  wrote:

> Ethan Furman wrote:
> > On 4/16/21 10:43 AM, redrad...@gmail.com wrote:
> > > Take a look at this video https://www.youtube.com/watch?v=D7Sd8A6_fYU
> > > or read some articles ... otherwise I will need to spend too many time
> providing evidences to you and after all you will probably will reject
> anyway (because lots of people is biased and they even do not understand
> that, it is not about you, it is in general)
> > > You are the one proposing the change, so it's up to you to provide the
> evidence for it.  If you aren't willing to put in
> > a few hours for that effort, why should we put the weeks and months to
> port the code over?
> > --
> > ~Ethan~
>
> I do not ask porting code, I ask using new code with C++ and if code was
> tested enough to reimplement it in C++ with RAII, 
>
> Also I suggest using C++ excepting that most of the people here now it ...
> It was not intended to teach C++ here, especially in Mail List )))
>
> And reason why you at least should try learn other languages, it is
> because it will make you better developer
>
Hi Denis,

While I can accept that your intentions are honourable, did you stop to
think that you are casting aspersions at a very capable and in many cases
senior developers by suggesting that the reason they will not adopt C++ as
an implementation language?

You are correct that there is a deal of inertia behind C as the
implementation language for CPython, as indeed there should be. It
represents a huge investment, and has created valuable artefacts. As
someone who isn't a core developer but manages programmers professionally
it seems to me that you are ignoring many easily detectable issues, some
technical and some social.

   - Who will put in the engineering effort to ensure that C++ code is
   supported within CPython codebase on all supported platforms?
   - Who will create and maintain the extra tests this would require?
   - Who will handle the inevitable deep bugs that the introduction of a
   not-fully-compatible technology will create?
   - By how much would such a change enlarge the core developer community?
   I so far know of one person it would add—you! What's the return on the
   effort?

Remember, relatively few people are paid to work on CPython. Most do it for
love and/or to scratch personal technical itches. What would they get out
of the adoption of C++. While your enthusiasm is welcome, it's beginning to
become a little wearing. Perhaps there's some history in the
python-dev archives that would inform you of previous discussions and help
you repeating already-considered arguments. I'm struggling to see the
benefits here, and your presumption that experienced team members should
immediately be persuaded by your arguments seems a little, well,
presumptuous.


> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/BWL6BIGR4NQBQSZM3OWLEB74U764PAYV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: gzip.py: allow deterministic compression (without time stamp)

[Steve Holden]

DEFAULT_TIMESTAMP?

Kind regards,
Steve


On Wed, Apr 14, 2021 at 8:03 PM  wrote:

> If the so, then a better name than NO_TIMESTAMP should be chosen, as the
> gzip specification does not allow for no timestamp.
> ___
> 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/O3ENOZ5OAFYX6PBXMEDGS3RJ3OSPKNYC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/QAACKOOKU34IV7GRCRO4CWCJTAPB5VLB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem

[Steve Holden]

The old rule is best: be strict in what you produce and liberal i what you
accept.

Kind regards,
Steve


On Tue, Apr 13, 2021 at 12:52 AM Edwin Zimmerman 
wrote:

> On 4/12/2021 6:34 PM, Brett Cannon wrote:
>
> Had the sentences ended at "confusing" or said something like "I don't
> think it's as optimal as it could be" or "I think it could be better" are
> all fine. But saying that the current approach is "arousing or deserving
> ridicule : extremely silly or unreasonable : absurd, preposterous" as defined
> by Merriam-Webster 
> is not necessary to make the point; it could have been phrased in such a
> way as to be a bit more respectful to those who have put in the time and
> effort to get things to where they are.
>
> My plea is very simple: that everyone would be a bit more gracious.  Email
> by its very nature does not convey meaning as well as in-person
> conversation.  As Hugh just remarked, the meaning you took from his
> comments was not the meaning he intended to convey.  These
> misunderstandings seem to be happening more and more frequently.  I read
> this list to understand the direction that Python will take in the future,
> but I have thought numerous times of unsubscribing due to all the curt "you
> said it wrong" responses like the one that triggered my first email.
>
> Any way, in the interest of not starting a flame war, I will have nothing
> more to say.
> ___
> 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/ETJCGR4ULRYY5WNOLRPULVWMBW4LCY3E/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/E7LWKNKS4CDRS4AZJBZVK5UJ2W6H6AD5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Security releases of CPython

[Steve Holden]

On Fri, Feb 19, 2021 at 10:53 PM Christian Heimes 
wrote:

> On 19/02/2021 23.22, Stestagg wrote:
> > The thing that stood out from this conversation, for me, is: Releases
> > are too hard, and there’s a risk of not having enough volunteers as a
> > result.
> >
> > How hard is it to fix that?
>
> Actually it's easy to fix!
>
> For some value of "easy"  that involves raising a six-figure dollar sum
annually ...

> The PSF needs needs sufficient money to hire a couple of people, so the
> PSF can turn release management and security maintenance from unpaid
> volunteers into paid fulltime jobs.
>

Oh, is that all? Sustainability of the PSF, as has been shown over its 20
years of existence, is not an easy thing to achieve. It was hit by
the financial crisis in 2008 and again by the coronavirus crisis last year,
both things that affected all foundations.

If you plan to bring this kind of money in and rely on it, you have to
ensure it comes from sources that can't just be switched off when budgets
tighten. It could be done, but "easy" sounds like exaggeration to me.
Unless your suggestions were joking, but I saw no smiley ...

Kind regards,
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/PUF4BTHGDFRV3P4WJ7EYWB5OTRXCTLR4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Concerns about PEP 634

[Steve Holden]

Good luck in your quest.

Kind regards,
Steve


On Sat, Feb 6, 2021 at 9:00 PM Ivan Pozdeev  wrote:

> Who said "__future__"? I said "3rd-party library". Independent from the
> CPython project.
> Maybe even a few of them -- to try out conflicting visions that emerged in
> the discussions.
> On 06.02.2021 23:58, Steve Holden wrote:
>
> My suggestion that it be introduced via __future__ due to its contentious
> nature met immediate resistance. No point going down that road.
>
> Kind regards,
> Steve
>
>
> On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
>
>> With such a large new area of functionality that's at odds with existing
>> syntax and semantics and a lack of clear vision and agreement, it
>> sounds like this would be better first added as a 3rd-party library to
>> let the syntax and semantics mature. (To allow new syntax, it'll
>> probably be parsing strings in that special syntax.)
>>
>> (At https://www.python.org/dev/peps/pep-0634/, there's no indication
>> that this option was considered.)
>>
>> On 06.02.2021 18:44, Mark Shannon wrote:
>> > Hi,
>> >
>> > Since a decision on PEP 634 is imminent, I'd like to reiterate some
>> concerns that I voiced last year.
>> >
>> > I am worried about the semantics and implementation of PEP 634.
>> > I don't want to comment on the merits of pattern matching in general,
>> or the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
>> >
>> > Semantics
>> > -
>> >
>> > 1. PEP 634 eschews the object model, in favour of adhoc instance
>> checks, length checks and attribute accesses.
>> >
>> > This is in contrast to almost all of the the rest of the language,
>> which uses special (dunder) methods:
>> >   All operators,
>> >   subscripting,
>> >   attribute lookup,
>> >   iteration,
>> >   calls,
>> >   tests,
>> >   object creation,
>> >   conversions,
>> >   and the with statement
>> >
>> > AFAICT, no justification is given for this.
>> > Why can't pattern matching use the object model?
>> >
>> > PEP 343 (the "with" statement) added the __enter__ and __exit__ methods
>> to the object model, and that works very well.
>> >
>> >
>> > 2. PEP 634 deliberately introduces a large area of undefined behaviour
>> into Python.
>> >
>> >
>> https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior
>> >
>> > Python has, in general, been strict about not having undefined
>> behaviour.
>> > Having defined semantics means that you can reason about programs, even
>> non-idiomatic ones.
>> > [This is not unique to Python, it is really only C and C++ that have
>> areas of undefined behaviour]
>> >
>> > I can see no good reason for adding undefined behaviour. It doesn't
>> help anyone.
>> >
>> > The lack of precise semantics makes programs harder to understand, and
>> it makes the language harder to implement.
>> > If the semantics aren't specified, then the implementation becomes the
>> specification.
>> > This bakes bugs into the language and makes it harder to maintain,
>> > as bug-for-bug compatibility must be maintained.
>> >
>> >
>> > 3. Performance
>> >
>> > PEP 634 says that each pattern must be checked in turn.
>> > That means that multiple redundant checks must be performed on (for
>> example) a sequence if there are several mapping patterns.
>> > This is unnecessarily slow.
>> >
>> >
>> > Implementation
>> > --
>> >
>> > My main concern with the implementation is that it does too much work
>> into the interpreter.
>> > Much of that work can and should be done in the compiler.
>> > For example, deep in the implementation of the MATCH_CLASS instruction
>> is the following comment:
>> > https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981
>> >
>> > Such complex control flow should be handled during compilation, rather
>> than in the interpreter.
>> > Giant instructions like MATCH_CLASS are likely to have odd corner cases,
>> > and may well have a negative impact on the performance of the rest of
>> the language.
>> > It is a lot easier to reason about a sequence of simple bytecodes, than
>> one giant one with context-dependent behaviour.
>> >
&g

[Python-Dev] Re: Concerns about PEP 634

[Steve Holden]

My suggestion that it be introduced via __future__ due to its contentious
nature met immediate resistance. No point going down that road.

Kind regards,
Steve


On Sat, Feb 6, 2021 at 8:15 PM Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> With such a large new area of functionality that's at odds with existing
> syntax and semantics and a lack of clear vision and agreement, it
> sounds like this would be better first added as a 3rd-party library to let
> the syntax and semantics mature. (To allow new syntax, it'll
> probably be parsing strings in that special syntax.)
>
> (At https://www.python.org/dev/peps/pep-0634/, there's no indication that
> this option was considered.)
>
> On 06.02.2021 18:44, Mark Shannon wrote:
> > Hi,
> >
> > Since a decision on PEP 634 is imminent, I'd like to reiterate some
> concerns that I voiced last year.
> >
> > I am worried about the semantics and implementation of PEP 634.
> > I don't want to comment on the merits of pattern matching in general, or
> the proposed syntax in PEP 634 (or PEP 640 or PEP 642).
> >
> > Semantics
> > -
> >
> > 1. PEP 634 eschews the object model, in favour of adhoc instance checks,
> length checks and attribute accesses.
> >
> > This is in contrast to almost all of the the rest of the language, which
> uses special (dunder) methods:
> >   All operators,
> >   subscripting,
> >   attribute lookup,
> >   iteration,
> >   calls,
> >   tests,
> >   object creation,
> >   conversions,
> >   and the with statement
> >
> > AFAICT, no justification is given for this.
> > Why can't pattern matching use the object model?
> >
> > PEP 343 (the "with" statement) added the __enter__ and __exit__ methods
> to the object model, and that works very well.
> >
> >
> > 2. PEP 634 deliberately introduces a large area of undefined behaviour
> into Python.
> >
> >
> https://www.python.org/dev/peps/pep-0634/#side-effects-and-undefined-behavior
> >
> > Python has, in general, been strict about not having undefined behaviour.
> > Having defined semantics means that you can reason about programs, even
> non-idiomatic ones.
> > [This is not unique to Python, it is really only C and C++ that have
> areas of undefined behaviour]
> >
> > I can see no good reason for adding undefined behaviour. It doesn't help
> anyone.
> >
> > The lack of precise semantics makes programs harder to understand, and
> it makes the language harder to implement.
> > If the semantics aren't specified, then the implementation becomes the
> specification.
> > This bakes bugs into the language and makes it harder to maintain,
> > as bug-for-bug compatibility must be maintained.
> >
> >
> > 3. Performance
> >
> > PEP 634 says that each pattern must be checked in turn.
> > That means that multiple redundant checks must be performed on (for
> example) a sequence if there are several mapping patterns.
> > This is unnecessarily slow.
> >
> >
> > Implementation
> > --
> >
> > My main concern with the implementation is that it does too much work
> into the interpreter.
> > Much of that work can and should be done in the compiler.
> > For example, deep in the implementation of the MATCH_CLASS instruction
> is the following comment:
> > https://github.com/brandtbucher/cpython/blob/patma/Python/ceval.c#L981
> >
> > Such complex control flow should be handled during compilation, rather
> than in the interpreter.
> > Giant instructions like MATCH_CLASS are likely to have odd corner cases,
> > and may well have a negative impact on the performance of the rest of
> the language.
> > It is a lot easier to reason about a sequence of simple bytecodes, than
> one giant one with context-dependent behaviour.
> >
> > We have spent quite a lot of effort over the last few years streamlining
> the interpreter.
> > Adding these extremely complex instructions would be a big backward step.
> >
> >
> > Cheers,
> > Mark.
> > ___
> > 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/HC6XDUASX2EELTA4L5R73BSYNJPTAYNL/
> > Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
> 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/OGXG4TIZQ35QGZ23JNAP4OAGEEW4COUK/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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 

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

[Steve Holden]

If the length of the name is any kind of issue, since the stdlib
only contains modules (and packages), why not just sys.stdlib_names?


On Mon, Jan 25, 2021 at 5:18 PM Victor Stinner  wrote:

> Hi Bernat,
>
> "stdlib_module_names" was my first idea but it looks too long, so I
> chose "module_names". But someone on Twitter and now you asked me why
> not "stdlib_module_names", so I wrote a PR to rename module_names to
> sys.stdlib_module_names:
> https://github.com/python/cpython/pull/24332
>
> At least "stdlib_module_names" better summarizes its definition: "A
> frozenset of strings containing the names of standard library
> modules".
>
> Victor
>
>
> On Mon, Jan 25, 2021 at 5:39 PM Bernat Gabor 
> wrote:
> >
> > Hello,
> >
> > In general, I love the idea and implementation. I'm not in love with the
> name though, it makes it sound like it contains all module names
> imported/available. We have sys.module already containing all module
> imported. So without a deeper knowledge sys.modules_names is very close to
> sys.module.keys() or all available modules. Can we name it instead
> sys.stdlib_modules_names to clarify that this is standard library only
> subset and not all available modules for the interpreter?
> >
> > Thanks,
> >
> > On Mon, Jan 25, 2021 at 4:33 PM Victor Stinner 
> wrote:
> >>
> >> Hi Ivan,
> >>
> >> On Mon, Jan 25, 2021 at 4:53 PM Ivan Pozdeev via Python-Dev
> >>  wrote:
> >> > Just _names_? There's a recurring error case when a 3rd-party module
> overrides a standard one if it happens to have the same name. If you
> >> > filter such a module out, you're shooting yourself in the foot...
> >>
> >> Overriding stdlib modules has been discussed in the issue.
> >>
> >> For example, it was proposed to add an attribute to all stdlib modules
> >> (__stdlib__=True or __author__ = 'PSF'), and then check if the
> >> attribute exists or not. The problem is that importing a module to
> >> check for its attribute cause side effect or fail, and so cannot be
> >> used for some use cases. For example, it would be a surprising to open
> >> a web browser window when running isort on a Python code containing
> >> "import antigravity". Another problem is that third party can also add
> >> the attribute to pretend that their code is part of the stdlib.
> >>
> >> In a previous version of my PR, I added a note about sys.path and
> >> overriding stdlib modules, but I have been asked to remove it. Feel
> >> free to propose a PR to add such note if you consider that it's
> >> related to sys.module_names.
> >>
> >> Please read the discussion at https://bugs.python.org/issue42955 and
> >> https://github.com/python/cpython/pull/24238
> >>
> >> Victor
> >> ___
> >> 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/7HMWTGBECAVLINLO3MAEN74YVDHOMZKM/
> >> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/WJMYK2JKZPTXMID7WRMP4KMJ656WEMI5/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/2JXT2M2DU2ZLPLPJF5LX3UVPRGWXKVPW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: macOS issues with 3.8.7rc1

[Steve Holden]

A general wish not to disadvantage those with older hardware any more than
they already are?

Just a shot in the dark.


On Wed, Dec 9, 2020 at 6:17 PM Gregory P. Smith  wrote:

>
>
> As a meta question: Is there a good reason to support binaries running on
> macOS earlier than ~ $latest_version-1?
>
> Aren't systems running those old releases rather than upgrading
> unsupported by Apple, never to be patched, and thus not wise to even have
> on a network?
>
> Yes, that means some very old hardware becomes useless as Apple drops
> support. But that is what people signed up for when they bought it. Why
> should that be our problem?
>
> (It sounds like y'all will make it work, that's great! I'm really just
> wondering where the motivation comes from)
>
> -gps
>
> On Wed, Dec 9, 2020, 9:25 AM Gregory Szorc 
> wrote:
>
>> On Wed, Dec 9, 2020 at 4:13 AM Ronald Oussoren 
>> wrote:
>>
>>>
>>>
>>> On 8 Dec 2020, at 19:59, Gregory Szorc  wrote:
>>>
>>> Regarding the 3.8.7rc1 release, I wanted to raise some issues regarding
>>> macOS.
>>>
>>> Without the changes from https://github.com/python/cpython/pull/22855
>>> backported, attempting to build a portable binary on macOS 11 (e.g. by
>>> setting `MACOSX_DEPLOYMENT_TARGET=10.9`) results in a myriad of `warning:
>>> 'XXX' is only available on macOS 10.13 or newer
>>> [-Wunguarded-availability-new]` warnings during the build. This warning
>>> could be innocuous if there is run-time probing in place (the symbols in
>>> question are weakly linked, which is good). But if I'm reading the code
>>> correctly, run-time probing was introduced by commits like eee543722 and
>>> isn't present in 3.8.7rc1.
>>>
>>> I don't have a machine with older macOS sitting around to test, but I'm
>>> fairly certain the lack of these patches means binaries built on macOS 11
>>> will blow up at run-time when run on older macOS versions.
>>>
>>> These same patches also taught CPython to build and run properly on
>>> Apple ARM hardware. I suspect some people will care about these being
>>> backported to 3.8.
>>>
>>> We know. Backporting the relevant changes to 3.8 is taking more time
>>> than I had hoped. It doesn’t help that I’ve been busy at work and don’t
>>> have as much energy during the weekend as I’d like.
>>>
>>> The backport to 3.9 was fairly easy because there were few changes
>>> between master and the 3.9 branch at the time. Sadly there have been
>>> conflicting changes since 3.8 was forked (in particular in posixmodule.c).
>>>
>>> The current best practice for building binaries that work on macOS 10.9
>>> is to build on that release (or rather, with that SDK).  That doesn’t help
>>> if you want to build Universal 2 binaries though.
>>>
>>
>> Thank you for your hard work devising the patches and working to backport
>> them.
>>
>> I personally care a lot about these patches and I have the technical
>> competency to perform the backport. If you need help, I could potentially
>> find time to hack on it. Just email me privately (or ping @indygreg on
>> GitHub) and let me know. Even if they don't get into 3.8.7, I'll likely
>> cherry pick the patches for
>> https://github.com/indygreg/python-build-standalone. And I'm sure other
>> downstream packagers will want them as well. So having them in an
>> unreleased 3.8 branch is better than not having them at all.
>> ___
>> 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/5AWFX2POTPNVW72VUPCPTJIOA6AOSVWY/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/Q45VNQYOYXTRRTA26Q4M2WNXPFKL4S2O/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/7ZSZVIVUVM35GELRKGXWAJ3HLYU6G6OJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The semantics of pattern matching for Python

[Steve Holden]

Fair enough.


On Fri, Nov 20, 2020 at 11:45 AM Thomas Wouters  wrote:

>
>
> On Fri, Nov 20, 2020 at 8:38 AM Steve Holden  wrote:
>
>> On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon  wrote:
>>
>> All I will say is just because we aren't *required* to implement it in
>> __future__ that doesn't mean we can't or shouldn't. Everything should be
>> done to underline the tentative nature of these developments, or we risk
>> the potential of functionality frozen because "we're already using it in
>> production."
>>
>
> On the other hand, __future__ imports have never been provisional, and it
> was never the *intent *of __future__ imports to be provisional. PEP 236,
> which introduced __future__ imports after a vigorous debate on backward
> compatibility, explicitly states "fully backward- compatible additions
> can-- and should --be introduced without a corresponding future_statement".
> I think it would be very surprising if a feature introduced under a future
> import turned out to go away rather than become the default.
>
> --
> Thomas Wouters 
>
> Hi! I'm an email virus! Think twice before sending your email to help me
> spread!
>
___
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/OD7YGKBLJFFMXYFMYWQZIX7UPHZG5ZR3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The semantics of pattern matching for Python

[Steve Holden]

On Thu, Nov 19, 2020 at 8:08 PM Brett Cannon  wrote:

>
>
> On Thu, Nov 19, 2020 at 5:16 AM Steve Holden  wrote:
>
>> On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset 
>> wrote:
>>
>>> [sorry for the duplicate, meant to reply-all]
>>>
>>> Thank you for this approach, I find it really helpful to put the
>>> conversation in these terms (semantics and guiding principles).
>>>
>>> It does help to rationalise discussion ;-)
>>
>>> [...]
>>> 4. "Objects should be able determine which patterns they match."
>>> This is something that you and I, and most of the authors of 622 agree
>>> on. What we found out when discussing this is that we didn't have clear
>>> what and how to open that customization. Some customization options added a
>>> lot of complexity at the cost of performance, some others were very simple
>>> but it wasn't clear that they would be actually useful, or extensible in
>>> the future. This has a lot to do with this being a somewhat new paradigm in
>>> Python, and our lack of knowledge on what the user community may do with it
>>> beyond what we imagined. So the decision was "pattern matching as it is
>>> presented without extensibility is useful, let's get this in, and once we
>>> see how it is used in the wild we'll understand better what kind of
>>> extensibility is valuable". For a crude analogy, imagine trying to get the
>>> descriptor protocol right when the basic python object model was being
>>> implemented. These things happened as different times as the use of the
>>> language evolved, and my opinion is that customization of the match
>>> protocol must follow a similar path.
>>>
>>>
>> I haven't so far understood whether the change proposed is intended to
>> start out in __future__. Given the preliminary nature of this development,
>> it would seem wise to retain the option to withdraw it or modify it
>> radically before production code depends on it.
>>
>
> The current proposal is not for it to be put behind a __future__ statement
> as it doesn't conflict with or break any pre-existing source code.
>

Ok, thanks for the clarification.

All I will say is just because we aren't *required* to implement it in
__future__ that doesn't mean we can't or shouldn't. Everything should be
done to underline the tentative nature of these developments, or we risk
the potential of functionality frozen because "we're already using it in
production."

The discussion to date suggests that such a breathing space would be
useful.
___
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/TUO5S5UZJ3SLNCM2DNCEJ5KTGYNDCAFD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Why does "except Ex as x" not restore the previous value of x?

[Steve Holden]

On Wed, Nov 18, 2020 at 7:45 PM Brett Cannon  wrote:

>
>
> On Tue, Nov 17, 2020 at 10:16 PM Greg Ewing 
> wrote:
>
>> On 18/11/20 4:36 pm, Larry Hastings wrote:
>> >
>> > But,
>> > the thinking went, you'd never want to examine the last value from a
>> > list generator, so it was more convenient if it behaved as if it had
>> its
>> > own scope.
>>
>> List comprehensions used to leak, but apparently that was considered
>> surprising by enough people that it was changed.
>>
>> Generator expressions are a bit different -- the only sane way to
>> implement them was to make the body implicitly a separate function,
>> and non-leaking behaviour naturally fell out of that. Making them
>> leak would have taken extra work just to get something that nobody
>> really had a good use case for.
>>
>> The desire to make list comprehensions and generator expressions
>> behave consistently may have contributed to the decision to change
>> list comprehensions to be non-leaking.
>>
>
> It did if I remember correctly.
>
> For me, generator expressions are small functions like you say (see,
> people did get the equivalent of multi-line lambdas, just in a very
> specific format ), and all the comprehensions are just passing a
> generator expression to the appropriate constructor, e.g. list(), set(),
> and dict(). In that regard the scoping is consistent to me.
>
> -Brett
>
>
If match were to create a scope, would making names in that scope nonlocal
by default work? (Obvs we'd then need a local declaration, but given
global's long-standing presence in the language and the more recent
addition of nonlocal it seems like a fairly natural extension).
___
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/BL5BGPFOJ25FVPC7KI4QPEEHUIR5L2RC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The semantics of pattern matching for Python

[Steve Holden]

On Wed, Nov 18, 2020 at 7:04 PM Daniel Moisset  wrote:

> [sorry for the duplicate, meant to reply-all]
>
> Thank you for this approach, I find it really helpful to put the
> conversation in these terms (semantics and guiding principles).
>
> It does help to rationalise discussion ;-)

> [...]
> 4. "Objects should be able determine which patterns they match."
> This is something that you and I, and most of the authors of 622 agree on.
> What we found out when discussing this is that we didn't have clear what
> and how to open that customization. Some customization options added a lot
> of complexity at the cost of performance, some others were very simple but
> it wasn't clear that they would be actually useful, or extensible in the
> future. This has a lot to do with this being a somewhat new paradigm in
> Python, and our lack of knowledge on what the user community may do with it
> beyond what we imagined. So the decision was "pattern matching as it is
> presented without extensibility is useful, let's get this in, and once we
> see how it is used in the wild we'll understand better what kind of
> extensibility is valuable". For a crude analogy, imagine trying to get the
> descriptor protocol right when the basic python object model was being
> implemented. These things happened as different times as the use of the
> language evolved, and my opinion is that customization of the match
> protocol must follow a similar path.
>
>
I haven't so far understood whether the change proposed is intended to
start out in __future__. Given the preliminary nature of this development,
it would seem wise to retain the option to withdraw it or modify it
radically before production code depends on it.
___
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/EBFOBAFOJPMKDFEQGT7ZN46R6QVM5UH3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Steve Holden]

On Thu, Nov 12, 2020 at 8:49 PM Guido van Rossum  wrote:

> The correct place for the docs for __cause__ and __context__ is in the
> section in the library reference about exceptions. There's quite a bit
> about them there already. That's where the tutorial should link as well.
>
> And now I ask you to stop complaining (your "the PEPs are the worst" does
> not help your cause).
>
> On Thu, Nov 12, 2020 at 12:30 PM Riccardo Polignieri via Python-Dev <
> python-dev@python.org> wrote:
>
>> > There is value in having non-trivial coverage of the language.  When
>> people ask how
>> > __cause__ works, we can link to the tutorial.
>> [...]
>
>
A Google search here for

python tutorial __cause__

returns as its first hit https://docs.python.org/3/library/exceptions.html
(the very section to which it seems you refer). There is a terse but
adequate description of __cause there__. It seems unhelpful that the
permalink for __cause__ (
https://docs.python.org/3/library/traceback.html?highlight=__cause__#traceback.TracebackException.__cause__)
links back to itself, but that's the nature of the beast with nested
exceptions -- it's __cause__s and __context__s all the way down.

A search for __cause__ using the documentations search feature leads to the
same loop of links noted above. In either case, if the curious reader
follows the traceback_exception link (
https://docs.python.org/3/library/traceback.html?highlight=__cause__#traceback.TracebackException)
they are moved up five lines whereupon the context becomes more
obvious.Those who find it intimidating may be a little out of their
depth, as this is hardly beginner material.

The tutorial was not mentioned in the docs search and the third hit in
my Google search, linking to https://docs.python.org/3/tutorial/errors.html.
Somewhat ironically, __cause__ is not mentioned on that page.
___
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/FU5CQKXAZD5KK54KFOE26JM636MHFJYO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Who is target reader of tutorial?

[Steve Holden]

As I remember the webmaster@ discussions, Mats did go so far as to start a
re-write of the classes section, but it never got as far as a PR.

Kind regards,
Steve


On Fri, Nov 6, 2020 at 5:51 PM Guido van Rossum  wrote:

> Ouch, that's bad. It seems the class tutorial could use an overhaul.
>
> We might also cut a few areas where we go unnecessarily deep (e.g.
> position-only parameters).
>
> On Fri, Nov 6, 2020 at 9:31 AM Mats Wichmann  wrote:
>
>> On 11/6/20 9:07 AM, Marco Sulla wrote:
>> > I started to learn Python with the tutorial, and two things come into
>> my
>> > mind:
>> > 1. The class section seems quite difficult and intimidating for a
>> novel,
>> > while classes in Python are really more simple than in other OO
>> languages
>>
>> Indeed - we got some complaints about the class chapter at the
>> webmas...@python.org alias a while back. The introductory section
>> repeatedly mentions Modula-3 and Smalltalk, languages which more
>> recently minted programmers aren't very likely to be familiar with,
>> which makes it a bit of a daunting beginning - this is the one chapter
>> that could really use a bit of rework, IMO.
>>
>> ___
>> 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/B54VI2DN2AYUXJG4SWSW2BMU5OOCIGSX/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
> 
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/QRWFPASA6TKQCDSIOUBYU5OGHPFAUXW3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/BQ2PWXS4VOTQUU5T3EUCQVKUQC4XQTH7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Steve Holden]

On Wed, Oct 21, 2020 at 8:37 AM Paul Moore  wrote:

> On Wed, 21 Oct 2020 at 08:14, Christian Heimes 
> wrote:
> >
> > On 21/10/2020 00.14, Steven D'Aprano wrote:
> > > On Tue, Oct 20, 2020 at 06:04:37PM +0100, Paul Moore wrote:
> > >
> > >> What I don't see is where the money's coming from. It's fine to ask,
> > >> but will anyone come up with that sort of funding?
> > >
> > > I don't think Mark is asking for you or I to fund the exercise. He's
> > > asking for the PSF to fund it.
> >
> > No, he is not. Mark is asking the PSF to organize a fund raiser and keep
> > half the money.
>
> Right. I'd misinterpreted the fact that the PSF was to get half the
> money as meaning they weren't doing the fundraising. My
> misunderstanding, thanks for the clarification.
>
> Paul
>

In 2004 a single company paid me to organise the "Need for Speed" sprint,
held in Iceland. A lot was achieved, particularly in string searching and
the re module, though I can't honestly say how much impact it had on
"overall performance". The work we did with pybench that week definitely
moved Python benchmarking along some.

Sixteen years later, the PSF's income may be down due to external factors,
but its connectivity at a high level with Python users has improved
immeasurably. Need for Speed cost ~$300,000 in inflation-adjusted dollars.
If one relatively small trading house could fund at that level it seems
likely the PSF could fund this suggested a project quite separately from
its existing revenues as long as the development community was behind it
and prepared to help with materials for the "sell."
___
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/36A6PRABPZPI6OSNNC2ZACJVHNBT7DUD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Remove module's __version__ attributes in the stdlib

[Steve Holden]

Since some code clearly accesses __version__, would it make sense to equip
all stdlib modules with a __version__ property that returned the Python
version, suitably prefixed?

Kind regards,
Steve


On Fri, Oct 16, 2020 at 5:28 AM Karthikeyan  wrote:

> On Fri, Oct 16, 2020, 12:45 AM Serhiy Storchaka 
> wrote:
>
>> 14.10.20 20:56, Brett Cannon пише:
>> > I think if the project is not maintained externally and thus synced into
>> > the stdlib we can drop the attributes.
>>
>> I have found only one exception. decimal.__version__ refers to the
>> version of the external specification which was not changed since 2009.
>> I think it should be kept, although it might be better to use different
>> name for it (like "spec_version").
>>
>> I do not know about any current projects maintained externally and
>> synced into the stdlib. simplejson and ElementTree are too different now
>> from the stdlib versions. Some features flow in both directions, but
>> selectively on case by case basis, not as full sync. External argparse
>> is outdated now.
>>
> I guess zipp that is maintained externally has code adopted into
> zipfile.ZipPath regularly : https://github.com/jaraco/zipp
>
> __version__ was removed from mock and it broke a package in fedora. The PR
> has a discussion and also links to the bpo to remove __version__ from all
> of stdlib : https://github.com/python/cpython/pull/17977
>
> I am also in favor of removing since it causes confusion when the package
> is not maintained externally n synced into stdlib.
>
> Thanks
>
> ___
>> 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/MIEMWWC5W2WKV25WTARXACQOIUBUUSLS/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> 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/3NY5JIFUP5674Q3FR2DOMLXGBE6D4XJD/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/JZ4JVMYROUAONIZG2VQGKI6XCE4MJBDQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [python-committers] Resignation from Stefan Krah

[Steve Holden]

Full marks to the SC for transparency. That's a healthy sign that the
community acknowledges its disciplinary processes must also be open to
scrutiny, and rather better than dealing with matters in a Star Council.

Kind regards,
Steve


On Fri, Oct 9, 2020 at 12:10 AM Thomas Wouters  wrote:

>
> Stefan did indeed receive, and was notified of, a 1-year ban from core
> development. This action was based on advice from the Conduct WG and our
> own deliberations. We wanted to have a discussion with him before we made
> this public. The SC sent him an email with details (quoted below), three
> weeks ago, CC'ing the Conduct WG. We had a brief back-and-forth last week.
> Unfortunately (and without telling us), Stefan apparently declined to
> address the matter in the way we asked.
>
> For the record, the Steering Council followed the PEP 13 procedure for
> ejecting a core developer (
> https://www.python.org/dev/peps/pep-0013/#ejecting-core-team-members) and
> voted unanimously to eject Stefan, as we told Stefan we would do if he
> chose not to address the concerns we outlined below.
>
> Our original message to Stefan:
> """
> Dear Stefan,
>
> The Python Steering Council and the PSF Conduct Working Group have
> received reports of your ongoing behavior in the Python core developer
> community. The Steering Council agrees with the Conduct Working Group’s
> findings that this behavior is unacceptable. While we appreciate your
> valuable technical contributions to CPython, that does not exempt you from
> the expected standards of behavior and the Code of Conduct.
>
> Specifically, your behavior has displayed:
>
> * Disrespectful, hostile, and unwelcoming communication in tone and content
> * Harassment by needlessly adding people to issues
> * A disregard of the directions and authority of the release manager
>
> Some examples of the problematic behavior include:
>
> * https://bugs.python.org/issue36839#msg344544
> * https://bugs.python.org/issue40874#msg372616
> * https://bugs.python.org/issue40874#msg372917
> * https://bugs.python.org/issue40874#msg372922
> * https://bugs.python.org/issue39542#msg372983
>
> We are also aware that this is not new behavior. We know the PSF Conduct
> WG warned you on April 23, 2020 about your previous violations of the Code
> of Conduct.
>
> As such, we are taking the action of suspending your participation in
> Python's development for 12 months starting today. You will lose access to:
>
> * Python-committers
> * Python-dev
> * Python-ideas
> * Core-mentorship
> * bugs.python.org
> * discuss.python.org
> * The Python organization on GitHub
>
> Along with the 12-month suspension, you will need to meet additional
> conditions in good faith:
>
> * Please acknowledge that you have read and understand the Code of Conduct
> and promise to abide by it going forward
> * You write an apology to your fellow core developers for your actions
> which we will publish on your behalf when announcing your suspension
> * Acknowledge that future reinstatement will include a zero-tolerance
> conduct policy in regards to your future behavior
>
> We offer you 14 days from today to meet these conditions and submit them
> to the Steering Council via email.
>
> If you choose not to satisfy these conditions, the 12-month suspension
> will become a permanent ejection from the Python core developer community
> as per the procedures outlined in PEP 13.  You are then free to go through
> the Python core developer election process also as outlined in PEP 13,
> however the Steering Council will not consider approving any positive
> outcome of that vote until the 12-month suspension has elapsed.
>
> - The Python Steering Council
> """
>
> On behalf of the Steering Council,
> Thomas.
>
> On Wed, Oct 7, 2020 at 11:48 PM Antoine Pitrou  wrote:
>
>>
>> Hello,
>>
>> Apparently, Stefan Krah (core developer and author of the C _decimal
>> module) was silently banned or moderated from posting to python.org
>> mailing-lists.  He asked me to forward the following message:
>>
>>
>>
>> ==
>> Hello,
>>
>> Today I have left the Python organization.  It wasn't an easy decision,
>> after all there are so many amazing people here.
>>
>> My vision of how development should be handled differs from many people
>> who are currently active.  Other projects are more aligned with my
>> preferences, so I prefer to focus my energies elsewhere.
>>
>> Having a shared understanding of what constitutes politeness is
>> important and eliminates all sources of friction that sometimes result
>> in losing one's patience.
>>
>> All the best,
>>
>> Stefan Krah
>>
>> 
>>
>>
>> Best regards
>>
>> Antoine.
>> ___
>> python-committers mailing list -- python-committ...@python.org
>> To unsubscribe send an email to python-committers-le...@python.org

[Python-Dev] Re: Hygenic macros PEP.

[Steve Holden]

On Wed, Sep 16, 2020 at 3:53 PM Mark Shannon  wrote:

> [...]
>
> maybe!(a.b)
>
> which would translate to:
>
> $tmp = a; None if $tmp is None else ($tmp.b)
>
> This reminds me very much of PL/1's "compile-time  procedures," which
forty years ago were pretty much like PL/1 constructs with percent signs
sprinkled about. I didn't like those much, either ;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/INDHHUK5FXZ2MQFX6KMKIHDUPYYBMRGP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How to customize CPython to a minimal set

[Steve Holden]

Sadly micropython is not intended to support numerical libraries and other
such complex modules: the support for the Python standard library is pretty
much non-existent.

Kind regards,
Steve


On Wed, Jul 22, 2020 at 3:10 PM Huang, Yang  wrote:

> Thank you for all your comments.
>
> I cannot agree any more. I did try but there were so many dependencies.
> One change all change.
>
>
>
> Micropython is a choice. But not sure if numpy and sqlite3 can be
> supported well. And what’s the compatibility of the libs in Pypi.
>
>
>
>
>
> *From:* Guido van Rossum 
> *Sent:* Tuesday, July 21, 2020 10:57 PM
> *To:* Huang, Yang 
> *Cc:* python-dev@python.org
> *Subject:* Re: [Python-Dev] How to customize CPython to a minimal set
>
>
>
> I expect it will be unfeasible to strip CPython. If you disagree, try it.
> ;-)
>
>
>
> On Mon, Jul 20, 2020 at 22:35 Huang, Yang  wrote:
>
> Hi, Guido
>
>
>
> Yes. Micropyhton is also in consideration.
>
> But sqlite3 is the first usage. There should be some additional features
> like numpy, scipy... Not sure if micropython supports well?
>
>
>
> Or is there a feasible way to strip CPython ?
>
>
>
> Thanks.
>
>
>
> *From:* Guido van Rossum 
> *Sent:* Monday, July 20, 2020 10:45 PM
> *To:* Huang, Yang 
> *Cc:* python-dev@python.org
> *Subject:* Re: [Python-Dev] How to customize CPython to a minimal set
>
>
>
> Have you considered starting with micropython? It’s made for embedded
> systems and fully supports Python 3 syntax. Adding sqlite3 support to it
> will be less work than stripping all the I/O from CPython.
>
>
>
> —Guido
>
>
>
> On Mon, Jul 20, 2020 at 06:48 Huang, Yang  wrote:
>
>
> Hi, all
>
> There is a request to run python in a Linux-based embedded resource
> constrained system with sqlite3 support.
>
> So many features are not required, like posixmodule, signalmodule,
> hashtable ...
> But seems there are some dependencies among the
> Modules/Parser/Python/Objects/Programs...
>
> Is there a way to tailor CPython 3 to a minimal set with sqlite3 (the less
> syscalls the better) ?
> Is it possible to do that?
>
> Thank you.
> ___
> 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/ECPLKXQ42VNLHD5DP3RG57L3QTJ77FUT/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
>
> --Guido (mobile)
>
> --
>
> --Guido (mobile)
> ___
> 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/OMUGASSNBFJOT3W2ES4OIOQ4LOWMNHHG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/JZDVYFODJRDYOLQOSV3OHMCLE4LZK6I4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Steve Holden]

While I understand the point of view that says that match ... :
should encapsulate a sequence of indented suites, it seems to me that
match/case/case/.../else has a natural affinity with
try/except/except/.../finally/else, and nobody seems to think that the
excepts should be indented. Or the finally. And naturally the match/else
case are at the same indentation level, just as for/else, while/else and
try/finally. So why, exactly, should case be indented?

My apologies for being a Bear of Very Little Brain.


On Fri, Jul 10, 2020 at 12:09 PM Greg Ewing 
wrote:

> A thought about the indentation level of a speculated "else" clause...
>
> Some people have argued that "else" should be at the outer level,
> because that's the way it is in all the existing compound statements.
>
> However, in those statements, all the actual code belonging to the
> statement is indented to the same level:
>
>  if a:
>  
>  elif b:
>  
>  else:
>  
>
>  ^
>  |
>  Code all indented to this level
>
> But if we were to indent "else" to the same level as "match",
> the code under it would be at a different level from the rest.
>
>  match a:
>  case 1:
>  
>  case 2:
>  
>  else:
>  
>  ^   ^
>  |   |
>  Code indented to two different levels
>
> This doesn't seem right to me, because all of the cases, including
> the else, are on the same footing semantically, just as they are in
> an "if" statement.
>
> --
> Greg
> ___
> 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/ACH4QXCURTNEGKFQXEWET5NQ6DIABSQZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/QAN7C4LJFLJ5U6SWZRH6ANRMHYEWHMBG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

[Steve Holden]

Given that case will be a keyword, what's the case (pun unintentional) for
indenting the case clauses? What's wrong with 'case' and 'else' both
indented the same as match? Without the keyword there'd be a case for
indenting, but with it I don't see the necessity.

Kind regards,
Steve


On Fri, Jul 10, 2020 at 12:09 PM Greg Ewing 
wrote:

> A thought about the indentation level of a speculated "else" clause...
>
> Some people have argued that "else" should be at the outer level,
> because that's the way it is in all the existing compound statements.
>
> However, in those statements, all the actual code belonging to the
> statement is indented to the same level:
>
>  if a:
>  
>  elif b:
>  
>  else:
>  
>
>  ^
>  |
>  Code all indented to this level
>
> But if we were to indent "else" to the same level as "match",
> the code under it would be at a different level from the rest.
>
>  match a:
>  case 1:
>  
>  case 2:
>  
>  else:
>  
>  ^   ^
>  |   |
>  Code indented to two different levels
>
> This doesn't seem right to me, because all of the cases, including
> the else, are on the same footing semantically, just as they are in
> an "if" statement.
>
> --
> Greg
> ___
> 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/ACH4QXCURTNEGKFQXEWET5NQ6DIABSQZ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/KWOQBHH5HXPJIJQBQJVP2LQ7WJS7MWY4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Steve Holden]

Thank you. I understand the need for tolerance in such matters since
opinions vary, and merely wished to voice my own.

If I am being oversensitive it is perhaps because I have trodden in these
waters before, and have frequently been surprised by what other people find
distasteful or offensive. I do not necessarily require my opinions to be
thought reasonable, even by other reasonable people.

Kind regards,
Steve


On Mon, Jun 29, 2020 at 11:22 AM Nathaniel Smith  wrote:

> On Mon, Jun 29, 2020 at 2:31 AM Steve Holden  wrote:
> > The commit message used, however, reveals implementation details of the
> change which are irrelevant to the stated aim, which is making the
> documentation clear and concise. Use of such language is certainly
> regrettable, since it carries with it the implication that the Python
> developer community has somehow been wilfully sanctioning "relics of white
> supremacy" up until the change was made.
> >
> > There certainly is a place in tech for politics, as I have argued many
> times, and I am sure nobody wishes to continue to use language that might
> be offensive to readers. But I would suggest that the politics can safely
> be omitted from commit messages, since they can only properly be fully
> addressed in the conversation about the PR in advance. The wording of the
> commit message has the appearance (probably specious) of wanting to rub
> former misdeeds in the face of a largely innocent community, and that is
> the principal reason I found it distasteful and unnecessary.
>
> I just re-read the commit message, and I think you're being
> oversensitive and imagining things that aren't there. The actual
> commit message is written in a straightforward and factual way, and
> spends special effort on *absolving* the community of this kind of
> guilt. In particular, it emphasizes that the new text is accomplishing
> "the same goal", "maintaining the original intent", and describes the
> old text as a "relic", which is another way of saying that the
> problems were only there by historical accident, rather than by anyone
> intentionally keeping it there. Merely mentioning the concept of white
> supremacy is not an attack on you or the community [1].
>
> -n
>
> [1] https://en.wikipedia.org/wiki/White_defensiveness
>
> --
> Nathaniel J. Smith -- https://vorpus.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/2KNGOQKZOPJXMJWHZYMJ3DQZZVVHMLJ7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [Python-ideas] Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

[Steve Holden]

It's broadly accepted among professional writers that the language used
should be acceptable and comprehensible to the audience. This seems
uncontentious.

Posting a straightforward change representing a relaxation of standards
(which were not in any case being enforced) should also be uncontentious.

The commit message used, however, reveals implementation details of the
change which are irrelevant to the stated aim, which is making the
documentation clear and concise. Use of such language is certainly
regrettable, since it carries with it the implication that the Python
developer community has somehow been wilfully sanctioning "relics of white
supremacy" up until the change was made.

There certainly is a place in tech for politics, as I have argued many
times, and I am sure nobody wishes to continue to use language that might
be offensive to readers. But I would suggest that the politics can safely
be omitted from commit messages, since they can only properly be fully
addressed in the conversation about the PR in advance. The wording of the
commit message has the appearance (probably specious) of wanting to rub
former misdeeds in the face of a largely innocent community, and that is
the principal reason I found it distasteful and unnecessary.

Kind regards,
Steve

PS: I also think there is still room for the PEP to remind writers that
many readers of the documentation who graciously allow us to use English
without complaint are using it as their second or even third language, and
all writers should be sympathetic to their needs as a matter of
professional courtesy.



On Sun, Jun 28, 2020 at 10:18 PM Paul Sokolovsky  wrote:

> Hello,
>
> Shouldn't such feedback be also cross-posted to the python-dev mailing
> list? Also note the original pull request,
> https://github.com/python/peps/pull/1470, and differences of what was
> written in the pull request description and what went in the commit
> message.
>
>
> On Sun, 28 Jun 2020 22:10:14 +0200
> "Giampaolo Rodola'"  wrote:
>
> > From:
> >
> https://github.com/python/peps/commit/0c6427dcec1e98ca0bd46a876a7219ee4a9347f4
> >
> > > Instead of requiring that comments be written in Strunk & White
> > > Standard
> > English, require instead that English-language comments be clear and
> > easily understandable by other English speakers. This accomplishes
> > the same goal without upholding relics of white supremacy. Many
> > native English speakers do not use Standard English as their native
> > dialect, so requiring conformation to Standard English centers
> > whiteness in an inappropriate and unnecessary way, and can alienate
> > and put up barriers for people of color and those whose native
> > dialect of English is not Standard English. This change is a simple
> > way to correct that while maintaining the original intent of the
> > requirement.
> >
> > This has nothing to do with making the wording "clear and
> > understandable" (I agree on that). It's about, once again, bringing
> > race-based politics into Python, and spreading hate towards a
> > specific group of people: whites. Whether you're aware of it or not,
> > there is a term for this: it's racism. I want to remind everyone that
> > most of us here simply want to contribute code. We do it for free,
> > and don't want to be involved in "this", because frankly it's
> > disgusting. Doing something out of passion and for free, and at the
> > same time seeing these sorts of things happening on a regular basis,
> > looks and feels like an insult, and will only lead to people leaving
> > this place.
> >
> > On Fri, Jun 26, 2020 at 11:27 PM Keara Berlin 
> > wrote:
> >
> > > Hi all, this is a very small change, but I thought I would field it
> > > here to see if anyone has suggestions or ideas. Instead of
> > > requiring that comments be written in Strunk & White Standard
> > > English, PEP-8 should require instead that English-language
> > > comments be clear and easily understandable by other English
> > > speakers. This accomplishes the same goal without alienating or
> > > putting up barriers for people (especially people of color) whose
> > > native dialect of English is not Standard English. This change is a
> > > simple way to correct that while maintaining the original intent of
> > > the requirement. This change may even make the requirement more
> > > clear to people who are not familiar with Strunk & White, since for
> > > programmers, the main relevant aspect of that standard is "be clear
> > > and concise;" simply saying that instead of referencing Strunk &
> > > White may communicate this more effectively. Here is the current
> > > line in PEP-8: "When writing English, follow Strunk and White."
> > > I propose changing this line to "When writing English, ensure that
> > > your comments are clear and easily understandable to other English
> > > speakers." ___
> > > Python-ideas mailing list -- python-id...@python.org
> > > To unsubscribe send an 

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

[Steve Holden]

On Wed, May 20, 2020 at 7:11 PM Jim J. Jewett  wrote:

> David Mertz wrote:
>
> > Fwiw, I don't think it changes my order, but 'strict' is a better word
> than
> > 'equal' in all those places. I'd subtract 0.1 from each of those votes if
> > they used "equal".
>
> I would say that 'equal' is worse than 'strict'. but 'strict' is also
> wrong.
>
> Zipping to a potentially infinite sequence -- like a manual enumerate --
> isn't wrong.  It may be the less common case, but it isn't wrong.  Using
> 'strict' implies that there is something sloppy about the data in, for
> example, cases like Stephen J. Turnbull's lagged time series.
>
> Unfortunately, the best I can come up with is 'same_length', or possibly
> 'equal_len' or 'equal_length'.  While those are better semantically, they
> are also slightly too long or awkward.  I would personally still consider
> 'same_length' the least bad option.
>
> conformant? similar? parallel?
___
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/VWGV4RCZTZJYU6WP7UR4CEKCNVWEJNOG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 617: New PEG parser for CPython

[Steve Holden]

On Mon, Apr 6, 2020 at 8:04 PM Guido van Rossum  wrote:

> On Mon, Apr 6, 2020 at 11:36 AM Steven D'Aprano 
> wrote:
>
>>
>> Personally, I would not like to have to explain to newcomers why `match`
>> is a keyword but you can still use it as a function or variable, but not
>> other keywords like `raise`, `in`, `def` etc.
>>
>> match expression:
>> match = True
>>
>
> What kind of newcomers do you have that they even notice that, unless you
> were to draw attention to it? I'm serious -- from the kind of questions
> I've seen in user forums, most newcomers are having a hard enough time
> learning more fundamental concepts and abstractions than the precise rules
> for reserved words.
>

Absolutely. Beginners can simply be told they are keywords. If they then
come across them in other contexts, hopefully there'll be a sensible
documentation page that a web search for " keyword" would lead to
an explanation that

"Some Python keywords can only ever be used with that meaning. Others can
be used with other meanings where the context makes it clear that the
keyword interpretation does not apply. You are recommended not to use such
keywords as names in your own programs. The feature was implemented to make
porting existing code to future versions of Python simpler."

The tutorial should contain a similar passage.
___
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/S2URQJVKERGOTKGJM5ZQX3EOCA2KNNS2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

[Steve Holden]

On Wed, Mar 25, 2020 at 5:42 PM Dennis Sweeney 
wrote:

> I'm removing the tuple feature from this PEP. So now, if I understand
> correctly, I don't think there's disagreement about behavior, just about
> how that behavior should be summarized in Python code.
> [...]
> return (the original object unchanged, or a copy of the object,
> depending on implementation details,
> but always make a copy when working with subclasses)
>
> is well-summarized by
>
>return self[:]
>
> especially if followed by the text
>
> Note that ``self[:]`` might not actually make a copy -- if the affix
> is empty or not found, and if ``type(self) is str``, then these methods

may, but are not required to, make the optimization of returning
> ``self``.
> However, when called on instances of subclasses of ``str``, these
> methods should return base ``str`` objects, not ``self``.
>
> Perhaps:

Note that ``self[:]`` might not actually make a copy of ``self``.
If the affix is empty or not found, and if ``type(self)`` is immutable,
then these methods may, but are not required to, make the
optimization of returning ``self``. ...

[...]
>
___
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/UWIFAGIT6CKVYGWOCWHAUNFCVSS6TJ3X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How to respond to repeated bad ideas

[Steve Holden]

The webmaster list sends an auto-response to new posters. If something like
that could happen on python-dev too, as long as the advice was clear enough
the list could then simply ignore such requests, knowing that the
auto-responder had taken care of it. This could drive posters to
python-list or python-ideas. There's nothing to stop individual devs still
replying if the inquiry merits it ...

Kind regards,
Steve


On Mon, Mar 2, 2020 at 10:49 PM Bar Harel  wrote:

> What I usually do btw is just search on mailman. Perhaps we can guide
> people to search on mailman before suggesting an idea?
>
> On Tue, Mar 3, 2020 at 12:30 AM Bar Harel  wrote:
>
>> I wrote it and take full responsibility, did not mean to be
>> disrespectful. Afterall, it's not what any of us are here for.
>>
>> For repeated suggestions though, that were rejected once or more in the
>> past, what are the general guidelines of answering?
>> In this case, apart from the rejection reason, we wish to teach the
>> newbie how to check if an idea was already suggested, else his ideas would
>> just be rejected over and over again.
>>
>> Atm we don't have an index of ideas, apart from pep 3099, and I'm not
>> sure we can make one (can we?), so I do not see a way to prevent this from
>> happening.
>>
>> I bet that many ideas are repeated, we don't know it, and it therefore
>> causes a repeated discussion with time and effort going nowhere.
>>
>> Just to clarify, my aim by answering it this way was to reduce the
>> overall effort of both sides, and the attempt to reinvent the wheel. It's
>> much like how duplicate stackoverflow questions are closed.
>>
>> On Mon, Mar 2, 2020, 11:58 PM Guido van Rossum  wrote:
>>
>>> Somebody wrote, in response to a newbie's idea:
>>>
 This idea is proposed at least once a year. You're able to read past
 discussions on python-ideas for the full list of rejection reasons.

>>>
>>> This   needs to go. It's unfair to the newbie, and I bet that in most
>>> cases whoever posts this doesn't have the slightest idea on how to find the
>>> specific rejection reason for the idea to which they're responding. I agree
>>> that many bad ideas come up repeatedly. But unless the proposer is a
>>> regular harasser of one of the lists, a response like this is unhelpful.
>>> Even if an idea is bad, let's respond in a friendly way, so the OP actually
>>> learns something about how Python is designed, or how it works, or whatever
>>> is relevant to understanding why their idea won't fly.
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>> *Pronouns: he/him **(why is my pronoun here?)*
>>> 
>>> ___
>>> Python-Dev mailing list -- python-dev@python.org
>>> To unsubscribe send an email to python-dev-le...@python.org
>>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>>> Message archived at
>>> https://mail.python.org/archives/list/python-dev@python.org/message/EZMCYMLYJKOIUWXIHUHQTQ2776XZOZ3Z/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> ___
> 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/3YYFGF2CVYJXM6PHZETWQUJ22SOUYIKM/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/BHNA7CHWHCXGVAALKGLBAPODI3B33HR2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typo in Link

[Steve Holden]

Really webmas...@python.org would have been more appropriate, but I've
already copied that address on my direct reply to you. The python-dev list
is for discussions about the development of the language and its CPython
implementation.

Kind regards,
Steve


On Tue, Jan 28, 2020 at 7:20 PM Steve Holden  wrote:

> Hi Steve,
>
> I believe you will find that wiki.python.org redirects to
> wiki.python.org/moin/. While https://wiki.python.org/moin/SteveHolden
>  exists, https://wiki.python.org/SteveHolden does not. It would therefore
> appear the links should include the "/moin".
>
> Kind regards,
> Steve
>
>
> On Tue, Jan 28, 2020 at 3:38 PM onlinejudge95 
> wrote:
>
>> Hi team,
>>
>> First of all is it a right place to ask this question? If not i would
>> love to redirect and apologise for any inconvenience.
>>
>> While i was going through the wiki.python.org links, i saw that the urls(
>> https://wiki.python.org/moin) contains *moin*, is it expected?
>>
>> Thanks,
>> onlinejudge95
>>
>> ___
>> 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/Y54FPSVXYCU7KTSDS76ZSU72DESF4W3P/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
___
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/Z3YDGLXJIF7WRPAHLH2BCBTKRBQMM7FX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Requesting PR review on locale module

[Steve Holden]

I've verified this fix and changed the status to "commit review." I trust
that was the correct action.

Kind regards,
Steve Holden


On Thu, Jan 9, 2020 at 9:57 PM Cédric Krier via Python-Dev <
python-dev@python.org> wrote:

> Hi,
>
> Any chance to get this PR reviewed? It is blocking the resolution of
> https://bugs.tryton.org/issue8574
>
> Thanks
>
> On 2019-11-18 06:36, Stéphane Wirtel wrote:
> > Hi Cedric,
> >
> > It’s my fault, I am going to check your PR for this week. I am really
> sorry because I am busy with the preparation of my black belt in Karate and
> I have a training every day.
> >
> > Have a nice day,
> >
> > Stéphane
> >
> > > Le 17 nov. 2019 à 14:06, Tal Einat  a écrit :
> > >
> > > 
> > > Hi Cédric,
> > >
> > > Thanks for writing and sorry that you've experienced such a delay.
> Such occurrences are unfortunately rather common right now, though we're
> working on improving the situation.
> > >
> > > Stéphane Wirtel self-assigned that PR to himself a couple of months
> ago, but indeed hasn't followed it up after his requested changes were
> apparently addressed, despite a couple of "pings".
> > >
> > > The experts index[1] lists Marc-Andre Lemburg as the expert for the
> locale module, so perhaps he'd be interested in taking a look.
> > >
> > > I've CC-ed both Stéphane and Marc-Andre.
> > >
> > > [1] https://devguide.python.org/experts/
> > >
> > >> On Sun, Nov 17, 2019 at 2:06 PM Cédric Krier via Python-Dev <
> python-dev@python.org> wrote:
> > >> Hi,
> > >>
> > >> Few months ago, I submitted a PR [1] for the bpo [2] about
> locale.format
> > >> casting Decimal into float. Has someone some times to finish the
> review?
> > >> This change is blocking a bugfix on Tryton [3].
> > >>
> > >>
> > >> [1] https://github.com/python/cpython/pull/15275
> > >> [2] https://bugs.python.org/issue34311
> > >> [3] https://bugs.tryton.org/issue8574
> > >>
> > >>
> > >> Thanks,
> > >> --
> > >> Cédric Krier - B2CK SPRL
> > >> Email/Jabber: cedric.kr...@b2ck.com
> > >> Tel: +32 472 54 46 59
> > >> Website: http://www.b2ck.com/
> > >> ___
> > >> 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/UOGIZADIK3EOLGPDDA2C525R63DULSDG/
> > >> Code of Conduct: http://python.org/psf/codeofconduct/
>
> --
> Cédric Krier - B2CK SPRL
> Email/Jabber: cedric.kr...@b2ck.com
> Tel: +32 472 54 46 59
> Website: https://www.b2ck.com/
> ___
> 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/RFY3DCK47ALK6X6AYCZ3ET5O6P6US3NA/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/IL2BNPSAAWVEVOUP553X3P2BSYNNS7RF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Deprecating the "u" string literal prefix

[Steve Holden]

In which case, wouldn't "_" make a better literal prefix than "i"?

A better comparison might be between _"..." and f"...".

regards
Steve Holden


On Thu, Dec 5, 2019 at 5:37 AM Serhiy Storchaka  wrote:

> 04.12.19 16:02, Anders Munch пише:
> > Victor Stinner [mailto:vstin...@python.org] wrote:
> >> You may want to have a look at the deferred PEP 501 -- General purpose
> string interpolation:
> >> https://www.python.org/dev/peps/pep-0501/
> >
> > I'm struggling to see what i-strings would do for i18n that str.format
> doesn't do better.
>
> You would not need to repeat yourself.
>
>  _('{name} costs ${price:.2f}').format(name=name, price=price)
>
> vs
>
>  i'{name} costs ${price:.2f}'
>
> In addition, you need to translate the format for money (in some
> cultures you need not two digits after dot), and this is hard to do with
> str.format().
> ___
> 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/46VZ2Q6QNT444YM7MV66YV26IYNIQEQC/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/EDTCRQYUID356P7LDEMCNGUTAWO4PJFK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: small improvement idea for the CSV module

[Steve Holden]

If using a dictionary but still requiring attribute access, techniques such
as those used at https://github.com/holdenweb/hw can be used to simply
client code.

Kind regards,
Steve Holden


On Wed, Oct 30, 2019 at 11:15 AM Oz Tiram  wrote:

> Hi Steve,
>
> Thanks for your reply. While dataclass provide a cleaner API than DictRow
> (you can access `row.id` instead of `row["id"]`).
> However, dataclass still use the built in `__dict__` instead of
> `__slots__`.
>
> ```
> >>> @dataclass
> ... class InventoryItem:
> ... '''Class for keeping track of an item in inventory.'''
> ... name: str
> ... unit_price: float
> ... quantity_on_hand: int = 0
> ...
>
> >>> cf = InventoryItem("cornflakes", 0.99, 123)
> >>> cf
> InventoryItem(name='cornflakes', unit_price=0.99, quantity_on_hand=123)
> >>> cf.__dict__
> {'name': 'cornflakes', 'unit_price': 0.99, 'quantity_on_hand': 123}
> ```
>
> This means that the users reading large files won't see the suggested
> memory improvements.
>
> On the other hand, I'm willing to implement CSVReader classes for both.
> `DataClassCSVReader` does offer the
> benefit of row instances being mutable, `NamedTupleCSVReader` can be
> useful for people leaning toward functional
> programming style, where queries on CSV are only meant to find items or
> calculate quantities quickly without actually
> modifying the rows.
>
> I would be more than happy to know whether such PR would accept.
>
> Best regards
> Oz
>
>
> On Wed, Oct 30, 2019 at 8:39 AM Steve Holden  wrote:
>
>> Since 3.7 it may be that dataclasses offer a cleaner implementation of
>> the functionality you suggest. It shouldn't be too difficult to produce
>> code that uses dataclasses in 3.7+ but falls back to namedtuples when
>> necessary. You may wish to consider such an implementation strategy.
>>
>> Best wishes,
>> Steve Holden
>>
>>
>> On Tue, Oct 29, 2019 at 10:59 PM Oz Tiram  wrote:
>>
>>> Hello Python-devs,
>>>
>>> The csv module is probably heavily utilized by newcomers to Python,
>>> being a very popular data exchange format.
>>> Although, there are better tools for processing tabular data like
>>> SQLite, or Pandas, I suspect this is still a very popular
>>> module.
>>> There are many examples floating around how one can read and process CSV
>>> with the csv module.
>>> Quite a few tutorials show how to use namedtuple to gain memory saving
>>> and speed, over the DictReader.
>>> Python's own documentation has got a recipe in the collections modules[1]
>>> Hence, I was wondering why not go the extra step and add a new class to
>>> the CSV module NamedTupleReader?
>>> This class would do a good service for Python's users, especially
>>> newcomers who are still not aware of
>>> modules like the collections module.
>>> Would someone be willing to sponsor and review such a PR from me?
>>> As a smaller change, we could simply add a link from the CSV module's
>>> documentation to the recipe in the collections module.
>>> What do you think?
>>>
>>> Best regards
>>> Oz
>>>
>>> [1]:
>>> https://docs.python.org/3/library/collections.html?highlight=namedtuple%20csv#collections.namedtuple
>>>
>>> ---
>>> Imagine there's no countries
>>> it isn't hard to do
>>> Nothing to kill or die for
>>> And no religion too
>>> Imagine all the people
>>> Living life in peace
>>>
>>> ___
>>> 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/GRPUTYZOPWTTU532CKZOHCTRSHNFKE2M/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>
> --
>
>
> ---
>
> Imagine there's no countries
> it isn't hard to do
> Nothing to kill or die for
> And no religion too
> Imagine all the people
> Living life in peace
>
>
___
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/PU3IIPTWFEH4AJ3V2QPRKZHAGQOOKM4S/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: small improvement idea for the CSV module

[Steve Holden]

Since 3.7 it may be that dataclasses offer a cleaner implementation of the
functionality you suggest. It shouldn't be too difficult to produce code
that uses dataclasses in 3.7+ but falls back to namedtuples when necessary.
You may wish to consider such an implementation strategy.

Best wishes,
Steve Holden


On Tue, Oct 29, 2019 at 10:59 PM Oz Tiram  wrote:

> Hello Python-devs,
>
> The csv module is probably heavily utilized by newcomers to Python, being
> a very popular data exchange format.
> Although, there are better tools for processing tabular data like SQLite,
> or Pandas, I suspect this is still a very popular
> module.
> There are many examples floating around how one can read and process CSV
> with the csv module.
> Quite a few tutorials show how to use namedtuple to gain memory saving and
> speed, over the DictReader.
> Python's own documentation has got a recipe in the collections modules[1]
> Hence, I was wondering why not go the extra step and add a new class to
> the CSV module NamedTupleReader?
> This class would do a good service for Python's users, especially
> newcomers who are still not aware of
> modules like the collections module.
> Would someone be willing to sponsor and review such a PR from me?
> As a smaller change, we could simply add a link from the CSV module's
> documentation to the recipe in the collections module.
> What do you think?
>
> Best regards
> Oz
>
> [1]:
> https://docs.python.org/3/library/collections.html?highlight=namedtuple%20csv#collections.namedtuple
>
> ---
> Imagine there's no countries
> it isn't hard to do
> Nothing to kill or die for
> And no religion too
> Imagine all the people
> Living life in peace
>
> ___
> 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/GRPUTYZOPWTTU532CKZOHCTRSHNFKE2M/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/HGQG4AW2KBS4Q7QUCNTOTMRF3ZJSTRBM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The Python 2 death march

[Steve Holden]

It's not dead, it's just restin' after a particularly heavy release process.

regards
Steve Holden


On Mon, Sep 9, 2019 at 4:24 PM Rhodri James  wrote:

> On 09/09/2019 15:51, brian.sk...@gmail.com wrote:
> >  it's getting better?
>
> No it's not, it'll be stone dead in a moment.
>
> --
> Rhodri James *-* Kynesim Ltd
> ___
> 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/AUMYGJ444W53RFXK5LGUX46UGDBC4RCB/
>
___
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/JIMW7GYCMUVBCNJRORMHLCH2Z46SCKKS/

[Python-Dev] Re: [Webmaster] Python for Mac OS X Catalina

[Steve Holden]

Hi Ana,

This is something that the development team are best placed to answer, and
I'm sure that they'd be happy to know if there are bumps in the road coming
up with Catalina.

I am copying this reply to the core developer list to alert them. It would
be helpful if you could make as full a report as possible via
bugs.python.org. A reply-all to this email can be used to let the
development team know the report reference should you do so, and the bug
tracker is a better medium for such focused communication than the list.

I've moved the webmaster address to Bcc to relieve it of further traffic.
Good luck!

Steve Holden


On Fri, Aug 16, 2019 at 11:04 AM Ana Simion via Webmaster <
webmas...@python.org> wrote:

> Hello,
>
> Can you advise when you’re going to update Python to work with Mac OS X
> Catalina? I am running the beta of  Mac OS X Catalina but am unable to
> install the python software - I get a message advising the Developer hasn’t
> updated the software to work with the new OS yet. I’d be most grateful if
> you could get back to me as soon as possible.
>
> Many thanks
>
> Ana Simion
>
>
> ___
> Webmaster mailing list
> webmas...@python.org
> https://mail.python.org/mailman/listinfo/webmaster
>
___
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/CA3S22D63KY3K5ZOT2SDKBDEV5ICOOT4/

[Python-Dev] Re: What to do about invalid escape sequences

[Steve Holden]

On Mon, Aug 12, 2019 at 6:26 PM Terry Reedy  wrote:

> On 8/8/2019 5:31 AM, Dima Tisnek wrote:
> [...]
>
> To me, this one of the major problems with the half-baked default.
> People who want string literals left as is sometimes get away with
> omitting explicit mention of that fact, but sometimes don't.
>
> Note: when we added '\u' and '\U' escapes, we broke working code that
> had Windows paths like "C:\Users\Terry".  But we did it anyway.
>

It might be helpful it there were some sort of declaration that the
ultimate goal, despite the backwards incompatibility it would entail, is
removing this wart from the language.

While practicality does indeed often beat purity, I fell this particular
case may be the exception that proves the rule. Onwards to 4.0!
___
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/6AMS2N4O53RZ4BKTAB3GNPADZBGA4T7B/

[Python-Dev] Re: What to do about invalid escape sequences

[Steve Holden]

While not a total solution, it seems like it might be worthwhile forcing
flake8 or similar checks when uploading PyPI modules.

That would catch the illegal escape sequences where it really matters -
before they enter the ecosystem.

(general) fathead:pyxll-www sholden$ cat t.py
"Docstring with illegal \escape sequence"
(general) fathead:pyxll-www sholden$ flake8 t.py
t.py:1:25: W605 invalid escape sequence '\e'

while this won't mitigate the case for existing packages, it should reduce
the number of packages containing potentially erroneous string constants,
preparing the ground for the eventual introduction of the syntax error.

Steve Holden


On Sat, Aug 10, 2019 at 8:07 AM Serhiy Storchaka 
wrote:

> 10.08.19 02:04, Gregory P. Smith пише:
> > I've merged the PR reverting the behavior in 3.8 and am doing the same
> > in the master branch.
>
> I was going to rebase it to master and go in normal backporting process
> if we decide that DeprecationWarning should be in master. I waited the
> end of the discussion.
>
> > Recall the nightmare caused by md5.py and sha.py DeprecationWarning's in
> > 2.5...  this would be similar.
>
> It is very different because DeprecationWarning for md5.py and sha.py is
> emitted at runtime.
> ___
> 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/H5VXWS6UT2OZBTXG7HUERKAQQIQ4BYEA/
>
___
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/24ID6EF6ESG64B6VFXVRL4XNWP5I7ITW/

[Python-Dev] Re: What to do about invalid escape sequences

[Steve Holden]

This whole thread would be an excellent justification for following 3.9
with 4.0. It's as near as we ever want to get to a breaking change, and a
major version number would indicate the need to review. If increasing
strictness of escape code interpretation in string literals is the only
incompatibility there would surely be general delight.

Kind regards,
Steve Holden


On Wed, Aug 7, 2019 at 8:19 PM eryk sun  wrote:

> On 8/7/19, Steve Dower  wrote:
> >
> > * change the PyErr_SetExcFromWindowsErrWithFilenameObjects function to
> > append (or chain) an extra message when either of the filenames contains
> c
> > control characters (or change OSError to do it, or the default
> > sys.excepthook)
>
> On a related note for Windows, if the error is specifically
> ERROR_INVALID_NAME, we could extend this to look for and warn about
> the five reserved wildcard characters (asterisk, question mark, double
> quote, less than, greater than), pipe, and colon. It's only sometimes
> the case for colon because it's allowed in device names and used as
> the name and type delimiter for stream names.
>
> Kernel object names don't reserve wildcard characters, pipe, and
> colon. So I wouldn't want anything but the control-character warning
> if it's say ERROR_FILE_NOT_FOUND. An example would be
> SharedMemory(name='Global\test'), or a similar error for registry key
> and value names such as OpenKey(hkey, 'spam\test'), that is if winreg
> were updated to include the name in the exception. Note that forward
> slash is just a name character in these cases, not a path separator,
> so we have to use backslash, even if just via replace('/', '\\').
> ___
> 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/UFMVFL4QDUXLZFBWVW4YLAKPHQ6LTPDK/
>
___
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/KM2IVRWN5QPLCFHJ5FUWZ6XB7DW2VONS/

[Python-Dev] Re: Comparing dict.values()

[Steve Holden]

On Thu, Jul 25, 2019 at 4:01 AM Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> I considered an alternative: return True if the underlying dicts were
> identical or equal, and raise an Exception otherwise.
> But I soon decided that this was a terrible idea: it could hide a bug by
> making faulty code work intermittently.
> Apologies for doubtless belabouring the blindingly obvious (but then
> again, if I don't mention this possibility, maybe someone even more
> idiotic than me will suggest it ).
>
>
Whatever made you think I'd do that?
___
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/F6EPXBDDOJX6PKNRMGESBG3EMJ63VNBV/

[Python-Dev] Re: What is a public API?

[Steve Holden]

PEP 8 would concur, whatever the current preferred style was. Under "Naming
Conventions":

"""New modules and packages (including third party frameworks) should be
written to these standards, but where an existing library has a different
style, internal consistency is preferred."""

The requirement for internal consistency (essential for readability in code
of any size) alone justifies Raymond's wish to update it.


On Wed, Jul 17, 2019 at 1:32 AM Brett Cannon  wrote:

> Raymond Hettinger wrote:
> > > On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka storch...@gmail.com...
> wrote:
> > > Could we strictly define what is considered a public module interface
> in Python?
> > > The RealDefinition™ is that whatever we include in the docs is public,
> otherwise
> > not.
> > Beyond that, there is a question of how users can deduce what is public
> when they run
> > "import somemodule; print(dir(some module))".
> > In some modules, we've been careful to use both all and to use an
> > underscore prefix to indicate private variables and helper functions
> (collections and
> > random for example).  IMO, when a module has shown that care, future
> maintainers should
> > stick with that practice.
> > The calendar module is an example of where that care was taken for many
> years and then
> > a recent patch went against that practice.
>
> I agree with Raymond that if the calendar module was following the leading
> underscore practice (which we should probably encourage all new modules to
> follow for consistency going forward) then I think the module should be
> updated to keep the practice going.
>
> -Brett
> ___
> 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/WRREKS5LYMB5VYFON7RWGDKZW4KTYMIE/
>
___
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/6MZ62L2CIY72NRMHHGBLTD7X6MYMUDU4/

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

[Steve Holden]

[python-dev -> Bcc]

There are questions to answer, but they are mostly of a pretty mundane
kind. Technical issues are deflected by the auto-response, which contains
many pointers to sources of possible assistance, and so can usually be
disregarded or followed up with a simple response underlining the need to
seek assistance elsewhere. We see remarkably little spam, so moderating the
list isn't an issue and I've been doing that unaided for over a year
without noticing.

Kind regards,
Steve Holden


On Mon, Jul 8, 2019 at 11:56 PM Ethan Furman  wrote:

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

[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: strip behavior provides inconsistent results with certain strings

[Steve Holden]

On Tue, Jul 2, 2019 at 4:24 PM  wrote:

> It seems to me that the desired behavior here is closest to
> 'str.replace()' out of all the options discussed, just with the constraint
> of being limited to either the start or the end of the string. (Thus the
> .lreplace() and .rreplace() option suggested by Glenn.)
>
> The minimal change (which actually also is pretty general?) I think would
> be to add 'only_start' and 'only_end' keyword arguments to str.replace(),
> both defaulting to False. If, e.g., 'only_start' is passed True, each
> repetition of 'old' at the start of 's' is replaced by 'new', with the
> number of replacements limited by the existing optional 'count'. Similar
> behavior for 'only_end'=True.  Probably best to raise a ValueError(?) if
> both 'only_start'=True and 'only_end'=True?
>
> Taking swapping a file extension as an example of a particular
> transformation of interest, it would be achieved with something like
> s.replace(".htm", ".html", only_end=True).
>
> -Brian


Just to add my own touch of colour to the bike shed, I'd suggest that more
naturally-usable names for those arguments, should they be added, would be
at_start and at_end.

regards
 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/IVIUHDKO7WWORNFNUQDGDVVH2LYUKLXI/

[Python-Dev] Re: PEP 581 has been updated with "Downsides of GitHub" section

[Steve Holden]

Excellent thought.

On Fri, Jun 28, 2019 at 6:49 PM Ned Deily  wrote:

>
> On Jun 28, 2019, at 12:56, Mariatta  wrote:
> > Some of the items brought up during the language summit:
> > [...]
> > - we should be updating devguide ahead of the actual migration, so core
> developers and release managers have time to review and learn the new
> workflow. (suggested by Ned Deily)
>
> Actually, my suggestion was (and remains :) ) that a modified devguide
> branch should be created *first* as part of the migration design process,
> not later during implementation.  It needs to happen anyway but it would be
> much more effective, I think, to have it available up front to help catch
> any holes during the design and review.
>
> P.S. Thanks for doing this, Marietta!
>
> --
>   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/JPWPWUUYDRWNWALTVT4VIT4L6WMBNIRJ/
>
___
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/OQ4TWMKGDTZ5ILI7T66IWD3353BULV2Y/

[Python-Dev] Re: bug(?) - unexpected frames being skipped in extract_stack with closures

[Steve Holden]

Hi Ed,

Your note probably won't receive any other reply than this, because the
python-dev list is specifically for discussions about the development _of_,
rather than _with_, Python.

A more appropriate forum is probably the Python list (python-l...@python.org),
about which you can discover more details at Python-list Info Page
<https://mail.python.org/mailman/listinfo/python-list>.

Kind regards,
Steve Holden


On Thu, Jun 20, 2019 at 3:40 AM Ed Peschko  wrote:

> all,
>
> I'm writing a function meant to print out the context of a given
> function call when executed - for example:
>
> 1. def main():
> 2.
> 3. _st = stack_trace_closure("/path/to/log")
> 4. _st()
> 5. _st()
>
> would print out
>
> /path/to/file.py:4
> /path/to/file.py:5
>
> for each line when executed. Basic idea is to create a closure and
> associate that closure with a filename, then run that closure to print
> to the log without needing to give the filename over and over again.
>
> So far so good. But when I write this function, the frames given by
> getframeinfo or extract_stack skip the actual calling point of the
> function, instead giving back the *point where the closure was
> defined*.  (in the above example, it would print /path/to/file.py:3,
> /path/to/file.py:3 instead of incrementing to show 4 and 5).
>
> However, when I insert a pdb statement, it gives me the expected
> calling frame where _st is actually called.
>
> What's going on here? It looks an awful lot like a bug to me, like an
> extra frame is being optimized out of of the closure's stack
> prematurely.
>
> I've tried this in python2.7 and python3.3, both show this.
>
> thanks much for any info,
>
> Ed
>
> code follows:
> ---
>
> def stack_trace_closure(message, file_name=None, frame=3):
>
> fh = open(file_name, "w+")
>
> def _helper():
> return stack_trace(message, frame, fh)
>
> return _helper
>
> def stack_trace(message _frame, fh):
>
> _bt = traceback.extract_stack()
>
>  fh.write( "%s:%s - %s" % (_bt[_frame][0], _bt[_frame][1], _message))
> ___
> 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/4MKHPCRNAJACKIBMLILMQMUPTEVFD3HW/
>
___
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/RVIY2MGM5DP4R7U2PT4SV5SVCU7NAC7D/

[Python-Dev] Re: why is not 64-bit installer the default download link for Windows?

[Steve Holden]

On Tue, Jun 18, 2019 at 9:37 PM Steve Dower  wrote:

> On 18Jun2019 1025, Stephen J. Turnbull wrote:
> > Oleg Broytman writes:
> >   > On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com
> wrote:
> >
> >   > > Why don't we check the architecture using js and provide the
> >   > > appropriate version?
> >   >
> >   >Because the downloading computer is not necessary the installation
> >   > target.
> >
> > Sure, but (a) it's a good bet, and (b) somebody downloading to install
> > on a different machine is more likely to know what they're doing and
> > be conscious of issues of platform.
>
> Equally, someone more conscious of the issues will know to go and get
> the 64-bit version if they explicitly want it. But for practically
> everyone the 32-bit version will be just fine.
>
> There's no definitive answer to this, which means regardless of which
> decision we make we will have to continue to explain it over and over
> again. Right now, status quo and the lack of a volunteer to update the
> web site means that sticking with the 32-bit link is easier to explain
> than having to figure out why a particular machine was offered a
> particular download when it is not correct.
>

I just posted a webmaster reply about just such an inquiry. As one of the
people who get to do the explaining, it would be nice if we (not the devs)
could figure out some way of getting people to the download they want.

The lack of volunteers to update the web site content is disappointing, but
a fact of open source life. Personally I'd have thought that the PSF was
now spending enough on infrastructure that it might be able to afford
someone to maintain the content - especially those areas that most impact
the dev team. I imagine some assistance for release managers would also be
helpful.

Is it worth trying to make this happen?

regards
 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/I6ZRZKA6HOP4GYR5KQIYXM7A5L3ADCEC/

[Python-Dev] Re: PEP 594: update 1

[Steve Holden]

Perhaps if PEP 594 is seen to be moving ahead towards a slimmer Python (4?)
stdlib, it might encourage the development of a PEP to take over
maintenance of dead parrots. They might be recruited by the offer of some
way to at least publish a supported bundle via the same (python.org) site
that Python itself comes from. It would seem unfair to burden the PEP with
promising an afterlife. That would raise quality assurance issues, though.

If no such PEP emerges then the dead parrots will be buried and forgotten.
I see little reason why we (Python users) shouldn't trust the collective
python-dev wisdom on what ultimately belongs in stdlib, and heaven knows
these aren't simple discussions.


On Wed, Jun 5, 2019 at 6:56 PM Brett Cannon  wrote:

>
>
> On Tue, Jun 4, 2019 at 5:22 PM Victor Stinner  wrote:
>
>> So what is happening for this PEP since Python 3.8 beta1 has been
>> released? Is it too late for Python 3.8 or not?
>>
>> It seems like most people are confused by the intent of the PEP. IMHO
>> it would be better to rewrite "Remove packages from the stdlib" as
>> "Move some stdlib modules to PyPI". But that would require to rewrite
>> some parts of the PEP to explain how modules are moved, who become the
>> new maintainers, how to support modules both in stdlib (old Python
>> versions) and in PyPI (new Python), etc.
>>
>
> Correct, that is more than a title change but a shift in what the PEP's
> final result is. And the title as it currently stands as the modules would
> still be removed from the stdlib regardless of whether they end up on PyPI
> or not.
> Python-Dev mailing list -- python-dev(a)python.org
> To unsubscribe send an email to python-dev-leave(a)python.org
> Unsubscribe:
> https://mail.python.org/mailman3/lists/python-dev.python.org/
Python-Dev mailing list -- python-dev(a)python.org
To unsubscribe send an email to python-dev-leave(a)python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/

Re: [Python-Dev] PEP 558: Defined semantics for locals()

[Steve Holden]

I'm guessing the reason is to remove the overhead of keeping the dictionary
up to date during function execution when no Python code needs access to it.


On Mon, May 27, 2019 at 8:10 PM Richard Damon 
wrote:

> On 5/27/19 2:05 PM, Terry Reedy wrote:
> > On 5/27/2019 9:52 AM, Richard Damon wrote:
> >> On 5/27/19 9:12 AM, Terry Reedy wrote:
> >
> >>> I believe that the situation is or can be thought of as this: there is
> >>> exactly 1 function locals dict.
> >
> > per function invocation, or more generally, as Guido said, per stack
> > frame.  This part is obvious to me, but I should have been clearer.
> >
> >>>   Initially, it is empty and
> >>> inaccessible (unusable) from code.  Each locals() call updates the
> >>> dict to a current snapshot and returns it.
> >>>
> >> I had a similar concern, and one BIG issue with it being define this way
> >> is that you get a fundamental re-entrancy problem. If module a uses
> >> locals(), and then calls module b that uses locals(), module a has lost
> >> its usage.
> >
> > No. Sorry about being unclear.
> >
> Ok, if each function invocation gets its own dict, then the reentrancy
> issues go away.
>
> The fact that it isn't the 'active' dict, so you can't use it to modify
> the current state, but also you don't get a fresh copy each time (there
> is a single mutable dict that gets updated) seems to be an odd behavior
> and I can't see where it is an advantage to the user of the function, or
> where that makes it easier on the implementation. (But I could easy be
> missing something).
>
> --
> Richard Damon
>
> ___
> 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/steve%40holdenweb.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] PEP 594 - a proposal for unmaintained modules

[Steve Holden]

This whole vexing issue isn't going to be solved with any simple fix. A
tool that could identify upcoming trouble spots might or might not be
helpful.

Or perhaps it could be implemented as a __future__ feature, so that those
who choose not to use it during development see no change.

The primary effect of the import would be to put the import system into
"PEP-594 advice mode," where any imports of potentially troublesome modules
would at least give assiduous developers some idea of how much trouble to
expect by emitting warnings (unless explicitly silenced).

Even though only intended for development, it would inevitably make its way
into production code, so there would still be plenty of room for
bikeshedding about that ;-).


On Mon, May 27, 2019 at 4:07 PM Antoine Pitrou  wrote:

> On Mon, 27 May 2019 09:27:33 -0400
> David Mertz  wrote:
> > On Sun, May 26, 2019 at 11:17 PM Steven D'Aprano 
> > wrote:
> >
> > > > Nobody reads warnings.
> > >
> > > If nobody reads warnings, we should just remove the warnings module and
> > > be done with it. That should probably be a PEP.
> > >
> >
> > We'll have to start issuing a PendingDeprecationWarning when folk import
> > the `warnings` module. :-)
>
> And message users that they can `pip install warnings` to get the
> independently-maintained version ;-)
>
> 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/steve%40holdenweb.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] PEP 594: Removing dead batteries from the standard library

[Steve Holden]

What would _really_ help is getting the groups that maintain each dead
parrot to collaborate on a "Python Legacy release" that adds back anything
with a maintainer to the stdlib of the current Python version.

Even that will demand large resources, and if it's to be organised in a way
that doesn't involve lots of dev time then perhaps the PSF could be
involved? I presume the Steering Committee are the people to consider
directions like this.

Steve Holden


On Thu, May 23, 2019 at 7:03 PM Barry Warsaw  wrote:

> On May 20, 2019, at 13:15, Christian Heimes  wrote:
> >
> > here is the first version of my PEP 594 to deprecate and eventually
> remove modules from the standard library. The PEP started last year with
> talk during the Python Language Summit 2018,
> https://lwn.net/Articles/755229/.
> >
> > The PEP can be confirmed in two stages. I'm not planning any code
> changes for 3.8. Instead I only like to document a bunch of modules as
> deprecated. Active deprecation is planned for 3.9 and removal for 3.10. The
> long deprecation phase gives us 3 years to change our minds or handle edge
> cases, too.
>
> Hi Christian,
>
> First, I appreciate the work you’ve done on this, and the general
> sentiment.  But I do feel like this is a partial solution to a problem the
> Python distribution has had for a very long time.  Maybe it’s a good step
> forward, but in a sense it is incomplete and only chips away at the problem.
>
> We have two competing pressures, one to provide a rich standard library
> with lots of useful features that come right out of the box.  Let’s not
> underestimate the value that this has for our users, and the contribution
> such a stdlib has made to making Python as popular as it is.
>
> But it’s also true that lots of the stdlib don’t get the love they need to
> stay relevant, and a curated path to keeping only the most useful and
> modern libraries.  I wonder how much the long development cycle and
> relatively big overhead for contributing to stdlib maintenance causes a big
> part of our headaches with the stdlib.  Current stdlib development
> processes also incur burden for alternative implementations.
>
> We’ve had many ideas over the years, such as stripping the CPython repo
> stdlib to its bare minimum and providing some way of *distributing* a sumo
> tarball.  But none have made it far enough to be adopted.  I don’t have any
> new bright ideas for how to make this work, but I think finding a holistic
> approach to these competing pressures is in the best long term interest of
> Python.
>
> That all said, if PEP 594 can be viewed as part of the bigger picture,
> then maybe it’s a good idea.  Perhaps the approaches for maintaining such
> deprecated libraries can be used as an experiment for finding a more
> modern, useful, and vibrant approach to stdlib maintenance.
>
> 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/steve%40holdenweb.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] PEP 594: Removing dead batteries from the standard library

[Steve Holden]

It might also serve to identify those with an interest in maintaining the
non-core packages, which might even be given some special status on PyPI.


On Thu, May 23, 2019 at 9:01 AM Alex Walters 
wrote:

> I've watched the entire thread and its taken me a few days to put a finger
> on what bothers me about it.
>
> In my opinion, this shouldn't be a pep describing the list of modules that
> need to go as "dead batteries", but should be a process pep describing how
> dead batteries should be removed, and the individual modules should be
> given
> their own pep.  I think reactions to individual module peps will give a
> better indication of if it's a used module or not.
>
> > -Original Message-
> > From: Python-Dev  > list=sdamon@python.org> On Behalf Of Christian Heimes
> > Sent: Monday, May 20, 2019 4:15 PM
> > To: Python Dev 
> > Subject: [Python-Dev] PEP 594: Removing dead batteries from the standard
> > library
> >
> > Hi,
> >
> > here is the first version of my PEP 594 to deprecate and eventually
> remove
> > modules from the standard library. The PEP started last year with talk
> during
> > the Python Language Summit 2018, https://lwn.net/Articles/755229/.
> >
> > The PEP can be confirmed in two stages. I'm not planning any code changes
> > for 3.8. Instead I only like to document a bunch of modules as
> deprecated.
> > Active deprecation is planned for 3.9 and removal for 3.10. The long
> > deprecation phase gives us 3 years to change our minds or handle edge
> > cases, too.
> >
> > Regards,
> > Christian
> >
> >
> >
>
> 
> > PEP: 594
> > Title: Removing dead batteries from the standard library
> > Author: Christian Heimes 
> > Status: Active
> > Type: Process
> > Content-Type: text/x-rst
> > Created: 20-May-2019
> > Post-History:
> >
> >
> > Abstract
> > 
> >
> > This PEP proposed a list of standard library modules to be removed from
> the
> > standard library. The modules are mostly historic data formats and APIs
> that
> > have been superseded a long time ago, e.g. Mac OS 9 and Commodore.
> >
> >
> > Rationale
> > =
> >
> > Back in the early days of Python, the interpreter came with a large set
> of
> > useful modules. This was often refrained to as "batteries included"
> > philosophy and was one of the corner stones to Python's success story.
> > Users didn't have to figure out how to download and install separate
> > packages in order to write a simple web server or parse email.
> >
> > Times have changed. The introduction of the cheese shop (PyPI),
> setuptools,
> > and later pip, it became simple and straight forward to download and
> install
> > packages. Nowadays Python has a rich and vibrant ecosystem of third party
> > packages. It's pretty much standard to either install packages from PyPI
> or
> > use one of the many Python or Linux distributions.
> >
> > On the other hand, Python's standard library is piling up cruft,
> unnecessary
> > duplication of functionality, and dispensable features. This is
> undesirable
> > for several reasons.
> >
> > * Any additional module increases the maintenance cost for the Python
> core
> >   development team. The team has limited resources, reduced maintenance
> > cost
> >   frees development time for other improvements.
> > * Modules in the standard library are generally favored and seen as the
> >   de-facto solution for a problem. A majority of users only pick 3rd
> party
> >   modules to replace a stdlib module, when they have a compelling reason,
> > e.g.
> >   lxml instead of `xml`. The removal of an unmaintained stdlib module
> >   increases the chances of a community contributed module to become
> > widely
> >   used.
> > * A lean and mean standard library benefits platforms with limited
> resources
> >   like devices with just a few hundred kilobyte of storage (e.g. BBC
> >   Micro:bit). Python on mobile platforms like BeeWare or WebAssembly
> >   (e.g. pyodide) also benefit from reduced download size.
> >
> > The modules in the PEP have been selected for deprecation because their
> > removal is either least controversial or most beneficial. For example
> > least controversial are 30 years old multimedia formats like ``sunau``
> > audio format, which was used on SPARC and NeXT workstations in the late
> > 1980ties. The ``crypt`` module has fundamental flaws that are better
> solved
> > outside the standard library.
> >
> > This PEP also designates some modules as not scheduled for removal. Some
> > modules have been deprecated for several releases or seem unnecessary at
> > first glance. However it is beneficial to keep the modules in the
> standard
> > library, mostly for environments where installing a package from PyPI is
> not
> > an option. This can be cooperate environments or class rooms where
> > external
> > code is not permitted without legal approval.
> >
> > * The usage of FTP is declining, but some files are still provided over

Re: [Python-Dev] PEP 594: update 1

[Steve Holden]

Besides which, it would be lovely to have a major release that didn't
involve any pain at all for the majority of users!

Our erstwhile BDFL always eschewed two-digit version identifiers-  due to
the possibility for confusion about collating sequence, I beleive.. We
should honour his preferences by going from 3.9 to 4.0.


On Thu, May 23, 2019 at 5:49 PM Anders Munch  wrote:

> Fra: Paul Moore [mailto:p.f.mo...@gmail.com]:
> > > A major version change serves as a heads up that something is going on
> and you need to check the consequences before upgrading.
> > Python's backward compatibility policy allows breaking changes between
> versions X.Y and X.Y+1 (with a suitable deprecation period). This proposal
> is no different.
>
> Except perhaps in scale.  The same people that upgrade from 3.x to 3.x+1
> without giving it a second thought, just to be on the latest version, will
> hesitate to go from 3.x to 4.y, because the major version change is a hint
> that they should be more careful.  That means they're ready for it when
> they get the ModuleNotFoundError exception, instead of feeling ambushed.
>
> OK, it may be that this is not enough to warrant a 4.0 release, but I do
> think python-dev should get over its fear of major versions sometime.  And
> that transitioning to a leaner standard library with some things moved to
> PyPI would not be a bad program statement for a Python 4.0.
>
> regards, Anders
>
> ___
> 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/steve%40holdenweb.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] PEP 594: Removing dead batteries from the standard library

[Steve Holden]

Good point!

On Tue, May 21, 2019 at 2:01 PM Paul Moore  wrote:

> On Tue, 21 May 2019 at 13:50, Steve Holden  wrote:
> >
> > That seems entirely reasonable. I wonder if the larger community could
> somehow form an organization (the Dead Parrot SIG?) that would at least
> curate and monitor efforts to ensure their continued utility?
>
> I have no idea whether there is enough community support to make this
> work, but regardless, I strongly support a SIG by that name. It may
> actually be even *more* amusing if it doesn't have enough members to
> make it viable :-)
>
> 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] PEP 594: Removing dead batteries from the standard library

[Steve Holden]

That seems entirely reasonable. I wonder if the larger community could
somehow form an organization (the Dead Parrot SIG?) that would at least
curate and monitor efforts to ensure their continued utility?


On Tue, May 21, 2019 at 1:40 PM Christian Heimes 
wrote:

> On 21/05/2019 14.06, Anders Munch wrote:
> > Fra: Python-Dev [mailto:python-dev-bounces+ajm=flonidan...@python.org]
> På vegne af Christian Heimes
> >> * The removed modules will be available through PyPI.
> >
> > Will they?  That's not the impression I got from the PEP.
>
> It's all open source. It's up to the Python community to adopt packages
> and provide them on PyPI.
>
> Python core will not maintain and distribute the packages. I'll merely
> provide a repository with packages to help kick-starting the process.
>
> Christian
> ___
> 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/steve%40holdenweb.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] PEP 594: Removing dead batteries from the standard library

[Steve Holden]

It's covered in "Python in a Nutshell," Alex Martelli having been a
promoter of its ability simplify many utility programs for a long time.

Not that that's any guide as to what should be in 3.10, by which time we'll
be four minor releases out of date anyway.


On Tue, May 21, 2019 at 9:16 AM Christian Heimes 
wrote:

> On 21/05/2019 02.16, Inada Naoki wrote:
> > I use fileinput for several times per year.
> >
> > fileinput is handy tool to write single script file to analyze log files.
> >
> > * In such tools, I don't need real argument parser.
> > * Some log files are compressed and some are not.
> >   It seems argparse doesn't support transparent decompression.
> > * I don't want to use 3rd party library for such single script files.
>
> OK, let's keep it. I was under the impression that it's not used.
>
> Christian
> ___
> 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/steve%40holdenweb.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] Feature request: Change a Dependency Package Version During Package Initiation

[Steve Holden]

I suspect this discussion would be better moved to python-ideas, since it
seems clear there needs to be some work on determining the exact
requirements


On Sat, May 18, 2019 at 4:03 PM Dan Ryan  wrote:

> It probably makes the most sense to formally outline all of the behavioral
> changes, expectations, and constraints you are asking for as Brett said
> because dependency and package management are tricky and it's not clear (to
> me at least) what the request is, what problem is being encountered, and
> how it is proposed that it be resolved.
>
> First glance makes it sound a bit like the a prerequisite for this request
> would be allowing multiple versions of the same package to be installed in
> a given python environment to begin with, or else some runtime hacking of
> paths would be necessary.  I may be misunderstanding, but that's why a
> formal approach for something like this might make some sense
>
> Dan Ryan
> gh: @techalchemy // e: d...@danryan.co
>
> From: Q [mailto:qiang.f...@zoho.com.cn]
> Sent: Friday, May 17, 2019 10:32 PM
> To: Daniel Holth
> Cc: Brett Cannon; Python-Dev
> Subject: Re: [Python-Dev] Feature request: Change a Dependency Package
> Version During Package Initiation
>
> Sorry, there is an error in my last post. It's corrected as:
> The abaqus python distribution has libA 1.0, the external package to be
> installed is LibB, which requires libA2.0, and we don't want to change
> every import in LibB to be import /somewhere/libA2.0, because the source
> code may have not been provided.
>
>
>  在 星期六, 2019-05-18 10:26:04 Q  撰写 
>
> From the viewpoint of the package user, people don't want to change every
> import to "require a version at runtime". If "set up a python path in a
> wrapper script" is a better strategy, can you please give an example for
> the following use case:
> The abaqus python distribution has libA 1.0, the external package to be
> installed is LibB, which requires libA2.0, and we don't want to change
> every import in LibB to be import libA 1.0, because the source code may
> have not been provided.
> In emacs, you can always advice a command to change its behaviour, which
> makes it very user friendly, and that what all the following suggestion is
> about. I have no idea at all how it could be implemented though.
> https://github.com/mitsuhiko/multiversion/issues/1
> "The work around is to let a version to be set within a package and have
> that propagate to all modules in that package. For example in the root
> init.py if I set tonado version to be 2.2.1 then all modules in that
> package will use tornado 2.2.1 when I import tornado."
>
>  在 星期五, 2019-05-17 23:38:55 Daniel Holth  撰写 
>
>
>
> This sounds exactly like what people used to do with eggs. You could have
> multiple versions of a package on the path as eggs and then require a
> version at runtime. The approach has problems. Ruby also abandoned a
> strategy where random app code depends on package management code at
> runtime.
>
> One better strategy is to set up a python path in a wrapper script.
>
> On Fri, May 17, 2019, 11:27 Brett Cannon  wrote:
>
> Thanks for the idea but there are currently no plans to support such a
> feature. If you would like to see it then you will need to write a PEP with
> a proof-of-concept to demonstrate how you would expect such a feature to
> work.
>
> On Fri., May 17, 2019, 07:55 Q via Python-Dev, 
> wrote:
>
> A lot of the Python code we use in production are used directly as imports
> in other python
> distributions (such as the python comes with the finite element software
> Abaqus and MSC Marc), many
> packages (such as matplotlib, numpy) that may have varying versioned
> dependencies.
>
> I was wondering if this could be expanded to allow a version to be set
> within a package and have
> that propagate to all modules in that package. For example in the root
> init.py if I set
> multiversion(tornado, 2.2.1) then all modules in that package will use
> tornado 2.2.1 when I import
> tornado.
>
> See a relevant issue on github:
> https://github.com/mitsuhiko/multiversion/issues/1
>
> Thank you!
> Qiang
>
>
> ___
> 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/steve%40holdenweb.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] PEP 581 (Using GitHub issues for CPython) is accepted

[Steve Holden]

As a mere user I'd like to thank the developer team for biting this bullet.
Remembering the transition to Git I am sure that the further
democratisation (?) of the development process will similarly increase the
diversity and scope of the development effort.

It will indeed be a significant effort to effect this migration. While it's
inevitable this will involve significant dev time, perhaps there roles can
be identified specifically as to be filled by _other_ than core devs.


On Wed, May 15, 2019 at 2:43 AM Victor Stinner  wrote:

> Congrats Mariatta :-)
>
> Victor
>
> Le mer. 15 mai 2019 à 03:14, Barry Warsaw  a écrit :
> >
> > As the BDFL-Delegate for PEP 581, and with the unanimous backing of the
> rest of the Steering Council, I hereby Accept this PEP.
> >
> > We would like to thank Mariatta for championing PEP 581, and to all the
> contributors to the discussion, both pro and con.  We appreciate your
> candor and respect for your fellow developers.  The SC believes that this
> migration is in the best interest of the Python community, and we look
> forward to the elaboration of the detailed migration plan (PEP 588).
> >
> > We also extend our heartfelt thanks Berker, Ezio, and everyone who has
> helped develop and maintain Roundup and bugs.python.org over the years.
> bpo has been a critical component for Python development for a very long
> time, and we all greatly appreciate the time, effort, and devotion you have
> put into this resource.
> >
> > https://www.python.org/dev/peps/pep-0581/
> >
> > Onward we go!  The migration will be a large effort, with much planning,
> development, and testing, and we welcome volunteers who wish to help make
> it a reality.  I look forward to your contributions on PEP 588 and the
> actual work of migrating issues to GitHub.
> >
> > Cheers,
> > -Barry (BDFL-Delegate, and on behalf of the Python Steering Council)
> >
> > ___
> > 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/vstinner%40redhat.com
>
>
>
> --
> Night gathers, and now my watch begins. It shall not end until my death.
> ___
> 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/steve%40holdenweb.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] Easier debugging with f-strings

[Steve Holden]

What's not to like?


On Tue, May 7, 2019 at 2:31 AM Glenn Linderman 
wrote:

> On 5/6/2019 5:39 PM, Eric V. Smith wrote:
>
> Last fall Larry Hastings made a suggestion for adding a way to make
> so-called "print-based debugging" easier with f-strings. Basically the
> approach is that f-strings would be able to produce the text of the
> expression and the value of that expression, without repeating the
> expression in the f-sting. No more writing f'foo={foo}, bar={bar}'. foo and
> bar should each only be in there once each!
>
>
> My plan is to commit this change before 3.8b1. If anyone would like to
> discuss it at PyCon, I'll be around until about 10:30 am on Tuesday. I'll
> be in the CPython sprint room, and I'll be watching bpo, too.
>
>
> Yes, I'd like this yesterday, please :)  Thanks!
> ___
> 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/steve%40holdenweb.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] Please merge : bpo-34848

[Steve Holden]

Looks like the failure is due to absence of a News entry. Maybe add a "skip
news" label if this doesn't need to be documented?

Kind regards.
Steve Holden


On Fri, May 3, 2019 at 9:48 AM Srinivas Reddy Thatiparthy <
thatiparthysreeni...@gmail.com> wrote:

> Hi,
>The PR - https://github.com/python/cpython/pull/9877  has been
> approved by Raymond long ago.  Please merge or comment if not mergeable.
>
> Best Regards,
> Srinivas Reddy Thatipathy
> 7768044110.
>
> ___
> 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/steve%40holdenweb.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] Removing PendingDeprecationWarning

[Steve Holden]

On Fri, Mar 22, 2019 at 8:43 AM Victor Stinner  wrote:

> Le ven. 22 mars 2019 à 09:16, Inada Naoki  a
> écrit :
> > > > We have `socket.error` for long time.
> > >
> > > And it's perfectly fine, no?
> > >
> >
> > Yes.  Waiting 10+ years to remove aliases is fine.
>
> [...]

>
> Right now, the maintenance cost is close to zero, whereas removing the
> alias would annoy a lot of people who will suddenly no longer be able
> to use their legacy code (written for Python 2 long time ago, but only
> ported to Python 3 recently). Getting a hard AttributeError exception
> is different than getting a silent DeprecationWarning :-)
>

Quite. Why expend the effort on a development that will cause unnecessary
pain?

Generally speaking, end-users will live their lives in blissful ignorance
of [Pending]DeprecationWarning and should be allowed to do so. When a
developer wants to migrate them to more recent versions of Python there's a
chance that warnings will be enabled and examined, but it's by no means
certain.

I suspect the real value of the warnings is so that the dev team can shrug
their shoulders when someone complains a feature has gone missing after ten
years in deprecated status. This is the price of having them normally
silent, which is certainly worth any trouble it causes by refusing to
hassle innocent non-developers with warnings they can do nothing about.
___
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] Is XML serialization output guaranteed to be bytewise identical forever?

[Steve Holden]

On Thu, Mar 21, 2019 at 11:33 AM Antoine Pitrou  wrote:

> [...]
>
> Most users and applications should /never/ care about the order of XML
> attributes.
>
> Regards
>
> Antoine
>

Especially as the standards specifically say that ordering has no semantic
impact.

Byte-by-byte comparison of XML is almost always inappropriate.
___
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] PEPs from non-core devs now need a sponsor

[Steve Holden]

On Tue, Mar 5, 2019 at 9:04 PM Steve Dower  wrote:

> On 05Mar2019 1245, Chris Angelico wrote:
> > How much effort does it take to sponsor a PEP? I'm not a core dev, but
> > I can help someone with the work of writing and publishing. So if, in
> > that hypothetical situation, some (very busy) core dev were willing to
> > say "yeah, go ahead, put my name on it", would that be sufficient? If
> > so, it shouldn't be a problem to require this - any proposal with
> > enough support to be worth PEPing should have at least one person
> > who's willing to have his/her name in the headers.
>
> For the record, now that he's joined the conversation, Chris is who I
> had in mind when I invented the term "PEP triager" in my email :)
>
> If we had a way of appointing people who we trust to be non-core dev
> sponsors of PEPs, I'd nominate him. Though I suspect he's well known
> enough to the council that they'd accept his support of a PEP as
> sufficient to consider it from someone who's otherwise completely
> unknown. There are always grey areas in any policy.
>

If core devs trust someone enough to let them act as a PEP sponsor, they
probably know at least one core dev well enough to get them to add their
name as sponsor on the condition that they are only responsiible for
ensuring their "proxy" (?) responds adequately and in a sufficiently timely
manner.

I don't have a great deal to add to most conversations here, but I would
urge all concerned to consider Brett's point, from my own now distant
experience as a PSF chair. If I may paraphrase him, it's easier to change
the rules when someone wants or needs to do something outside their current
scope than it is to devise bullet-proof rules. It was only after I learned
this lesson that much of the constitutional lawyering in the PSF was
(gradually) replaced by useful mission-directed volunteer-led activity.

Please don't concern yourselves too much about process, but instead focus
on the desired results. If lawyering is needed, delegate it to the PSF! I'd
rather have you pushing Python forward ;-).

Finally, thanks again to everyone who contributes, particularly for
managing to hide a great deal of Python's modern-day complexity from those
who neither want nor need to know about it. Ultimately I think that is
perhaps the biggest factor fuelling the language's continued growth.

Kind regards
Steve Holden
___
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] datetime.timedelta total_microseconds

[Steve Holden]

We should also consider that before long datetimes are frequently stored to
nanosecond resolution (two fields where this is significant are finance and
physics, and the latter would probably appreciate femtosedonds as well). So
maybe an external library that layers on top of datetime might be
preferable?

Kind regards
Steve Holden


On Wed, Feb 27, 2019 at 3:13 PM Paul Ganssle  wrote:

>
> On 2/26/19 7:03 PM, Chris Barker via Python-Dev wrote:
>
> This thread petered out, seemingly with a consensus that we should update
> the docs -- is anyone doing that?
>
> I don't think anyone is, I've filed a BPO bug for it:
> https://bugs.python.org/issue3613
>
>
> -- I am a physical scientist, I work with unitted quantities all the time
> (both in code and in other contexts). It never dawned on me to use this
> approach to convert to seconds or milliseconds, or ... Granted, I still
> rely on python2 for a fair bit of my work, but still, I had to scratch my
> head when it was proposed on this thread.
>
> As another data point, I also have a background in the physical sciences,
> and I actually do find it quite intuitive. The first time I saw this idiom
> I took it to heart immediately and only stopped using it because many of
> the libraries I maintain still support Python 2.
>
> It seemed pretty obvious that I had a `timedelta` object that represents
> times, and dividing it by a base value would give me the number of times
> the "unit" timedelta fits into the "value" timedelta. Seeing the code
> `timedelta(days=7) / timedelta(days=1)`, I think most people could
> confidently say that that should return 7, there's really no ambiguity
> about it.
>
>
> -- There are a number of physical unit libraries in Python, and as far as
> I know, none of them let you do this to create a unitless value in a
> particular unit. "pint" for example:
>
> https://pint.readthedocs.io/en/latest/
>
> ...
>
> And you can reduce it to a dimensionless object:
>
> In [57]: unitless.to_reduced_units()
>
> Out[57]: 172800.0 
>
> I think the analogy with pint's unit-handling behavior is not completely
> appropriate, because `timedelta` values are not in *specific* units at
> all, they are just in abstract duration units. It makes sense to consider
> "seconds / day" as a specific dimensionless unit in the same sense that
> "percent" and "ppb" make sense as specific dimensionless units, and so that
> would be the natural behavior I would expect for unit-handling code.
>
> For timedelta, we don't have it as a value in specific units, so it's not
> clear what the "ratio unit" would be. What we're looking at with timedelta
> division is really more "how many s are there in this duration".
>
>
> So no -- dividing a datetime by another datetime with the value you want
> is not intuitive: not to a physical scientist, not to a user of other
> physical quantities libraries -- is it intuitive to anyone other than
> someone that was involved in python datetime development??
>
>
> Just to clarify, I am involved in Python datetime development now, but I
> have only been involved in Python OSS for the last 4-5 years. I remember
> finding it intuitive when I (likely working as a physicist at the time)
> first saw it used.
>
> Discoverable:
> ==
>
> I agree that it is not discoverable (which is unfortunate), but you could
> say the same thing of *all* operators. There's no tab-completion that
> will tell you that `3.4 / 1` is a valid operation or that (3,) + (4,) will
> work, but we don't generally recommend adding methods for those things.
>
> I do think the discoverability is hindered by the existence of the
> total_seconds method, because the fact that total_seconds exists makes you
> think that it is the correct way to get the number of seconds that a
> timedelta represents, and that you should be looking for other analogous
> methods as the "correct" way to do this, when in fact we have a simpler,
> less ambiguous (for example, it's not obvious whether the methods would
> truncate or not, whereas __truediv__ and __floordiv__ gives the division
> operation pretty clear semantics) and more general way to do things.
>
> I think it's too late to *remove* `total_seconds()`, but I don't think we
> should be compounding the problem by bloating the API with a bunch of other
> methods, per my earlier arguments.
> ___
> 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/steve%40holdenweb.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] Compile-time resolution of packages [Was: Another update for PEP 394...]

[Steve Holden]

While these are interesting ideas, wouldn't it be better to leave this kind
of packaging to snap and similar utilities that bundle the language support
and libraries to allow simple isolated installation.

Kind regards
Steve Holden


On Tue, Feb 26, 2019 at 10:05 PM Neil Schemenauer 
wrote:

> On 2019-02-26, Gregory P. Smith wrote:
> > On Tue, Feb 26, 2019 at 9:55 AM Barry Warsaw  wrote:
> > For an OS distro provided interpreter, being able to restrict its use to
> > only OS distro provided software would be ideal (so ideal that people who
> > haven't learned the hard distro maintenance lessons may hate me for it).
>
> Interesting idea.  I remember when I was helping develop Debian
> packaging guides for Python software.   I had to fight with people
> to convince them that Debian packages should use
>
> #!/usr/bin/pythonX.Y
>
> rather than
>
> #!/usr/bin/env python
>
> The situtation is much better now but I still sometimes have
> packaged software fail because it picks up my version of
> /usr/local/bin/python.  I don't understand how people can believe
> grabbing /usr/local/bin/python is going to be a way to build a
> reliable system.
>
> > Such a restriction could be implemented within the interpreter itself.
> For
> > example: Say that only this set of fully qualified path whitelisted .py
> > files are allowed to invoke it, with no interactive, stdin, or command
> line
> > "-c" use allowed.
>
> I think this is related to an idea I was tinkering with on the
> weekend.  Why shouldn't we do more compile time linkage of Python
> packages?  At least, I think we give people the option to do it.
> Obviously you still need to also support run-time import search
> (interactive REPL, support __import__(unknown_at_compiletime)__).
>
> Here is the sketch of the idea (probably half-baked, as most of my
> ideas are):
>
> - add PYTHONPACKAGES envvar and -p options to 'python'
>
> - the argument for these options would be a colon separated list of
>   Python package archives (crates, bales, bundles?).  The -p option
>   could be a colon separated list or provided multiple times to
>   specify more packages.
>
> - the modules/packages contained in those archives become the
>   preferred bytecode code source when those names are imported.  We
>   look there first.  The crawling around behavor (dynamic import
>   based on sys.path) happens only if a module is not found and could
>   be turned off.
>
> - the linking of the modules could be computed when the code is
>   compiled and the package archive created, rather than when the
>   'import' statement gets executed.  This would provide a number of
>   advantages.  It would be faster.  Code analysis tools could
>   statically determine which modules imported code corresponds too.
>   E.g. if your code calls module.foo, assuming no monkey patching,
>   you know what code 'foo' actually is.
>
> - to get extra fancy, the package archives could be dynamic
>   link libraries containing "frozen modules" like this FB experiment:
>   https://github.com/python/cpython/pull/9320
>   That way, you avoid the unmarshal step and just execute the module
>   bytecode directly.  On startup, Python would dlopen all of the
>   package archives specified by PYTHONPACKAGES.  On init, it would
>   build an index of the package tree and it would have the memory
>   location for the code object for each module.
>
> That would seem like quite a useful thing.  For an application like
> Mercurial, they could build all the modules/packages required into a
> single package archive.  Or, there would be a small number of
> archives (one for standard Python library, one for everything else
> that Mercurial needs).
>
> Now that I write this, it sounds a lot like the debate between
> static linking and dynamic linking.  Golang does static linking and
> people seem to like the single executable distribution.
>
> Regards,
>
>   Neil
> ___
> 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/steve%40holdenweb.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

[Python-Dev] Fwd: How about updating OrderedDict in csv and configparser to regular dict?

[Steve Holden]

-- Forwarded message -
From: Steve Holden 
Date: Thu, Jan 31, 2019 at 11:05 AM
Subject: Re: [Python-Dev] How about updating OrderedDict in csv and
configparser to regular dict?
To: INADA Naoki 


And I see that such a patch is now merged. Thanks,  Raymond!

>
>>
___
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] How about updating OrderedDict in csv and configparser to regular dict?

[Steve Holden]

I submitted the patch to make the csv module use an OrderedDict in
DictReader. It doesn't, AFAIR, use anything but the ordering property of
ordered dict, so the reversion to a simple dict should be perfectly OK as
long as no consumers have started to make use of specific OrderedDict
properties.

regards
Steve Holden


On Thu, Jan 31, 2019 at 7:55 AM INADA Naoki  wrote:

> Hi,
>
> csv.DictReader uses OrderedDict by default, from Python 3.6.
> But it doesn't make sense anymore, like namedtuple._asdict().
> How about changing default dict type back to regular dict.
>
> Python is widely used for handling learge data.  So I think
> changing default dict type to OrderedDict was performance
> and memory usage regression in 3.6.
>
> Additionally, configparser uses OrderedDict by default from Python 3.6 too.
>
> I am not sure about `parser['section1'] == parser['section2']` is not used
> yet.
> But we broke it once in 3.6 by changing dict to OrderedDict.  Are there any
> issue report caused by this backward incompatibility?
>
> And I think performance and memory efficiency is not so important for
> configparser, unlike csv.
>
> I'm
>
> * +1 about changing csv.DictReader's default dict type
> * +0.5 about changing configparser's default dict type.
>
> How do you think?
>
> Regards,
> --
> INADA Naoki  
> ___
> 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/steve%40holdenweb.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] Lost sight

[Steve Holden]

Like everyone else, I am sorry to hear this news, and extend my sympathies.
It's marvellous that you are still able to work on Python at all, still.
Since you have to be careful not to do too much, you will just have to
choose your battles carefully. Thank you for your many contributions to
Python to date.

Kind regards
 Steve


On Sat, Jan 19, 2019 at 10:14 AM Serhiy Storchaka 
wrote:

> I have virtually completely lost the sight of my right eye (and the loss
> is quickly progresses) and the sight of my left eye is weak. That is why
> my activity as a core developer was decreased significantly at recent
> time. My apologies to those who are waiting for my review. I will do it
> slowly.
>
> ___
> 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/steve%40holdenweb.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] Inclusion of lz4 bindings in stdlib?

[Steve Holden]

We* should probably do more collectively to point people at
production-quality third-party modules, as I believe we currently do with
pipenv which, while not a part of the standard library, is still
recommended in the documentation as the preferred method of dependency
management. We should also be even more strident when a library module is a
basic version, not to be used for production purposes.

This inevitably means, however, that there will be lag in the
documentation, which generally speaking lags current best practices.

Steve Holden

* I am not a significant contributor to the code base.



On Fri, Nov 30, 2018 at 9:02 PM Glenn Linderman 
wrote:

> On 11/29/2018 2:10 PM, Andrew Svetlov wrote:
>
> Neither http.client nor http.server doesn't support compression
> (gzip/compress/deflate) at all.
> I doubt if we want to add this feature: for client better to use requests
> or, well, aiohttp.
> The same for servers: almost any production ready web server from PyPI
> supports compression.
>
> What production ready web servers exist on PyPi? Are there any that don't
> bring lots of baggage, their own enhanced way of doing things? The nice
> thing about the http.server is that it does things in a standard-conforming
> way, the bad thing about it is that it doesn't implement all the standards,
> and isn't maintained very well.
>
> From just reading PyPi, it is hard to discover whether a particular
> package is production-ready or not.
>
> I had used CherryPy for a while, but at the time it didn't support Python
> 3, and to use the same scripts behind CherryPy or Apache CGI (my deployment
> target, because that was what web hosts provided) became difficult for
> complex scripts so I reverted to http.server with a few private
> extensions (private because no one merged the bugs I reported some 3
> versions of Python-development-process ago; back then I submitted patches,
> but I haven't had time to keep up with the churn of technologies Pythondev
> has used since Python 3 came out, which is when I started using Python, and
> I'm sure the submitted patches have bit-rotted by now).
>
> When I google "python web server" the first hit is the doc page for
> http.server, the second is a wiki page that mentions CherryPy and a bunch
> of others, but the descriptions, while terse, mostly point out some special
> capabilities of the server, making it seem like you not only get a web
> server, but a philosophy. I just want a web server. The last one, Waitress,
> is the only one that doesn't seem to have a philosophy in its description.
>
> So it would be nice if http.server and http.client could get some basic
> improvements to be complete, or if the docs could point to a replacement
> that is a complete server, but without a philosophy or framework
> (bloatware) to have to learn and/or work around.
>
> Glenn
> ___
> 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/steve%40holdenweb.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] Python Language Governance Proposals

[Steve Holden]

As a piece of pure experiential data based on some years trying to herd the
PSF cats, if python-dev can find a way of running its activities without
votes needing to be taken I would really emphasise the benefits of the lack
of such administration.

If voting is required, please consider using the PSF to manage such
activity.

Following the debate with interest, but mostly lurking due to my usual
absence of skin in the game. Bonne chance!

regards
 Steve

Steve Holden

On Fri, Oct 26, 2018 at 6:17 PM, Brett Cannon  wrote:

>
>
> On Tue, 23 Oct 2018 at 13:20, Jeroen Demeyer  wrote:
>
>> What is the timeframe for the installation of the new governance? In
>> other words, when will it be possible to review PEPs?
>>
>
> PEP 8001 outlines the voting for the governance models which includes a
> planned schedule for that vote. After that it will vary depending on which
> governance model is chosen as some of them require electing people to
> positions while others don't. The overall goal is to have the whole ting
> resolved no later than probably March (but probably sooner than that).
> Basically this should not be a new thing come PyCon US in May.
>
> But since you're asking about wanting to "review PEPs", you can review
> them now. There hasn't been much change to them lately so they are pretty
> stable at this point.
>
> ___
> 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/
> steve%40holdenweb.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] Some PRs to merge?

[Steve Holden]

This is terrific work. We all know that the best way to encourage
contributors is to use their usable contributions. Thank you very much,
Stephane and Victor (again)!

Steve Holden

On Sat, Oct 20, 2018 at 10:32 AM, Stephane Wirtel 
wrote:

> On 10/20, Victor Stinner wrote:
>
>> Le ven. 19 oct. 2018 à 19:01, Stephane Wirtel  a
>> écrit :
>>
>>> total: 49 PRs
>>> is:open is:pr review:approved status:success label:"awaiting merge"
>>> -label:"DO-NOT-MERGE" label:""LA signed""
>>>
>>
>> I merged many PRs and closed a few (2 if I recall correctly). Your
>> query now counts 24 PRs.
>>
> Really nice for your job, I think the contributors will appreciate a
> lot.
>
>>
>> Victor
>>
>
> I would like to know if you are interested by this kind of reports. I
> can interact with the GraphQL api of GitHub and just provide the report
> via email to python-dev@python.org
>
> Have a nice day and thank you for your merges.
>
> Stéphane
>
> --
> Stéphane Wirtel - https://wirtel.be - @matrixise
> ___
> 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/steve%
> 40holdenweb.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] Questions about signal handling.

[Steve Holden]

I'm afraid Kristjan left CCP some time ago, and may not subscribe to this
list any more.

Steve Holden


On Tue, Sep 25, 2018 at 4:23 PM Antoine Pitrou  wrote:

> On Tue, 25 Sep 2018 09:09:26 -0600
> Eric Snow  wrote:
> > On Tue, Sep 25, 2018 at 1:45 AM Victor Stinner 
> wrote:
> > > Please don't rely on this ugly API. *By design*, Py_AddPendingCall()
> > > tries 100 times to acquire the lock: if it fails to acquire the lock,
> > > it does notthing... your callback is ignored...
> >
> > Yeah, there are issues with pending calls as implemented.
> > Furthermore, I'm not clear on why it was made a public API in the
> > first place.
>
> I don't know, but I think Eve Online used the API at some point (not
> sure they're still Python-based nowadays).  Perhaps Kristján may
> confirm if he's reading this.
>
> 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/steve%40holdenweb.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] [help] where to learn how to upgrade from 2.7 to 3

[Steve Holden]

You can find information about python-list at
https://mail.python.org/mailman/listinfo/python-list

regards
Steve Holden


On Tue, Sep 18, 2018 at 4:28 AM Ryan Gonzalez  wrote:

> Python-dev is for development *of* Python, not *in* Python! You want
> python-list instead.
>
> Also, make sure you include some full example code where the error occurs
> and what exactly is failing. Right now, it's hard for me to tell what
> exactly is going on...
>
> On Mon, Sep 17, 2018, 8:21 PM Avery Richards 
> wrote:
>
>> I am having so much fun learning python! I did not install the best
>> version into my mac at first. Now I can't find out how to upgrade, (pip is
>> awesome but not as conversational as I need it to be on the subject). I've
>> downloaded the packages from python.org, installed all sorts of stuff,
>>  I configured my text editor to recognize python3, resolving formatting
>> strings output, but now as I progress the
>>
>> [end = '  ']
>>
>> is not recognized. I have figured out a lot on my own, can you help me
>> upgrade to 3.6 once and for all? Again I consulted with pip and followed
>> faq websites (maybe a mistake there, idk).
>>
>> please please thank you!
>>
>> ~Avery
>> ___
>> 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/rymg19%40gmail.com
>>
> --
>
> Ryan (ライアン)
> Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> everyone else
> https://refi64.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/steve%40holdenweb.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] Why does the Contributor Agreement need my address?

[Steve Holden]

On Sun, Sep 9, 2018 at 5:24 AM Joseph C. Sible 
wrote:

> On Sat, Sep 8, 2018 at 11:47 PM Tim Peters  wrote:
> [...]
> > As to why they want an address, you'll have to ask a
> > lawyer!  There aren't any on this list.  So, if you really want to
> > pursue this, I suggest you direct the question instead to the Python
> > Software Foundation, which deals with the project's legalities:
> >
> > p...@python.org
>
> Thanks, this is useful information.
>
> 


There's a reason he was called "the timbot" ;-)
___
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] Refactor __get_builtin_constructor on hasklib.py

[Steve Holden]

Hi there,

Good to see you on python-dev. It's always good to see people getting
excited about helping with Python's development.

The changes you suggest are, unless I've missed something, purely cosmetic
- affecting readability only. This implies that you feel the code as it
stands isn't as readable as it could be. You must admit that "it looks
messy" is a matter of opinion, and alone isn't much of a justification for
making changes to a project that will reach its end of life in less than
eighteen months.

The code in the standard library is mostly fairly well-scrutinised, and as
PEP 8 reminds us, change made for purely stylistic reasons threatens to
introduce new bugs.

It's not obvious how much of the developer documentation you've seen, so it
might be worth mentioning https://devguide.python.org/ as a good starting
point for anyone wanting to contribute.

regards
 Steve

Steve Holden

On Tue, Aug 7, 2018 at 8:00 AM, 蔡銘峯  wrote:

> Hello everybody,
> I am Park Tsai. I want to refactor __get_builtin_constructor on hasklib.py
> of python 2.7 (https://github.com/python/cpython/blob/2.7/Lib/hashlib.
> py#L72).
> This is the first time that I try to refactor code of CPython on GitHub,
> so I am very excited.
>
> This is __get_builtin_constructor code on hasklib.py ,as follows.
>
> def __get_builtin_constructor(name):
> try:
> if name in ('SHA1', 'sha1'):
> import _sha
> return _sha.new
> elif name in ('MD5', 'md5'):
> import _md5
> return _md5.new
> elif name in ('SHA256', 'sha256', 'SHA224', 'sha224'):
> import _sha256
> bs = name[3:]
> if bs == '256':
> return _sha256.sha256
> elif bs == '224':
> return _sha256.sha224
> elif name in ('SHA512', 'sha512', 'SHA384', 'sha384'):
> import _sha512
> bs = name[3:]
> if bs == '512':
> return _sha512.sha512
> elif bs == '384':
> return _sha512.sha384
> except ImportError:
> pass  # no extension module, this hash is unsupported.
>
> raise ValueError('unsupported hash type ' + name)
>
>
> When I read this code, it looks messy, so I want to refactor it and make
> it become more clearly .
>
> Then, it will be like this
>
> def get_builtin_constructor(name):
> try:
> if name[:3] in ('SHA','sha'):
>if(name[3:]=='1'):
>import _sha
>return _sha.new
>
>elif (name[3:] == '224'):
>import _sha256
>return _sha256.sha224
>
>elif (name[3:] == '256'):
>import _sha256
>return _sha256.sha256
>
>elif (name[3:] == '384'):
>import _sha512
>return _sha512.sha384
>
>elif (name[3:] == '512'):
>import _sha512
>return _sha512.sha512
> elif name in ('MD5', 'md5'):
> import _md5
> return _md5.new
>
> except ImportError:
> pass # no extension module, this hash is unsupported.
>
> raise ValueError('unsupported hash type ' + name)
>
> I will be grateful for any help you can provide. I really appreciate any
> feedback you can offer!
>
> Best regards,
> Park Tsai !!
>
> ___
> 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/
> steve%40holdenweb.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] Benchmarks why we need PEP 576/579/580

[Steve Holden]

On Sun, Jul 22, 2018 at 12:14 AM, Guido van Rossum  wrote:

> ​[...]
> The new BDFL may be less demanding though. :=)
>

​I sincerely hope not.

regards
 Steve​
___
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] Fuzzing the Python standard library

[Steve Holden]

On Tue, Jul 17, 2018 at 11:44 PM, Paul G  wrote:

> In many languages numeric types can't hold arbitrarily large values, and I
> for one hadn't really previously recognized that if you read in a numeric
> value with an exponent that it would be represented *exactly* in memory
> (and thus one object with a very compact representation can take up huge
> amounts of memory). It's also not *inconceivable* that under the hood
> Python would represent fractions.Fraction("1.64E664644") "lazily" in
> some fashion so that it did not consume all the memory on disk.
>
> ​Sooner or later you are going to need the digits of the number to perform
a computation. Exactly when would you propose the deferred evaluation
should take place?

There are already occasional inquiries about the effects of creation of
such large numbers and their unexpected effects, so they aren't completely
unknown. At the same time, this isn't exactly a mainstream "bug", as
evidenced by the fact that such issues
​

​are relatively rare.
​

> It seems to me that "Hey by the way the size of this thing is unbounded
> and because of exponents small strings can expand to huge objects" is a
> good tip.
>
> ​Not an unreasonable suggestion. Perhaps you could draft a documentation
change - personally I'm not even sure where the best place for the warning
would be.
​
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[Steve Holden]

On Thu, Jul 12, 2018 at 6:21 PM, Barry Warsaw  wrote:

> ​[...]
>


>   I was -1 as well, but I’d say I’m a firm +0 now[*].  I like how many of
> the problematic syntactic and semantic issues have been narrowed and
> prohibited, and I can see myself using this sparingly.
>
​[...]

I think experience will show that's how it's best used - only for
measurable wins. But then Python is the kind of language where "if it's
simpler, use that" is a part of the philosophy, thanks to the Zen's
popularity.​
___
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] Can I make marshal.dumps() slower but stabler?

[Steve Holden]

Eve is indeed based on stackless 2, and are well capable of ignoring
changes they don't think they need (or were when I was working with them).
At one point I seem to remember they optimised their interpreter to use
singleton floating-point values, saving large quantities of memory by
having only one floating-point zero.

Steve Holden

On Thu, Jul 12, 2018 at 9:55 AM, Alex Walters 
wrote:

>
>
> > -Original Message-
> > From: Python-Dev  > list=sdamon@python.org> On Behalf Of Victor Stinner
> > Sent: Thursday, July 12, 2018 4:01 AM
> > To: Serhiy Storchaka 
> > Cc: python-dev 
> > Subject: Re: [Python-Dev] Can I make marshal.dumps() slower but stabler?
> >
> > 2018-07-12 8:21 GMT+02:00 Serhiy Storchaka :
> > >> Is there any real application which marshal.dumps() performance is
> > >> critical?
> > >
> > > EVE Online is a well known example.
> >
> > EVE Online has been created in 2003. I guess that it still uses Python
> 2.7.
> >
> > I'm not sure that a video game would pick marshal in 2018.
> >
>
> EVE doesn't use stock CPython, IIRC.  They use a version of stackless 2,
> with their own patches.  If a company is willing to patch python itself, I
> don't think their practices should be cited without more context about what
> they actually modified.
>
> > 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/tritium-
> > list%40sdamon.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/
> steve%40holdenweb.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] Call for prudence about PEP-572

[Steve Holden]

On Sun, Jul 8, 2018 at 10:41 AM, Giampaolo Rodola' 
wrote:

> ​[...]
> I find that (space between the parentheses of a function call statement)
> too unnatural as a place where to put an assignment. It is not even
> "guarded" by a keyword like "if" or  "while" which can help as indicators
> that an assignment may occur. Also, I think it's way too easy to confuse it
> with a keyword argument:
>
> >>> foo(x = 1)  # keyword arg
> >>> foo(x := 1)  # assignment + value passing
> ​[...]
>

​But the PEP 8 spellings are​

foo(x=1)

and

   f(x := 1).

The extra spacing makes it obvious that this isn't a regular named argument.
___
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