[Python-Dev] PyCon Survivor's breakfast

[Steve Holden]

Hi everybody,

This year sees the third PyCon Survivors' Breakfast at Suite 701, a restaurant 
attached to the Place d'Armes hotel just up the road from the Palais de Congres 
(map on Eventbrite page).

All Python developers, PSF members and PyCon delegates are cordially invited to 
attend. The event starts at 7:30 but you can roll in whenever you feel like 
breakfast (I start early so that those who wish to start sprinting promptly can 
still join us).

The places cost about $45 a head (I've been asked about costs, I don't really 
know why) and you have a choice of prices, including free. I don't want anyone 
to feel that inability to pay need stop them coming along to join us. Last 
year's event was a relaxing change from the Palais de Congres. I hope I see you 
there.

Sign up at http://bit.ly/PyConSurvivor2015.

Numbers are limited, but last year there was a place for everyone who wanted to 
attend. If you are at PyCon, or know someone who is, please let them know that 
this invitation extends to everyone who attended.

regards
 Steve
-- 
Steve Holden st...@holdenweb.com / +1 571 484 6266 / +44 113 320 2335 / 
@holdenweb




___
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] [PSF-Members] PyCon Survivor's breakfast

[Steve Holden]

Indeed. I believe that the date is on the Eventbrite page, but sorry for 
omitting obviously necessary information. It's tomorrow. Hope to see you there.

S

On Apr 12, 2015, at 4:49 PM, Stephane Wirtel  wrote:

> 7h30 morning ? Tomorrow 
> 
> On 12 avr. 2015, at 4:13 PM, Steve Holden  wrote:
> 
>> Hi everybody,
>> 
>> This year sees the third PyCon Survivors' Breakfast at Suite 701, a 
>> restaurant attached to the Place d'Armes hotel just up the road from the 
>> Palais de Congres (map on Eventbrite page).
>> 
>> All Python developers, PSF members and PyCon delegates are cordially invited 
>> to attend. The event starts at 7:30 but you can roll in whenever you feel 
>> like breakfast (I start early so that those who wish to start sprinting 
>> promptly can still join us).
>> 
>> The places cost about $45 a head (I've been asked about costs, I don't 
>> really know why) and you have a choice of prices, including free. I don't 
>> want anyone to feel that inability to pay need stop them coming along to 
>> join us. Last year's event was a relaxing change from the Palais de Congres. 
>> I hope I see you there.
>> 
>> Sign up at http://bit.ly/PyConSurvivor2015.
>> 
>> Numbers are limited, but last year there was a place for everyone who wanted 
>> to attend. If you are at PyCon, or know someone who is, please let them know 
>> that this invitation extends to everyone who attended.
>> 
>> regards
>>  Steve
>> -- 
>> Steve Holden st...@holdenweb.com / +1 571 484 6266 / +44 113 320 2335 / 
>> @holdenweb
>> 
>> 
>> 
>> 
>> ___
>> PSF-Members mailing list
>> psf-memb...@python.org
>> https://mail.python.org/mailman/listinfo/psf-members
>> PSF home page (http://www.python.org/psf/)
>> PSF membership FAQ (http://www.python.org/psf/membership/)
>> PSF members' wiki (http://wiki.python.org/psf/)

-- 
Steve Holden st...@holdenweb.com / +1 571 484 6266 / +44 113 320 2335 / 
@holdenweb




___
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 557: Data Classes

[Steve Holden]

​I make this suggestion in trepidation, given that Guido called a halt on
the Great Naming Debate, but it seems that a short, neutral name with data
connotations previously not a part of many popular subsystems is required.

I therefore propose "row", which is sufficiently neutral to avoid most
current opposition and yet a common field-oriented mechanism for accessing
units of retrieved data by name.

regards
 Steve​

Steve Holden

On Sat, Sep 16, 2017 at 3:44 PM, Sven R. Kunze  wrote:

> Thanks for the PEP! :)
>
> I like the naming. ;) Though, I would like to add to Michel's argument in
> favor of a base class.
>
>
> On 11.09.2017 08:38, Michel Desmoulin wrote:
>
>> - I read Guido talking about some base class as alternative to the
>>>> generator version, but don't see it in the PEP. Is it still considered ?
>>>>
>>> I'm going to put some words in explaining why I don't want to use base
>>> classes (I don't think it buys you anything). Do you have a reason for
>>> preferring base classes?
>>>
>> Not preferring, but having it as an alternative. Mainly for 2 reasons:
>>
>> 1 - data classes allow one to type in classes very quickly, let's
>> harvest the benefit from that.
>>
>> Typing a decorator in a shell is much less comfortable than using
>> inheritance. Same thing about IDE: all current ones have snippet with
>> auto-switch to the class parents on tab.
>>
>> All in all, if you are doing exploratory programming, and thus
>> disposable code, which data classes are fantastic for, inheritance will
>> keep you in the flow.
>>
>> 2 - it will help sell the data classes
>>
>> I train a lot of people to Python each year. I never have to explain
>> classes to people with any kind of programming background. I _always_
>> have to explain decorators.
>>
>> People are not used to it, and even kind fear it for quite some time.
>>
>> Inheritance however, is familiar, and will not only push people to use
>> data classes more, but also will let them do less mistakes: they know
>> the danger of parent ordering, but not the ones of decorators ordering.
>>
>
> 3)  - the order of base classes can arranged appropriately
>
> In our day-to-day work, we use mixins and cooperative multiple inheritance
> a lot.
> So, having dataclasses as a base class or a mixin would be great! :)
>
> Combined with 1) and 2), I am much in favor of having dataclasses as base
> class/mixin than as a decorator.
> What are the benefits of the decorator? Maybe both is possible?
>
> Cheers,
> Sven
>
>
> PS: @Michel good observation 1). Typing decorators in shell is annoying.
>
> ___
> 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 557: Data Classes

[Steve Holden]

On Thu, Oct 12, 2017 at 9:20 AM, Mike Miller 
wrote:

>
> On 2017-10-12 00:36, Stéfane Fermigier wrote:
>
>> "An object that is not defined by its attributes, but rather by a thread
>> of continuity and its identity." (from https://en.wikipedia.org/wiki/
>> Domain-driven_design#Building_blocks)
>>
>
> Not sure I follow all this, but Python objects do have identities once
> instantiated.  e.g. >>> id('')
>
> ​It seems to me that the quoted document is attempting to make a
distinction ​similar to the one between classes (entities) and instances
(value objects). The reason I liked "row" as a name is because it
resembles  "vector" and hence is loosely assocaited with the concept of a
tuple as well as being familiar to database users. In fact the answer to a
relational query was, I believe, originally formally defined as a set of
tuples.

​Sometimes one can simply be too hifalutin' [
http://www.dictionary.com/browse/hifalutin]​, and language that attempts to
be precise obscures meaning to the less specialised reader.

See also the more general Wikipedia definition "An entity is something that
>> exists as itself, as a subject or as an object, actually or potentially,
>> concretely or abstractly, physically or not." (
>> https://en.wikipedia.org/wiki/Entity).
>>
>> In the context of DDD, entities are usually opposed to value objects: "An
>> object that contains attributes but has no conceptual identity. They should
>> be treated as immutable.". (https://en.wikipedia.org/wiki
>> /Domain-driven_design#Building_blocks)
>>
>> Attrs, and by extension the dataclass proposal (I guess), provide some
>> support for both:
>>
>> - Providing support for quickly constructing immutable objects from a bag
>> of attributes, and providing equality based on those attributes, it helps
>> implement Value Objects (not sure much more is needed actually)
>>
>> - By supporting equality based on some "primary key", it will also help
>> with maintaining the concept of "equality" in entities.
>>
>
> I don't believe either module particularly supports or restricts
> immutability?
>
> -Mike
>
>
___
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] [OT] Early PyCon Pictures, anyone?

[Steve Holden]

Hi all,

I've giving a talk on the history of PyCon at PyCon UK this weekend. I'd
love to include some photos from the early conferences but alas most of the
links I've found on the web are stale and broken.

If anyone has pictures, or valid links to such pictures, I'd be delighted
to hear about them.

Thanks
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] Guarantee ordered dict literals in v3.7?

[Steve Holden]

On Mon, Nov 6, 2017 at 10:18 AM, Paul Sokolovsky  wrote:

> Hello,
>
> What happens now borders on technologic surrealism - the CPython, after
> many years of persuasion, switched its dict algorithm, rather
> inefficient in terms of memory, to something else, less inefficient
> (still quite inefficient, taking "no overhead" as the baseline). That
> algorithm randomly had another property. Now there's a seemingly
> serious talk of letting that property leak into the *language spec*,
> despite the fact that there can be unlimited number of dictionary
> algorithms, most of them not having that property.
>
> ​
I have to agree: I find the elevation of a CPython implementation detail to
a language feature ​somewhat hard to comprehend. Maybe it's more to do with
the way it's been presented, but this is hardly an enhancement the language
has been screaming for for years.

​Presumably there is little concern that algorithms that rely on this
behaviour will be perfectly syntactically conformant with earlier versions​
but will fail subtly and without explanation? It's a small concern, but a
real one - particularly for learners.

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] Allow annotations using basic types in the stdlib?

[Steve Holden]

While I appreciate the value of annotations I think that *any* addition of
them to the stdlib would complicate an important learning resource
unnecessarily. S

Steve Holden

On Mon, Nov 6, 2017 at 4:07 PM, Victor Stinner 
wrote:

> Related to annotations, are you ok to annotate basic types in the
> *documentation* and/or *docstrings* of the standard library?
>
> For example, I chose to document the return type of time.time() (int)
> and time.time_ns() (float). It's short and I like how it's formatted.
> See the current rendered documentation:
>
> https://docs.python.org/dev/library/time.html#time.time
>
> "Annotations" in the documentation and docstrings have no impact on
> Python runtime performance. Annotations in docstrings makes them a few
> characters longer and so impact the memory footprint, but I consider
> that the overhead is negligible, especially when using python3 -OO.
>
> Victor
>
> 2017-11-06 17:02 GMT+01:00 Victor Stinner :
> > Hi,
> >
> > While discussions on the typing module are still hot, what do you
> > think of allowing annotations in the standard libraries, but limited
> > to a few basic types:
> >
> > * None
> > * bool, int, float, complex
> > * bytes, bytearray
> > * str
> >
> > I'm not sure about container types like tuple, list, dict, set,
> > frozenset. If we allow them, some developers may want to describe the
> > container content, like List[int] or Dict[int, str].
> >
> > My intent is to enhance the builtin documentation of functions of the
> > standard library including functions implemented in C. For example,
> > it's well known that id(obj) returns an integer. So I expect a
> > signature like:
> >
> >   id(obj) -> int
> >
> >
> > Context: Tal Einat proposed a change to convert the select module to
> > Argument Clinic:
> >
> >https://bugs.python.org/issue31938
> >https://github.com/python/cpython/pull/4265
> >
> > The docstring currently documents the return like:
> > ---
> > haypo@selma$ pydoc3 select.epoll.fileno|cat
> > Help on method_descriptor in select.epoll:
> >
> > select.epoll.fileno = fileno(...)
> > fileno() -> int
> >
> > Return the epoll control file descriptor.
> > ---
> >
> > I'm talking about "-> int", nice way to document that the function
> > returns an integer.
> >
> > Problem: even if Argument Clinic supports "return converters" like
> > "int", it doesn't generate a docstring with the return type. So I
> > created the issue:
> >
> > "Support return annotation in signature for Argument Clinic"
> > https://bugs.python.org/issue31939
> >
> > But now I am confused between docstrings, Argument Clinic, "return
> > converters", "signature" and "annotations"...
> >
> > R. David Murray reminded me the current policy:
> >
> > "the python standard library will not include type annotations, that
> > those are provided by typeshed."
> >
> > While we are discussing removing (or not) typing from the stdlib (!),
> > I propose to allow annotations in the stdlib, *but* only limited to
> > the most basic types.
> >
> > Such annotations *shouldn't* have a significant impact on performances
> > (startup time) or memory footprint.
> >
> > The expected drawback is that users can be surprised that some
> > functions get annotations, while others don't. For example,
> > os.fspath() requires a complex annotation which needs the typing
> > module and is currently done in typeshed, whereas id(obj) can get its
> > return type documented ("-> int").
> >
> > What do you think?
> >
> > 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/
> 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] Remove typing from the stdlib

[Steve Holden]

On Tue, Nov 7, 2017 at 12:35 AM, Donald Stufft  wrote:
[..]


> Maybe we just need to fully flesh out the idea of a "Python Core" (What
> exists now as “Python”) and a “Python Platform” (Python Core + A select set
> of preinstalled libraries). Then typing can just be part of the Python
> Platform, and gets installed as part of your typical installation, but is
> otherwise an independent piece of code.
>
> Given that (type and other) annotations have been promoted as an optional
feature of the language it seems unfair and perhaps unwise to add a
dependency specifically to support
​them
 to the stdlib and therefore the Python core.
​ Since type annotations are, as Paul pointed out, development-time
features, it​ would appear to behoove those wishing to use them to separate
them in such a way that the software can be installed without annotations,
and therefore without the need for the typing module. Assuming they would
like to see the widest possible distribution, of course. For selected
audiences I am sure typing will be *de rigeur*,


​In this scenario, surely the most "typical" installation would be a
virtualenv. ​Do all virtualenvs rely on the same Platform? Who decides
which additional libraries are required for the Platform? Doesn't this just
add another "type of installation" distinction to confuse the unwary? How
do I maintain the Platform separately from the Core? Does my sysadmin
maintain either or both? I'd like to see a little more clarity about the
benefits such a schism would offer.

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] Tricky way of of creating a generator via a comprehension expression

[Steve Holden]

On Wed, Nov 22, 2017 at 8:48 PM, Sven R. Kunze  wrote:

> Isn't yield like a return?
>
​Enough like it to make a good case, I'd say.​


> A return in a list/dict/set comprehension makes no sense to me.
>
​Nor me, nor the vast majority of instance. But nowadays yield is more of a
synchronisation point. If something is valid syntax we should presumably
like to have defined semantics.

> So, +1 on SyntaxError from me too.
>
​I'd tend to agree. This would give more time to discuss the intended
semantics: giving it meaning later might be a more cautious approach that
would allow decisions to be made in the light of further experience.

I would urge developers, in their ​improvements to the language to support
asynchronous programming, to bear in mind that this is (currently) a
minority use case. Why the rush to set complex semantics in stone?

>
regards
 Steve​


> Cheers.
>
> On 22.11.2017 21:29, David Mertz wrote:
>
> Inasmuch as I get to opine, I'm +1 on SyntaxError. There is no behavior
> for that spelling that I would find intuitive or easy to explain to
> students. And as far as I can tell, the ONLY time anything has ever been
> spelled that way is in comments saying "look at this weird edge case
> behavior in Python."
>
> On Nov 22, 2017 10:57 AM, "Jelle Zijlstra" 
> wrote:
>
>
>
> 2017-11-22 9:58 GMT-08:00 Guido van Rossum :
>
>> Wow, 44 messages in 4 hours. That must be some kind of record.
>>
>> If/when there's an action item, can someone summarize for me?
>>
>> The main disagreement seems to be about what this code should do:
>
> g = [(yield i) for i in range(3)]
>
> Currently, this makes `g` into a generator, not a list. Everybody seems to
> agree this is nonintuitive and should be changed.
>
> One proposal is to make it so `g` gets assigned a list, and the `yield`
> happens in the enclosing scope (so the enclosing function would have to be
> a generator). This was the way things worked in Python 2, I believe.
>
> Another proposal is to make this code a syntax error, because it's
> confusing either way. (For what it's worth, that would be my preference.)
>
> There is related discussion about the semantics of list comprehensions
> versus calling list() on a generator expression, and of async semantics,
> but I don't think there's any clear point of action there.
>
>
>> --
>> --Guido van Rossum (python.org/~guido )
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/jelle.zij
>> lstra%40gmail.com
>>
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/mertz%
> 40gnosis.cx
>
>
>
>
> ___
> Python-Dev mailing 
> listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-dev
>
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/srkunze%40mail.de
>
>
>
> ___
> 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] Can Python guarantee the order of keyword-only parameters?

[Steve Holden]

I was going to suggest the final DeprecationWarning should be raised
unconditionally (subject to whatever silencing rules are agreed) by the
final 2.7 release to recommend migration to Python 3.

"This is an ex-language ... it has ceased to be ... it is no more ... it
has returned to the great heap whence it came ..."

Steve Holden

On Tue, Nov 28, 2017 at 5:13 PM, Brett Cannon  wrote:

>
>
> On Tue, 28 Nov 2017 at 03:33 Nick Coghlan  wrote:
>
>> On 28 November 2017 at 15:42, Larry Hastings  wrote:
>> > On 11/27/2017 03:58 PM, Yury Selivanov wrote:
>> >> We can't say anything about the order if someone passes a partial
>> >> object
>> >
>> > Sure we could.  We could ensure that functools.partial behaves in a sane
>> > way, then document and guarantee that behavior.
>>
>> Right, I think the main implication here would be that we need to
>> ensure that any signature manipulation operations *we* provide are
>> order preserving.
>>
>> Fortunately for Larry, we kinda cheat on that front: all the logic for
>> dealing with this problem is in the inspect module itself, which knows
>> about all the different ways we manipulate signatures in the standard
>> library. That means that if we want to declare that the inspect module
>> will be order preserving, we can, and it shouldn't require changes to
>> anything else.
>>
>> Cheers,
>> Nick.
>>
>> P.S. Note that inspect.getfullargspec() was actually undeprecated a
>> while back - enough folks that didn't need access to the function
>> annotations were reimplementing it for themselves "because the
>> standard library API is deprecated" that the most logical course of
>> action was to just declare it as being supported again. I don't think
>> that changes the argument here though - it just means guaranteed order
>> preservation in that API will only happen if we declare dicts to be
>> insertion ordered in general.
>>
>
> OT for this thread, but is there an issue number tracking the
> un-deprecating? Basically I want to make sure there is an issue tracking
> deprecating it again when we stop worrying about any Python 2/3 support.
>
> ___
> 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] What's the status of PEP 505: None-aware operators?

[Steve Holden]

On Fri, Dec 1, 2017 at 10:31 AM, Steven D'Aprano 
wrote:

> On Thu, Nov 30, 2017 at 11:54:39PM -0500, Random832 wrote:
>
> > The OP isn't confusing anything; it's Eric who is confused. The quoted
> > paragraph of the PEP clearly and unambiguously claims that the sequence
> > is "arguments -> function -> call", meaning that something happens after
> > the "function" stage [i.e. a None check] cannot short-circuit the
> > "arguments" stage. But in fact the sequence is "function -> arguments ->
> > call".
>
> I'm more confused than ever. You seem to be arguing that Python
> functions CAN short-circuit their arguments and avoid evaluating them.
> Is that the case?
>
> If not, then I fail to see the difference between
>
> "arguments -> function -> call"
>
> "function -> arguments -> call"
>
> In *both cases* the arguments are fully evaluated before the function is
> called, and so there is nothing the function can do to delay evaluating
> its arguments.
>
> If this is merely about when the name "function" is looked up, then I
> don't see why that's relevant to the PEP.
>
> What am I missing?
>
> ​I guess it's possible that if computing the function (i.e., evaluating
the expression immediately to the left of the argument list) and/or the
argument has side effects​

​then the evaluation order will affect the outcome. Intuitively it seems
more straightforward to compute the function first. If this expression were
to raise an exception, of course, then the arguments would not then be
evaluated. Or vice versa. It would be best of the specification matches
current CPython bahviour.
​
___
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 static typing still optional?

[Steve Holden]

On Mon, Dec 11, 2017 at 5:10 PM, Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> .
>
> I see a couple of options:
> 1a: Use a default type annotation, if one is not is supplied. typing.Any
> would presumably make the most sense.
> 1b: Use None if not type is supplied.
> 2: Rework the code to not require annotations at all.
>
> I think I'd prefer 1a, since it's easy.
>
>
> 2) would be great :-)
>
> I find this bit of “typing creep” makes me nervous— Typing should Never be
> required!
>
> ​+1
​


> I understand that the intent here is that the user could ignore typing and
> have it all still work. But I’d rather is was not still there under the
> hood.
>
> Just because standardized way to do something is included in core Python
> doesn’t mean the standard library has to use it.
>
> ​I trust my repetition of the point that the stdlib is an important
learning resource isn't unduly harping on the subject. Python is in danger
of becoming pretty arcane rather too rapidly for my own liking​, though I
confess to being mostly a consumer of Python.

> However, typing is not currently imported by dataclasses.py.
>
>
> And there you have an actual reason besides my uneasiness :-)
>
> - CHB
>
> ​hmm...​
___
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] Guarantee ordered dict literals in v3.7?

[Steve Holden]

On Fri, Dec 15, 2017 at 9:47 PM, Guido van Rossum  wrote:

> ​[...]
>


> stays ordered across deletions" part of the ruling is true in CPython 3.6.
>
> I don't know what guidance to give Eric, because I don't know what other
> implementations do nor whether Eric cares about being compatible with
> those. IIUC micropython does not guarantee this currently, but I don't know
> if they claim Python 3.6 compatibility -- in fact I can't find any document
> that specifies the Python version they're compatible with more precisely
> than "Python 3".
>

​They currently specify 3.4+.

Specifically, https://github.com/micropython/micropython includes:

"""
MicroPython implements the entire Python 3.4 syntax (including exceptions,
with, yield from, etc., and additionally async/await keywords from Python
3.5). The following core datatypes are provided: str (including basic
Unicode support), bytes, bytearray, tuple, list, dict, set, frozenset,
array.array, collections.namedtuple, classes and instances. Builtin modules
include sys, time, and struct, etc. Select ports have support for
_thread module
(multithreading). *Note that only a subset of Python 3 functionality is
implemented for the data types and modules*.
"""

Note the emphasis I added on the last sentence.
___
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] Decision of having a deprecation period or not for changing csv.DictReader returning type.

[Steve Holden]

I submitted the 3.6 patch that Raymond committed. The purpose of the change
was to allow access to the ordering of the columns.

It doesn't use any of the OrderedDict-only methods, and I'd be very
surprised if a reversion to using dict in 3.7 would cause any tests to fail.

regards
 Steve

Steve Holden

On Mon, Dec 18, 2017 at 6:30 AM, 尚辉  wrote:

> Since regular dicts are ordered in 3.7, it might be cleaner to returning 
> regular dict instead of OrderedDict?
>
>
> ___
> 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] Is static typing still optional?

[Steve Holden]

On Tue, Dec 19, 2017 at 10:53 AM, Paul Moore  wrote:

> On 19 December 2017 at 07:49, Eric V. Smith  wrote:
> > Data Classes is also not the first use of type annotations in the stdlib:
> > https://docs.python.org/3/library/typing.html#typing.NamedTuple
> >
>
> Also, the fact that no-one raised this issue during the whole time the
> PEP was being discussed (at least as far as I recollect) and that
> Guido (who of all of us should be most aware of what is and isn't
> acceptable use of annotations in the stdlib) approved the PEP,
> suggests to me that this isn't that big a deal.
>
> The only thing that has surprised me in this discussion is that the
> actual type used in the annotation makes no difference. And once
> someone reminded me that types are never enforced at runtime (you can
> call f(x: int) with f('haha')) that seemed fine.
>

​If anything, this makes things more difficult for the learner.​ The fact
that annotations are formally undefined as to anything but syntax is
sensible but can be misleading (as the example above clearly shows).

In the typing module it's logical to see annotations, I guess. But I really
hope they aren't sprinkled around willy-nilly. Sooner or later there will
be significant demand for annotated libraries, even though CPython will
perform exactly as it does with non-annotated code. I can see the value of
annotations in other environments and for different purposes, but it would
be a pity if this were to unnecessarily complicate the stdlib.

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] Guarantee ordered dict literals in v3.7?

[Steve Holden]

On Tue, Dec 19, 2017 at 4:49 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Nathaniel Smith writes:
>
>  > To make sure I understand, do you actually have a script like this, or
>  > is this hypothetical?
>
> I have a couple of doctests that assume that pprint will sort by key,
> yes.  It makes the tests look quite a bit nicer by pprinting the
> output, and I get sorting (which matters for some older Pythons) for
> free.  (I admit I don't actually use those tests with older Pythons,
> but the principle stands.)
>
> I don't see why we don't do the obvious, namely add the option to use
> "native" order to the PrettyPrinter class, with the default being
> backward compatible.
>

​Perhaps now key ordering has been pronounced we could either add a
"sorted" method to dicts equivalent to the following code.

def sorted(self):​
return {self[k] for k in sorted(self.keys())}

Alternatively the sorted built-in could be modified to handle dicts in this
way. Though I still find the assumption of any ordering at all a bit weird
I suppose I'll grow used to it.

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] Is static typing still optional?

[Steve Holden]

On Thu, Dec 21, 2017 at 7:55 PM, Terry Reedy  wrote:

> On 12/21/2017 9:23 AM, Eric V. Smith wrote:
>
>>
>>
>> On 12/21/17 6:25 AM, Sven R. Kunze wrote:
>>
>>> On 21.12.2017 11:22, Terry Reedy wrote:
>>>

 @dataclass
>> class C:
>>  a: int # integer field with no default
>>  b: float = 0.0 # float field with a default
>>
>> And the types will be recognized by type checkers such as mypy.
>>
>> And I think the non-typed examples should go first in the docs.
>>
>

>>> I still don't understand why "I don't care" can be defined by "leaving
>>> out"
>>>
>>> @dataclass
>>> class C:
>>>  b = 0.0 # float field with a default
>>>
>>
>> Because you can't know the order that x and y are defined in this example:
>>
>> class C:
>>  x: int
>>  y = 0
>>
>> 'x' is not in C.__dict__, and 'y' is not in C.__annotations__.
>>
>
>
​Solely because, annotations being optional, the interpreter is not allowed
to infer from its presence  that an annotated name should be ​allocated an
entry in __dict__, and clearly the value associated with it would be
problematical.

I think the understanding problem with this feature arises from two
> factors: using annotations to define possibly un-initialized slots is
> non-obvious; a new use of annotations for something other than static
> typing is a bit of a reversal of the recent pronouncement 'annotations
> should only be used for static typing'.  Therefore, getting the permanent
> doc 'right' is important.
>

​Indeed. So annotations are optional, except where they aren't?​


> The following naively plausible alternative does not work and cannot
> sensibly be made to work because the bare 'x' in the class scope, as
> opposed to a similar error within a method, causes NameError before the
> class is created.
>
> @dataclass
> class C:
> x
> y = 0
>
> ​Quite. Could this be handled the same way not-yet initilialised slots
are? (Pardon my ignornace).
​


> I think the doc should explicitly say that uninitialized fields require
> annotation with something (anything, not necessarily a type) simply to
> avoid NameError during class creation.  It may not be obvious to some
> readers why x:'anything' does not also raise NameError, but that was a
> different PEP, and the dataclass doc could here link to wherever
> name:annotation in bodies is explained.
>
>
​This contortion is why I feel a better solution would be desirable. Alas I
do not have one to hand.

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] LibreSSL support

[Steve Holden]

On Fri, Jan 19, 2018 at 12:09 AM, Nathaniel Smith  wrote:

> On Jan 18, 2018 07:34, "Christian Heimes"  wrote:
>
> On 2018-01-16 21:17, Christian Heimes wrote:
> > FYI, master on Travis CI now builds and uses OpenSSL 1.1.0g [1]. I have
> > created a daily cronjob to populate Travis' cache with OpenSSL builds.
> > Until the cache is filled, Linux CI will take an extra 5 minute.
>
> I have messed up my initial research. :( When I was checking LibreSSL
> and OpenSSL for features, I draw a wrong conclusion. LibreSSL is *not*
> OpenSSL 1.0.2 compatible. It only implements some of the required
> features from 1.0.2 (e.g. X509_check_hostname) but not
> X509_VERIFY_PARAM_set1_host.
>
> X509_VERIFY_PARAM_set1_host() is required to perform hostname
> verification during the TLS handshake. Without the function, I'm unable
> to fix Python's hostname matching code [1]. LibreSSL upstream knows
> about the issue since 2016 [2]. I have opened another bug report [3].
>
> We have two options until LibreSSL has addressed the issue:
>
> 1) Make the SSL module more secure, simpler and standard conform
> 2) Support LibreSSL
>
>
> ​[...]
>


> We have *very* few people qualified to maintain the ssl module, so given
> the new landscape I think we should focus on keeping our core OpenSSL
> support solid and not worry about LibreSSL. If LibreSSL wants to be
> supported as well then – like any other 2nd tier platform – they need to
> find someone to do the work. And if people are worried about supporting
> more diversity in SSL implementations, then PEP 543 is probably the thing
> to focus on.
>
> ​Given the hard limit on resources it seems only sensible to focus on the
"industry standard" library​. I'm rather disappointed that LibreSSL isn't a
choice, but given the lack of compatibility that's hardly Python's problem.
___
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] Support of the Android platform

[Steve Holden]

For this to move forward more rapidly it would really help if there were a
utility VM appliance available with a ready-installed support an SDK. Or at
least that would lower impedance to joining the development effort. Does
any such beast by chance exist?

S

Steve Holden

On Tue, Jan 23, 2018 at 5:17 PM, Victor Stinner 
wrote:

> Ok, I created https://bugs.python.org/issue32637
> "Android: set sys.platform and os.name to android"
>
> Victor
>
> 2018-01-23 18:01 GMT+01:00 Brett Cannon :
> >
> >
> > On Mon, 22 Jan 2018 at 09:29 Victor Stinner 
> > wrote:
> >>
> >> Hi,
> >>
> >> I'm still talking with Paul Peny (pmpp on IRC) who is trying to build
> >> the master branch of Python on Android, using cross-compilation or
> >> directly on an Android device. I started to took notes since Android
> >> is a complex platforms and it's not easy for me to remember
> >> everything.
> >>
> >> http://vstinner.readthedocs.io/python_android.html
> >>
> >> Paul would like to support Android 4.4 Kitkat (API 19) just because
> >> it's possible to find cheap devices running Android, but usually only
> >> with old Android versions. Technically, it doesn't see difficult to
> >> support API 19+ (instead of 21+), a few tiny patches are needed. But I
> >> don't want to have a "full support" of API 19+, only basic support
> >> like "make sure that the compilation doesn't fail", not "all tests
> >> must pass".
> >>
> >> It seems like sys.platform == 'android' would be more appropriate
> >> since Android is not Linux: different libc, different filesystems,
> >> etc.
> >
> >
> > I've had a similar thought myself.
> >
> > -Brett
> >
> >>
> >>
> >> While Xavier promotes cross-compilation, Paul would like to build
> >> Python directly on Android to get pip and wheels.
> >>
> >> Honestly, I have no strong opinion, since I don't know well Android.
> >> I'm trying to help everybody working on the Android support. IMHO it's
> >> fine to support multiple ways to build Python for Android. It's not
> >> like there is very obvious option which has no drawback... Cross
> >> compilation is complex, getting a C compiler on Android also seems to
> >> be complex. From my point of view, compared to a common Fedora Linux,
> >> Android doesn't seem easy to use to develop on CPython...
> >>
> >> Victor
> >>
> >> 2017-12-10 15:19 GMT+01:00 Xavier de Gaye :
> >> > The following note is a proposal to add the support of the Android
> >> > platform.
> >> >
> >> > The note is easier to read with clickable links at
> >> > https://github.com/xdegaye/cagibi/blob/master/doc/android_support.rst
> >> >
> >> > Motivations
> >> > ===
> >> >
> >> > * Android is ubiquitous.
> >> > * This would be the first platform supported by Python that is
> >> > cross-compiled,
> >> >   thanks to many contributors.
> >> > * Although the Android operating system is linux, it is different from
> >> > most
> >> >   linux platforms, for example it does not use GNU libc and runs
> SELinux
> >> > in
> >> >   enforcing mode. Therefore supporting this platform would make Python
> >> > more
> >> >   robust and also would allow testing it on arm 64-bit processors.
> >> > * Python running on Android is also a handheld calculator, a successor
> >> > of
> >> > the
> >> >   slide rule and the `HP 41`_.
> >> >
> >> > Current status
> >> > ==
> >> >
> >> > * The Python test suite succeeds when run on Android emulators using
> >> > buildbot
> >> >   strenuous settings with the following architectures on API 24: x86,
> >> > x86_64,
> >> >   armv7 and arm64.
> >> > * The `Android build system`_ is described in another section.
> >> > * The `buildmaster-config PR 26`_ proposes to update ``master.cfg`` to
> >> > enable
> >> >   buildbots to run a given Android API and architecture on the
> >> > emulators.
> >> > * The Android emulator is actually ``qemu``, so the test suites for
> x86
> >> > and
> >> >   x86_64 last about the same time as the test suite run natively whe

[Python-Dev] CLion IDE

[Steve Holden]

I've just start using CLion from JetBrains, and I wondered if anyone on the
list is using this product in CPython development. Links to any guidance
would be useful.

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] OS-X builds for 3.7.0

[Steve Holden]

The horizontal axis labelling in that graph is useless with so many tests
included!

Would a graphic with hover labels over the bars be more useful?

Steve Holden

On Wed, Jan 31, 2018 at 1:06 PM, Victor Stinner 
wrote:

> There is https://speed.python.org/comparison/ to compare Python 2.7, 3.5,
> 3.6 and master (future 3.7).
>
> Victor
>
> Le 31 janv. 2018 13:14, "Ray Donnelly"  a écrit :
>
>> On Wed, Jan 31, 2018 at 11:16 AM, Joni Orponen 
>> wrote:
>> > On Wed, Jan 31, 2018 at 9:31 AM, Ray Donnelly 
>> > wrote:
>> >>
>> >> We see a 1.1 to 1.2 times performance benefit over official releases as
>> >> measured using 'python performance'.
>> >>
>> >> Apart from a static interpreter we also enable LTO and PGO and only
>> build
>> >> for 64-bit so I'm not sure how much each bit continues. Our recipe for
>> >> python 3.6 can be found at:
>> >
>> >
>> > Do you metrify LTO and PGO independent of each other as well or only the
>> > "enable everything" combo? I've had mixed results with LTO so far, but
>> this
>> > is probably hardware / compiler combination specific.
>>
>> I've never found enough time to take detailed metrics, sorry. Maybe
>> one day? Looking at my performance graphs again:
>>
>> Against the official CPython 3.6 (probably .3 or .4) release I see:
>> 1 that is 2.01x faster (python-startup, 24.6ms down to 12.2ms)
>> 5 that are >=1.5x,<1.6x faster.
>> 13 that are >=1.4x,<1.5x faster.
>> 21 that are >=1.3x,<1.4x faster.
>> 14 that are >=1.2x,<1.3x faster.
>> 5 that are >=1.1x,<1.2x faster.
>> 0 that are < 1.1x faster/slower.
>>
>> Pretty good numbers overall I think.
>>
>>
>>
>>
>> >
>> > --
>> > Joni Orponen
>> >
>> > ___
>> > 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/mingw.
>> android%40gmail.com
>> >
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe: https://mail.python.org/mailman/options/python-dev/victor.
>> stinner%40gmail.com
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> 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] OS-X builds for 3.7.0

[Steve Holden]

Doh! Thank you.

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] Dataclasses and correct hashability

[Steve Holden]

As a Bear of Relatively Little Brain, I've grown up understanding, and
teaching, that mutable things aren't to be used as dict keys. I'm aware
that immutability isn't strictly the required condition, but it for most
people, that's the primary reason for using frozen sets and tuples, for
example, and immutability serves as a practical and comprehensible first
approximation. So I'm at a loss to understand why I am being offered a
feature that (especially during maintenance by a different developer) might
be prone to bizarre errors caused by a change in hash.

I realise that this won't happen very often, but the difficulty of the
debug task should surely merit at least some warning for us bears - you
know, the ones that take your work and use it to do mundane things with.

On a slightly tangential note, us bears are very glad that such questions
are taken seriously and discussed in such depth. Thank you all.

Steve Holden

On Sat, Feb 3, 2018 at 6:44 AM, Guido van Rossum  wrote:

> It appears Eric and I are the only ones in favor of keeping the current
> behavior. But I still am not convinced by all the worries about "attractive
> nuisances" and all the other bad names this feature has been called. We
> don't know that any of the doomsday scenarios will happen. In my
> experience, usually once something is rolled out the set of issues that are
> *actually* raised is entirely different from the things its designers were
> worried about.
>
> Please don't commit a change to roll this back without checking in with
> me; I have some misgivings about the problem being raised here that I still
> need to think through more carefully. In the meantime, please try to use
> dataclasses with 3.7b1!
>
> On Fri, Feb 2, 2018 at 10:25 PM, Nick Coghlan  wrote:
>
>>
>>
>> On 3 Feb. 2018 1:09 am, "Eric V. Smith"  wrote:
>>
>>
>> The problem with dropping hash=True is: how would you write __hash__
>> yourself? It seems like a bug magnet if you're adding fields to the class
>> and forget to update __hash__, especially in the presence of per-field
>> hash=False and eq=False settings. And you'd need to make sure it matches
>> the generated __eq__ (if 2 objects are equal, they need to have the same
>> hash value).
>>
>>
>> I think anyone that does this needs to think *very* carefully about how
>> they do it, and offering both "hash=True" and "frozen=True" is an
>> attractive nuisance that means people will write "hash=True" when what they
>> wanted was "frozen=True".
>>
>> In particular, having to work out how write a maintainable "__hash__"
>> will encourage folks to separate out the hashed fields as a separate frozen
>> subrecord or base class.
>>
>> If this proves to be an intolerable burden then the short hand spelling
>> could be added back in 3.8, but once we ship it we're going to be stuck
>> with explaining the interactions indefinitely.
>>
>> Cheers,
>> Nick.
>>
>
___
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 4.0 a major breaking changes release?

[Steve Holden]

On Sat, Feb 3, 2018 at 10:46 PM, Ned Deily  wrote:

> On Feb 3, 2018, at 17:40, Alex Walters  wrote:
> > I am still working on porting code from 2.x to 3.x.  As of late on the
> lists
> > I've seen comments about making somewhat major changes in 4.0 - now I'm
> > concerned that I should pause my porting effort until that is released.
> Is
> > python 4 going to be another python 3?
>
> At this point, Python 4 is just a convenient tag for really big changes.
> There are no concrete plans or schedule for such a major undertaking.  Port
> away to Python 3.x!
>
> ​"Py3K?" they said, "oh, no, we're just noodling around with a few ideas
..."​ :-)

To be honest, and historically fair to Guido, he did warn for a long time
that we should expect breaking changes in an eventual wart-removal release.

It seemed to me the biggest disappointment was the team not having the
resources to devote to a mooted but never really achieved reorganisation of
the stdlib.

​Rectifying that omission would, I hope, be included as a priority in any
Python 4 design. Since people rely on the stdlib hugely, automated
translation of at least 98% of existing stdlib imports should be a goal.
But that's just  me.
​
___
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] libxml2 installation/binding issue

[Steve Holden]

On Mon, Feb 5, 2018 at 10:55 PM, Ethan Smith  wrote:

> This list is for the discussion of development *of* Python. For
> discussion of development *with* Python, you want python-list.
>

 ... Whose web page can be found at
https://mail.python.org/mailman/listinfo/python-list

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] A minimal Python interpreter written in Python for experimenting with language changes

[Steve Holden]

On Tue, Feb 6, 2018 at 3:40 AM, Steven D'Aprano  wrote:

> On Sat, Feb 03, 2018 at 11:45:15AM +0100, asrp wrote:
>
> ​[...]
>


> Here's a faked session showing the sort of thing I am referring to.
> (Note that this is just an example, not a proposal for a new language
> feature.)
>
> for x in [1, 2, 3]:
> print(x)
> otherwise:
> print("nothing there")
>
>
> prints 1, 2, 3.
>

​I think you meant

for x in ([1, 2, 3], ):

​
___
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 is the GitHub workflow working for people?

[Steve Holden]

On Wed, Feb 21, 2018 at 5:53 PM, Brett Cannon  wrote:

>
>
> On Wed, 21 Feb 2018 at 09:30 Yury Selivanov 
> wrote:
>
>>
>
>
>> Huge thanks to the core-workflow team!
>>
>>
​Hear, hear!

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] PEP 467 (Minor API improvements for binary sequences) - any thoughts?

[Steve Holden]

I think the chances of a "byte" object are about as good as the chances of
a character object (though one can always implement such in C extensions,
that wouldn't build them into the syntax). The fact that characters are
single-byte strings is responsible for certain anomalies with (e.g.) the
__contains__ operator (list elements aren't lists, but string element are
strings), but overall the choices made lead to sensible, comprehensible
code.

regards
 Steve

Steve Holden

On Wed, Feb 21, 2018 at 8:26 PM, Chris Barker  wrote:

> On Wed, Feb 21, 2018 at 11:55 AM, Elias Zamaria 
> wrote:
>
>> This is about some minor changes to the bytes, bytearray, and memoryview
>> classes. Here is the PEP: https://www.python.org/dev/peps/pep-0467/
>>
>
>
>> I am waiting for this to be merged, or approved, or whatever is the next
>> step. Someone on the bug tracker mentioned restarting the discussion on the
>> mailing list, so that is what I'm trying to do here. Does anyone have any
>> thoughts?
>>
>
> +1 all around.
>
> One other thought:
>
> : Addition of optimised iterator methods that produce bytes objects
>
> Maybe it would make sense to have a "byte" type that holds a single byte.
> It would be an integer that could only hold values from 0-255. Then the
> regular iterator could simply return a bunch of single byte objects.
>
> I can't say I've thought it through, but if a byte is a int with
> restricted range, then it could act like an int in (almost?) every context,
> so there would be no need for a separate iterator.
>
> I also haven't thought through whether there is any real advantage to
> having such a type -- but off the top of my head, making a distinction
> between a bytes object that happens to be length-one and a single byte
> could be handy. I sure do often wish for a character object.
>
> -CHB
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> 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 2.7 -- bugfix or security before EOL?

[Steve Holden]

Speaking from the sidelines, I'd say that any further backporting of
non-security fixes would appear to be throwing good development effort away,

This software is less than two years from the extremely well-heralded end
of its life and people are expecting enhancements? It's a cold, ungrateful
world we live in!

It might be useful to retain the issues for the benefit of those who way
wish to maintain the release after EOL, or at least get a list of them
before the tags are wiped.

regards
 Steve

Steve Holden

On Wed, Mar 14, 2018 at 1:16 PM, Michael Scott Cuthbert 
wrote:

> >* it still is in the time period before
> *>* EOL that other recent versions have gone to security only.
> *
> Again, not relevant.
>
> You might want to read http://python3statement.org/. 
> <http://python3statement.org/>
>
> I’m guessing my first message was unclear or able to be misunderstood in
> some part — I’m one of the frequent contributors to python3statement.org
> and have moved my own Python projects to Py3 only (the main one, music21,
> gets its 3.4+-only release this Saturday).  I have NO desire to prolong the
> 2.7 pain.
>
> What I am referring to is the number of “needs backport to 2.7” tags for
> non-security-related bug-fixes in the issue tracker. (
> https://github.com/python/cpython/pulls?q=is%3Apr+is%
> 3Aopen+label%3A%22needs+backport+to+2.7%22
> <https://github.com/python/cpython/pulls?q=is:pr+is:open+label:%22needs+backport+to+2.7%22>)
> My question was between now and 1 Jan 2020 should we still be fixing things
> in 2.7 that we’re not fixing in 3.5, or leave 2.7 in a security-only mode
> for the next 21 months?  Looking at what has been closed recently, without
> getting a bpo for actually backporting, it appears that we’re sort of doing
> this in practice anyhow.
>
> Thanks! and even if my message was read differently than I intended, glad
> that it had a good effect.
>
> Michael Cuthbert (https://music21-mit.blogspot.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] Deprecating float.is_integer()

[Steve Holden]

On Wed, Mar 21, 2018 at 3:08 PM, Guido van Rossum  wrote:

> I searched 6M LoC of Python code at Dropbox and found only three uses.
> They seem legit. Two are about formatting a number that's given as a float,
> deciding whether to print a float as 42 or 3.14. The third is attempting a
> conversion from float to integer where a non-integer must raise a specific
> exception (the same function also supports a string as long as it can be
> parsed as an int).
>
> I don't doubt we would get by if is_integer() was deprecated.
>
> ​Since code that's been deleted can't have bugs, +1.​
___
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] Better support for consuming vendored packages

[Steve Holden]

On Sat, Mar 24, 2018 at 9:29 AM, Nick Coghlan  wrote:

> On 23 March 2018 at 02:58, Gregory Szorc  wrote:
>
>> I'd like to start a discussion around practices for vendoring package
>> dependencies. I'm not sure python-dev is the appropriate venue for this
>> discussion. If not, please point me to one and I'll gladly take it there.
>>
>>
> ​[...]​
>
> If it's the main application doing the vendoring, then the following kind
> of snippet can be helpful:
>
> from knights.vendored import shrubbery
> import sys
> sys.path["shrubbery"] = shrubbery
>
> ​I suspect you meant
>

​sys.modules["shrubbery"]​ = shrubbery
___
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: Assignment Expressions

[Steve Holden]

On Mon, Apr 23, 2018 at 8:28 AM, Antoine Pitrou  wrote:

> On Mon, 23 Apr 2018 00:44:44 -0500
> Tim Peters  wrote:
> ​[...]
>
> > if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
> > return g
> > That's so Pythonic I could cry ;-)
>
> ​[...]
>
> The second part, especially, where you use the result of an
> assignment expression as a comparison operand, looks definitely
> un-Pythonic.
>
> ​Which, I suppose, underlines that Pythonicity is in the mind of the
beholder.​


The assignment expression seems like a vary natural way to introduce
variables of limited (controlled?) scope, and the class-namespace special
case doesn't seem horrible enough to put me, at least, off the idea. There
will, of course, be those who abuse assignment expressions, and I'm very
much looking forward to seeing what David Beazley makes of them.

While Tim's expression might look (superficially) like C, the five-line
alternative isn't exactly an inspiring example of Pythonicity, is it?

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] PEP 572: Assignment Expressions

[Steve Holden]

What facilities does the interpreter currently have for extracting common
subexpressions, and how would it verify in such a dynamic environment that
such extractions wouldn't alter the semantics of the program? Explicit
(assignment using :=) is better than implicit (by optimizations hidden to
the programmer).

regards
 Steve

Steve Holden

On Mon, Apr 23, 2018 at 6:13 PM, Sven R. Kunze  wrote:

> On 23.04.2018 17:59, Steve Holden wrote:
>
>
> While Tim's expression might look (superficially) like C, the five-line
> alternative isn't exactly an inspiring example of Pythonicity, is it?
>
>
> What about
>
> diff = x - x_base
> if diff and gcd(diff, n) > 1:
> return gcd(diff, n)
>
> # or
>
> if (x - x_base) and gcd(x - x_base, n) > 1:
> return gcd(x - x_base, n)
>
>
>
> and have the interpreter handle the optimization, or apply an lru_cache?
> ;-)
>
> Cheers,
> Sven
>
> ___
> 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 572: Assignment Expressions

[Steve Holden]

On Wed, Apr 25, 2018 at 6:15 AM, Nick Coghlan  wrote:

> On 25 April 2018 at 13:56, Guido van Rossum  wrote:
> > On Tue, Apr 24, 2018 at 8:24 PM, Nick Coghlan 
> wrote:
> >>
> >> I also think it would be good for the PEP to spell out the following
> >> semantic invariant for code running in a regular namespace:
> >>
> >> _rhs = expr
> >> assert (target := _rhs) is _rhs and target is _rhs
> >>
> >> It's the restriction to single names as targets that makes it possible
> >> to impose such a strong assertion about what the syntax means.
> >
> > Can you elaborate? I don't understand what you mean by this.
>
> The assertion is just spelling out in code form that given the name
> binding expression "target := expr", then:
>
> 1. the result of the expression itself is "expr", exactly as if the
> name binding was omitted
> 2. that result is also bound to the name "target" in the current scope
>
> The preceding "_rhs = expr" line is included to make the invariant
> generalise even to expressions that have side effects or can change
> their output based on mutable system state.
>
> Ironically, that may be clearer if I use another assignment statement
> to break it out as two separate invariants:
>
> _rhs = expr
> _inline_result = (bound_name := _rhs)
> assert _inline_result is _rhs
> assert bound_name is _rhs
>
> By contrast, the protocols involved in handling more complex
> assignment targets and in handling augmented assignment mean that it
> wouldn't be possible to define a similarly simple invariant of what
> they mean (since the exact runtime behaviour would be both type and
> target dependent).
>
>
​While it's handy that one _could_ use any valid assignment target,
allowing this wouldn't (IMHO) necessarily be a good idea.
Binding/assignment expressions fit well into Python's semantics (where
bindings copy references rather than data) precisely because names are
effectively and straightforwardly shorthand for values at the point of
assignment.

Restricting the targets in

target := expression

to simple names would avoid a lot of the tricksiness that less experienced
programmers might be tempter to indulge, leading to simpler code without
undue restrictions on what can be done.

The PEP is currently somewhat confused on naming, since it is entitled
"Assignment Expressions" but appears to then exclusively use the name
"named expressions" to reference the concept under "Syntax and Semantics"
and "assignment expression" elsewhere. I'd prefer the term "name binding
expressions," since that implies the stricture that more complex targets
are excluded. Whatever is chosen, usage in the PEP should be consistent.

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] assignment expressions: an alternative alternative proposal

[Steve Holden]

On Wed, Apr 25, 2018 at 6:16 AM, Steven D'Aprano 
wrote:

> On Tue, Apr 24, 2018 at 03:54:30PM -0700, Guido van Rossum wrote:
>
> > We should really take this back to python-ideas at this point.
>
> Please no :-(
>

​+1
​
___
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: Write vs Read, Understand and Control Flow

[Steve Holden]

On Wed, Apr 25, 2018 at 4:56 AM, Tim Peters  wrote:

> [Tim]
> >> Binding expressions are debugger-friendly in that they _don't_ just
> >> vanish without a trace.  It's their purpose to _capture_ the values of
> >> the expressions they name.  Indeed, you may want to add them all over
> >> the place inside expressions, never intending to use the names, just
> >> so that you can see otherwise-ephemeral intra-expression results in
> >> your debugger ;-)
>
>
> [Steven D'Aprano ]
>  wrote:
> > That's a fantastic point and I'm surprised nobody has thought of it
> > until now (that I've seen).
> >
> > Chris, if you're still reading this and aren't yet heartedly sick and
> > tired of the PEP *wink* this ought to go in as another motivating point.
>
> You know, I thought I was joking when I wrote that - but after I sent
> it I realized I wasn't ;-)
>
> ​You just don't realise how perspicacious you truly are, Tim!
​


> It would actually be quite convenient, and far less error-prone, to
> add a binding construct inside a complicated expression for purposes
> of running under a debugger.  The alternative is typing the
> sub-expression(s) of interest by hand at the debugger prompt, or
> adding print()s, both of which are prone to introducing typos, or
> changing results radically due to triggering side effects in the code
> invoked by the duplicated sub-expression(s).  Adding a binding
> construct wouldn't change anything about how the code worked (apart
> from possibly clobbering a local name).


​Indeed, in the cases where I currently find myself unwrapping expressions
to capture their values in local variables for debugging purposes it would
usually be far less intrusive to bind a name to the expression inline, then
use the debugger to inspect the value.
​
___
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] (name := expression) doesn't fit the narrative of PEP 20

[Steve Holden]

On Wed, Apr 25, 2018 at 9:55 PM, Łukasz Langa  wrote:

>
> > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum  wrote:
> >
> > You don't seem to grasp the usability improvements this will give. I
> hear you but at this point appeals to Python's "Zen" don't help you.
>
> This reads dismissive to me. I did read the PEP and followed the
> discussion on
> python-dev. I referred to PEP 20 because it distills what's unique about
> the
> value proposition of Python. It's our shared vocabulary.
>
> ​Perhaps so, but no PEP is chiselled in stone, and I would suggest that
PEP 20 is the least authoritative from a didactic point of view.
​


> Can you address the specific criticism I had? To paraphrase it without PEP
> 20
> jargon:
>
> > (name := expression) makes code less uniform.  It inserts more
> information
> > into a place that is already heavily packed with information (logic
> tests).
>
>
​One could argue the same about list comprehensions if one chose: they make
code denser (by expressing the same algorithm in a shorter spelling). I'm
not sure what you mean by "less uniform."​
___
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] (name := expression) doesn't fit the narrative of PEP 20

[Steve Holden]

On Thu, Apr 26, 2018 at 8:56 AM, Steven D'Aprano 
wrote:

> On Thu, Apr 26, 2018 at 03:31:13AM -0400, Terry Reedy wrote:
> > On 4/25/2018 8:20 PM, Chris Angelico wrote:
> > >On Thu, Apr 26, 2018 at 10:11 AM, Yury Selivanov
> > > wrote:
> > >>Just yesterday this snippet was used on python-dev to show how great
> the
> > >>new syntax is:
> > >>
> > >>   my_func(arg, buffer=(buf := [None]*get_size()),
> size=len(buf))
> >
> > What strikes me as awful about this example is that len(buf) is
> > get_size(), so the wrong value is being named and saved.
> > 'size=len(buf)' is, in a sense, backwards.
>
> Terry is absolutely right, and I'm to blame for that atrocity. Mea
> culpa.
>
> ​Perhaps a better spelling would be

my_func(arg, buffer=[None]*(buflen := get_size()), size=buflen)

​[...]
___
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] (name := expression) doesn't fit the narrative of PEP 20

[Steve Holden]

On Fri, Apr 27, 2018 at 8:19 PM, Tim Peters  wrote:

> [Lukasz]
> >> >  And that *is* a thing that you will have to explain to newbies when
> >> > they encounter it for the first time.
>
> ​Which they will presumably do either in class or by reading code. No
sensible instructor or course author is going to bring name-binding
expressions up until standard assignment has been thoroughly assimilated.
In my own teaching experience I observed that those used to static
languages took a little time to adapt to the indirection of Python's names,
but not long.
​


> ​[...]
>
> Sure.  What I wrote was shorthand for what's already been covered at
> length many times:  what a binding expression does is "easy to
> explain" GIVEN THAT someone ALREADY UNDERSTANDS how binding a name
> works.  The latter in fact seems difficult for a significant number of
> people to learn, but it's utterly unavoidable that they learn it if
> they're ever to write non-trivial Python programs.  That's been true
> since Python's first release.
>
> ​I was half-expecting someone to pop up and suggest only functional
programming as a means to avoid having to teach assignment ...
​


> Binding expressions would be introduced much later in any sane course.
> At THAT point, for students who haven't already dropped out, the
> semantics are darned-near trivial to explain:  it binds the name to
> the object the expression evaluates to (all of which they _already_
> understand by this point), and the value of the binding expression is
> that object (the only new bit).
>
> Unlike as for most other operators, you don't even have to weasel-word
> it to account for that a magical dunder method may change what ":="
> does.  As for the "is" operator, the meaning is baked into the
> language and can't be altered in the slightest.
>
>
> > So having one more way to do assignment WILL make it harder to
> > teach, not because it's that hard, but because it's one more thing to
> learn.
>
> ​But surely that depends on HOW MUCH of the language you aim to teach.
​Over the years Python has become a much more complex language, but it has
a fairly easily-identified subset that can act as a basis for building
useful programs. Some instructors avoided teaching comprehensions, but a
sensible course would try to ensure that students could understand the code
they were most likely to encounter "in the wild."

[
> ​...]
>
> You now, I think instructors like me are partly responsible. "is" is
> rarely
> > useful outside of comparing to singletons. Yet I use it early in
> instruction
> > to do checks on name binding and show things with mutablilty, etc
> which
> > has the unfortunate side effect of making it seem like a more common
> > operator than it is.
> >
>
​I'd expand that to say that identity comparison is most useful for types
whose instances are all unique. For other types there's the unfortunate
impedance mismatch between identity and equality (which is user-definable
anyway).
​


> > I've even had students write code like:
> >
> > if x is 3:
> >
> > and thanks to interning, it appears to work!
>
> ​No, thanks to interning it DOES work. For interned values.​

​But instructors have to touch on implementation artefacts at times, and I
used to find it instructive to write the same code with two different
integer constants and ask why they gave different results. It certainly
helped people to master the semantics of assignment (as did the phrase
"Python never copies data on assignment").​

Yup, that's the real problem with "is":  its semantics are dead
> simple, but "but under exactly what conditions are `x` and `y` bound
> to the same object?" is intractable.  It seems to take a long time to
> get across the point, that the question itself is misguided.  A full
> answer requires delving into transient implementation details, which
> is counterproductive because they _are_ accidents of the
> implementation du jour.  What questioners need to be nudged into
> asking instead is for examples of when using "is" is thoroughly sane.
>

​I'd argue that without some knowledge of the potential pitfalls students
can't be expected to learn how to make that distinction.

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] PEP 572: Assignment Expressions

[Steve Holden]

On Tue, May 1, 2018 at 3:36 AM, Chris Jerdonek 
wrote:

> On Thu, Apr 26, 2018 at 10:33 AM, Sven R. Kunze  wrote:
> > On 25.04.2018 01:19, Steven D'Aprano wrote:
> >>
> >> Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that
> >> sometimes g is better. [...]
> >
> > We were talking about the real-world code snippet of Tim (as a
> justification
> > of := ) and alternative rewritings of it without resorting to new syntax.
>
> Apologies if this idea has already been discussed (I might have missed
> the relevant email), but thinking back to Tim's earlier example--
>
> if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
> return g
>
> it occurs to me this could be implemented with current syntax using a
> pattern like the following:
>
> stashed = [None]
>
> def stash(x):
> stashed[0] = x
> return x
>
> if stash(x - x_base) and stash(gcd(stashed[0], n)) > 1:
> return stashed[0]
>
> There are many variations to this idea, obviously. For example, one
> could allow passing a "name" to stash(), or combine stash / stashed
> into a single, callable object that allows setting and reading from
> its store. I wonder if one of them could be made into a worthwhile
> pattern or API..
> ​.
>

​I hope you don't think this recasting, is in any way less confusing to a
beginner than an inline assignment. This is language abuse!

In any case, what advantages would it have over simply declaring "stashed"
as a global inside the function and omitting the confusing subscripting?

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] Drop/deprecate Tkinter?

[Steve Holden]

On Thu, May 3, 2018 at 12:12 AM, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> On 03.05.2018 1:01, Antoine Pitrou wrote:
>
>> On Wed, 2 May 2018 22:54:04 +0100
>> Paul Moore  wrote:
>>
>>> On 2 May 2018 at 22:37, Antoine Pitrou  wrote:
>>>
 To elaborate a bit: the OP, while angry, produced both a detailed
 analysis *and* a PR.  It's normal to be angry when an advertised
 feature doesn't work and it makes you lose hours of work (or, even,
 forces you to a wholesale redesign). Producing a detailed analysis and a
 PR is more than most people will ever do.

>>> His *other* email seems reasonable, and warrants a response, yes. But
>>> are we to take the suggestion made here (to drop tkinter) seriously,
>>> based on the fact that there's a (rare - at least it appears that the
>>> many IDLE users haven't hit it yet) race condition that causes a crash
>>> in Python 2.7? (It appears that the problem doesn't happen in the
>>> python.org 3.x builds, if I understand the description of the issue).
>>>
>> In 3.x, Tkinter+threads is broken too, albeit in a different way -- see
> https://bugs.python.org/issue33412 (this should've been the 2nd link in
> the initial message, sorry for the mix-up).
>

​The observation in t​hat issue that tkinter and threads should be handled
in specific ways is certainly a given for old hands, who have long put the
GUI code in one thread with one or more concurrent worker threads typically
communicating through queues. But I haven't built anything like that
recently, so I couldn't say how helpful the current documenation might be.

The 2.x bug also shows in 3.x if it's linked with a nonthreaded version of
> Tcl (dunno how rare that is, but the code still supports this setup).
>
>> I and others actually suggested it seriously in the past.  Now,
>> admittedly, at least IDLE seems better maintained than it used to
>> be -- not sure about Tkinter itself.
>>
>> Nor do I think the tone of his message here is acceptable - regardless
>>> of how annoyed he is, posting insults ("no-one gives a damn") about
>>> volunteer contributors in a public mailing list isn't reasonable or
>>> constructive. Call that "playing speech police" if you want, but I
>>> think that being offended or annoyed and saying so is perfectly
>>> reasonable.
>>>
>> Will all due respect, it's sometimes unpredictable what kind of wording
>> Anglo-Saxons will take as an insult, as there's lot of obsequiosity
>> there that doesn't exist in other cultures. To me, "not give a damn"
>> reads like a familiar version of "not care about something", but
>> apparently it can be offensive.
>>
> Confirm, never meant this as an insult.
>
> I had to use emotional language to drive the point home that it's not some
> nitpick, it really causes people serious trouble (I lost a source of
> income, for the record).
> Without the emotional impact, my message could easily be ignored as some
> noise not worth attention. This time, it's just too damn important to allow
> this possibility.
>
> With respect, I would say you CHOSE to use emotional language. I don't see
that much indication that its absence had failed to produce responses,
though they may not have been the responses you wanted.

Unfortunately the developers are rather too used to this kind of gratuitous
abuse and so many of them may have overlooked your detailed analysis of the
issues you were experiencing, since constructive contributions don't
normally accompany such rants.

The module being abandoned and unused is truly the only explanation I could
> think of when seeing that glaring bugs have stayed unfixed for 15 years (an
> infinity in IT), in an actively developed and highly used software.
> This may be flattering for my ego, but if the module really is in any
> production use to speak of, then in all these years, with all this
> humongous user base, someone, somewhere in the world, at some point, should
> have looked into this. I don't even program in C professionally, yet was
> able to diagnose it and make a PR!
>
> ​I think the fact that alarm bells haven't clanged is likely a product of
​tkinter's relatively small user base, perhaps amplified by dwindling
availability of "GYU in one thread" lore. Anyway they have certainly
clanged now.

---
>
> I'll make a PR with the doc warning as Guido suggested unless there are
> any better ideas.
>
> ​In the absence of other actions this would be a good first step. Thank
you.
​


> Meanwhile, I'd really appreciate any response to my other message -- it is
> about actually fixing the issue, and I do need feedback to be able to
> proceed.
> No need to delve all the way in and give an official authorization or
> something. I'm only looking for an opinion poll on which redesign option
> (if any) looks like the most reasonable way to proceed and/or in line with
> the big picture (the last one -- to provide a unifying vision -- is _the_
> job of a BDFL IIRC).
>

​I wouldn't presume to tell Guido his job, give

Re: [Python-Dev] Dealing with tone in an email

[Steve Holden]

On Thu, May 3, 2018 at 9:13 PM, Brett Cannon  wrote:

>
>
> On Thu, 3 May 2018 at 12:29 Guido van Rossum  wrote:
>
>> EVENTUALLY WE'LL ALL BE SHOUTING ALL THE TIME. Sad.
>>
>
> Yep. And that leads to burn-out. So while Ivan may have lucked out in
> getting the attention of people who are helped him (and given the wrong
> kind of positive reinforcement that this approach is reasonable), this can
> lead to people quitting open source and not being available to help you
> next time (e.g. notice how it drove Paul Moore over the edge to pull back
> for a week or so and he may have been the expert you needed for packaging
> or me for imports; IOW I would say Ivan was lucky this time and may not be
> so lucky next time).
>
> -Brett
>
>

​Yup. Tolerance has to have its limits, and this came close to abusive
behaviour. ​

​I suspect others among us might have been guilty of similar behaviours in
the past I certainly couldn't cast the first stone), but times change as do
standards, and it's certainly not the tone the majority of the readers of
this list would want, I believe.

Let's hope this message continues to come across loud and clear.

​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] Dealing with tone in an email

[Steve Holden]

Me neither, but I do want people to accept that there are norms, which
should usually be observed.  S

Steve Holden

On Fri, May 4, 2018 at 11:14 AM, Antoine Pitrou  wrote:

> On Fri, 4 May 2018 08:23:19 +0100
> Steve Holden  wrote:
> >
> > ​Yup. Tolerance has to have its limits, and this came close to abusive
> > behaviour. ​
> >
> > ​I suspect others among us might have been guilty of similar behaviours
> in
> > the past I certainly couldn't cast the first stone), but times change as
> do
> > standards, and it's certainly not the tone the majority of the readers of
> > this list would want, I believe.
> >
> > Let's hope this message continues to come across loud and clear.
>
> Since Terry Reedy (the IDLE maintainer) responded and refuted (some
> of?) the OP's assertions, I guess the case is settled.
>
> But that's not the same thing as threatening a poster with some
> accusations of CoC violation, just because the poster happened to use a
> familiar expression.
>
> Personally, I don't want people to be intimidated away from contributing
> because their English expression differs from that of the dominant (or,
> rather, most vocal and/or better organized) fraction.
>
> 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] Dealing with tone in an email (was: Drop/deprecate Tkinter?)

[Steve Holden]

On Fri, May 4, 2018 at 4:43 PM, Steven D'Aprano  wrote:

> On Thu, May 03, 2018 at 06:31:03PM +, Brett Cannon wrote:
>
> > No one is saying people can't be upset and if you are ever upset there's
> > something wrong; we're human beings after all. But those of us speaking
> up
> > about the tone are saying that you can also wait until you're not so
> upset
> > to write an email. This was never going to be resolved in an hour, so
> > waiting an hour until you're in a better place to write an email that
> > wasn't quite so inflammatory seems like a reasonable thing to ask.
>
> Certainly!
>
> I'm not defending Ivan's initial email. His tantrum *was* annoying,
> unreasonable, and unfair to those who do care about tkinter. He could
> have done better.
>
> But *we* should be better too. Our response to Ivan has not been
> welcoming, and as a community we haven't lived up to our own standards,
> as we have piled onto him to express our rightous indignation:
>
> 1. Guido responded telling Ivan to calm down and work off his
>frustration elsewhere. And that's where things should have
>stopped, unless Ivan had persisted in his impoliteness.
>
> 2. Brian upped the ante by bringing the CoC into discussion.
>
> 3. Paul raised it again by describing Ivan's post as "offensive".
>
> 4. And now, Steve H has claimed that Ivan's initial post was
>bordering on "abusive".
>
> We've gone from rightly treating Ivan's post as intemperate and
> impolite, and telling him to chill, to calling his post "offensive", to
> "abusive". (Next, I presume, someone will claim to be traumatised by
> Ivan's email.)
>
> ​I for one hold my hand up, and will simply not respond the next time I am
tempted to respond in this way. I do not wish to enter into discussion on
the semantics of abuse, neither do I want to sidetrack the list from its
intended purpose.

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

[Python-Dev] PEP 554 - strange random boldface

[Steve Holden]

Does anyone know why some lines in the tables of
https://www.python.org/dev/peps/pep-0554/ appear in bold when the markup
doesn't seem to call for it? I can't find a way to stop this, and it's
bugging me!

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] PEP 554 - strange random boldface

[Steve Holden]

It's certainly true that when I split any of those left-hand cells the
bizarre emphasis occurs. Still looking for a workaround.

regards
 Steve

Steve Holden

On Sat, May 12, 2018 at 3:26 PM, Antoine Pitrou  wrote:

> On Sat, 12 May 2018 15:20:11 +0100
> Steve Holden  wrote:
> > Does anyone know why some lines in the tables of
> > https://www.python.org/dev/peps/pep-0554/ appear in bold when the markup
> > doesn't seem to call for it? I can't find a way to stop this, and it's
> > bugging me!
>
> Apparently this may have to do with the given table cells being laid out
> in multiple lines?
>
> 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 554 - strange random boldface

[Steve Holden]

On Sat, May 12, 2018 at 4:57 PM, Serhiy Storchaka 
wrote:

> 12.05.18 17:48, Steve Holden пише:
>
>> It's certainly true that when I split any of those left-hand cells the
>> bizarre emphasis occurs. Still looking for a workaround.
>>
>
> Remove an extra indentation of the second line.
>
>
​That's nailed it, 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/archive%40mail-archive.com

Re: [Python-Dev] [Webmaster] Possible virus in Win32 build of python?

[Steve Holden]

On Thu, May 17, 2018 at 5:26 AM, Ryan Saunders 
wrote:

> Hello webmaster,
>
>
>
> A little over a week ago, I got hit by a rather nasty virus…one of those
> “ransomware” viruses that encrypts everything on your disk and then demands
> bitcoin payment in exchange for the decryption key. Yuck.
>
>
>
> One potential way in which this virus might have gotten onto my system is
> via a version of Python I downloaded, as I was working on a script to
> auto-download Python around that time. It’s a bit difficult to be sure,
> since (a) my antivirus (Windows Defender) didn’t notice the virus at all
> and (b) most files on my HDD are now hopelessly encrypted, including the
> copies of Python I downloaded, which makes postmortem analysis…difficult.
>
>
>
> I plan to do some more investigation to try to determine exactly how I got
> this bug, but I thought it prudent to bring this to your attention quickly,
> just in case Python actually *was* the infection vector, so that you can
> remove any infected files from your download site.
>
>
>
> If I recall correctly, the versions of Python that I was working with were
> the following:
>
>- https://www.python.org/ftp/python/3.7.0/python-3.7.0b4-amd64.exe
>- https://www.python.org/ftp/python/3.7.0/python-3.7.0b4-
>embed-amd64.zip
>- https://www.python.org/ftp/python/3.7.0/python-3.7.0b3-amd64.exe
>- https://www.python.org/ftp/python/3.7.0/python-3.7.0b3-
>embed-amd64.zip
>- https://www.python.org/ftp/python/3.6.5/python-3.6.5-amd64.exe
>- https://www.python.org/ftp/python/3.6.5/python-3.6.5-embed-amd64.zip
>
>
>
> The virus is the “Arrow” virus, which most antivirus sites identify as a
> variant of the “dharma/crysys” family of malware. Unfortunately, Windows
> Defender did not catch it, so I’m not sure what AV tools to recommend. But
> I do suggest scanning the above files with whatever AV tools are at your
> disposal, just to be on the safe side, so that no one else contracts this
> thing.
>
>
>
> If I am later able to determine conclusively the source of my infection, I
> will let you know.
>
>
>
> Ryan
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> ___
> Webmaster mailing list
> webmas...@python.org
> https://mail.python.org/mailman/listinfo/webmaster
>
> Hi Ryan,

Thanks for your note, and I'm sorry to hear that you have fallen victim to
malware.

I suspect the probability of a virus in the official installer
distributions is very low. I understand that the release process for
Windows does involve anti-virus scans, and I am not personally aware of
even any false positives on 3.6.

Since 3.7.0 is a pre-release I am notifying the developers list as a
precaution. You will hear from them if they require any further information.

Good luck restoring your system.

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] Normalisation of unicode and keywords

[Steve Holden]

It's a canonicalisation error.

Steve Holden

On Fri, May 18, 2018 at 2:38 PM, Ivan Pozdeev via Python-Dev <
python-dev@python.org> wrote:

> On 18.05.2018 14:46, Steven D'Aprano wrote:
>
>> Stephan Houben noticed that Python apparently allows identifiers to be
>> keywords, if you use Unicode "mathematical bold" letters. His
>> explanation is that the identifier is normalised, but not until after
>> keywords are checked for. So this works:
>>
>> class Spam:
>>  locals()['if'] = 1
>>
>>
>> Spam.𝐢𝐟# U+1D422 U+1D41F
>> # returns 1
>>
>>
>> Of course Spam.if fails with SyntaxError.
>>
>> Should this work? Is this a bug, a feature, or an accident of
>> implementation we can ignore?
>>
> Voting for bug:
> Either those identifiers should be considered equal, or they shouldn't.
> They can't be considered "partially" equal.
>
>>
>>
>>
> --
> Regards,
> Ivan
>
>
> ___
> 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] A more flexible task creation

[Steve Holden]

On Thu, Jun 14, 2018 at 8:14 PM, Chris Barker via Python-Dev <
python-dev@python.org> wrote:

> Excuse my ignorance (or maybe it's a vocabulary thing), but I'm trying to
> understand the problem here.
>


> So why do queries fail with 1 tasks? or ANY number? If the async DB
> access code is written right, a given query should not "await" unless it is
> in a safe state to do so.
>
> So what am I missing here???
>
> because threads ARE concurrent, and there is no advantage to having more
>> threads than can actually run at once, and having many more does cause
>> thread-switching performance issues.
>>
>
> To me, tasks are (somewhat) logically analogous to threads.
>>
>
> kinda -- in the sense that they are run (and completed) in arbitrary
> order, But they are different, and that difference is key to this issue.
>
> As Yury expressed interest in this idea, there must be something I'm
> missing.
>
> What is it?
>

All tasks need resources, and bookkeeping for such tasks is likely to slow
things down. More importantly, with an uncontrolled number of tasks you can
require an uncontrolled use of resources, decreasing efficiency to levels
well below that attainable with sensible conservation of resources.
Imagine, if you will, a task that starts by allocating 1GB of memory. Would
you want 10,000 of those?
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Steve Holden]

On Mon, Jun 25, 2018 at 8:37 PM, Terry Reedy  wrote:

> On 6/24/2018 7:25 PM, Guido van Rossum wrote:
>
>> I'd wager that the people who might be most horrified about it
>>
>
> the (b) scoping rule change
>
> would be people who feel strongly that the change to the
>> comprehension scope rules in Python 3 is a big improvement,
>>
>
> I might not be one of those 'most horrified' by (b), but I increasingly
> don't like it, and I was at best -0 on the comprehension scope change. To
> me, iteration variable assignment in the current scope is a non-problem.
> So to me the change was mostly useless churn.  Little benefit, little
> harm.  And not worth fighting when others saw a benefit.
>
> However, having made the change to nested scopes, I think we should stick
> with them.  Or repeal them.  (I believe there is another way to isolate
> iteration names -- see  below).  To me, (b) amounts to half repealing the
> nested scope change, making comprehensions half-fowl, half-fish chimeras.
>
​[...]​


> --
> Terry Jan Reedy
>
> ​I'd like to ask: how many readers of ​

​this email have ever deliberately taken advantage of the limited Python 3
scope in comprehensions and generator expressions to use what would
otherwise be a conflicting local variable name?​

I appreciate that the scope limitation can sidestep accidental naming
errors, which is a good thing.

Unfortunately, unless we anticipate Python 4 (or whatever) also making for
loops have an implicit scope, I am left wondering whether it's not too
large a price to pay. After all, special cases aren't special enough to
break the rules, and unless the language is headed towards implicit scope
for all uses of "for" one could argue that the scope limitation is a
special case too far. It certainly threatens to be yet another confusion
for learners, and while that isn't the only consideration, it should be
given due weight.
___
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] ZIP File Instead of Installer

[Steve Holden]

Hi Alex,

Thanks for your email, and the suggestion. A couple of things …

First, as webmaster we are simply volunteers who try to accept and process 
feedback *about the python.org <http://python.org/> web site*. We aren’t 
(mostly) actively involved in the development of the language, though we are 
all dedicated users - most of us either don’t have tie to take part in 
python-dev or feel we have already put our time in. So this isn’t the best 
channel for the particular inout you’re making.

Second, while it’s practical to put *most* of the stdlib in a zip file it may 
be impractical to put them *all* in there. I did some experiments (admittedly 
about eight years ago, so things may have changed) to enable an import 
mechanism that imported code from a relational database. Naturally there were 
modules that had to be loaded using the standard mechanisms - the ones I needed 
to import to enable my database imports! It’s a classical bootstrap problem.

Third, your idea would need considerable expansion before being actionable: 
consider the fact that there are millions of downloads of Python every month. 
Obviously there is huge amount of engineering detail to consider before 
releasing anything new - if an error only occurs one time in 100,000 that will 
lead to a substantial number of bug reports, so the dev tend to proceed fairly 
carefully and with much deliberation.

Fourth, I really like it that you are enthusiastic about Python, and would 
suggest you consider joining the python-dev mailing list. Start as a lurker, 
just reading what is said, and (since you are obviously thinking a lot as you 
learn Python) you will be surprised how much you pick up. The people on that 
list aren’t gods, they are just regular developers who happen to commit a lot 
of their time to Python’s development, and they rely on a continuous influx of 
new blood. So as long as you take your time getting to know the personalities 
involved and how the list works you are likely to find a welcome there. The day 
will arrive when you realize that rather to your surprise you have something to 
contribute.

There’s also the python-ideas list and, if you are nervous about just diving 
straight into python-dev, there’s the python-mentor list that was specifically 
designed to provide a sympathetic and uncritical response to enthusiasm such as 
you exhibit.

The caveat in all this is that as an old fart I haven’t actually been active on 
any of those lists for quite a while, so I am unsure how active they all are.

I hope this response is helpful. I’ve invested a lot of time in trying to make 
the Python ecosystem one that welcomes enthusiasm and energy, and lot of other 
people do the same, many of them more effectively than me. It seems to me that 
you have both enthusiasm and energy, which is why I’ve taken the time to 
encourage you to put it to use.

Good luck in your progress with Python.

regards
 Steve

PS: The mailing lists are all detailed on 
https://mail.python.org/mailman/listinfo 
<https://mail.python.org/mailman/listinfo>

> On Aug 31, 2015, at 9:48 PM, Alex Huffstetler  wrote:
> 
> I have an idea. I had a problem with installing Python because I’m not an 
> admin.
> My idea is you delete the installer and put all the files in a ZIP folder. It 
> can make download time faster.
> Also, I made the Python logo out off underscores and pipes.
> If it dosen’t look right, put it somewhere on the Internet and it’ll look 
> right.
>   _
>  | . |
> ___|___   |
> ||   |
> | _|   |
> ||   |
> |___|___|
>  |         . |
>  |_|

-- 
Steve Holden st...@holdenweb.com / +44 208 289 6308 / @holdenweb





___
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] [Webmaster] Python keeps installing as 32 bit

[Steve Holden]

Hi Robb,

This address is really for web site issues, but we are mostly old hands,
and reasonably well-connected, so we try to act as a helpful channel when
we can.

In this case I can't personally help (though another webmaster may, if
available, be able to offer advice). I stopped doing system administration
for anything but my own machines a long time ago, having done far too much
:-)

The many mailing list channels available are listed at
https://mail.python.org/mailman/listinfo. I would recommend that you try
the distutils list at https://mail.python.org/mailman/listinfo/distutils-sig;
they don't actually build the Python installers (the dev who does that
lives on python-dev, so that would be the place to go to get the scoop, and
your email shows enough signs of competence that you need not fear adverse
reactions). It seems like a reasonable enquiry to me, and I'm sorry I can't
answer it.

I've Cc'd this email to python-dev on the off-chance that someone will
recognise my name and let it through, but I don't know how many people are
working on the Windows installer or how busy they are.

There are plenty of people smart enough to answer your question out there
now, it's just a question of finding them. stackoverflow.com has a pretty
good Python channel too.

In any case, good luck, and thanks for reaching out to Python.

regards
 Steve

On Wed, Dec 16, 2015 at 7:29 PM, Mullins, Robb 
wrote:

> Hi,
>
>
>
> Not quite sure where to ask this.
>
>
>
> I don’t use Python myself.  I keep user desktops updated.  Everything’s
> 64-bit.  In the past I was able to install 32-bit Python on 32-bit machines
> and 64-bit Python on 64-bit machines.  Now it’s just the one msi file to
> install, at least for 3.5.1.  I do have a couple Python 2.7.9 users.
> We’re all 64-bit for machines, but I keep having Python install as 32-bit.
> I’m not sure if it recognizes something on the machine and matches it for
> being 32-bit that I’m not aware of.  It can be tricky to uninstall, so it
> becomes a slight issue.  I just want to get 64-bit Python on my user
> machines, unless it’s not possible.
>
>
>
> Is there a better place to ask this?
>
>
>
>
>
> Thanks,
>
> RM
>
>
>
> Desktop Support Specialist
>
> Center for Innovation in Teaching & Learning
>
> citl-techsupp...@mx.uillinois.edu *(For computer issues, please use the
> ticket system.)*
>
> (217) 333-2146
>
>
>
> ___
> Webmaster mailing list
> webmas...@python.org
> https://mail.python.org/mailman/listinfo/webmaster
>
>
___
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] [Webmaster] Python installation problem

[Steve Holden]

Hi Sumit,

We get a lot of these inquiries. Yes, you can generally assume that Python
will be available for the current versions of Linux, Windows and MacOS
because the developers generally use those platforms for development work.
It is certainly fine on Windows 10, so you should have no problems. You
might find
https://www.londonappdeveloper.com/setting-up-your-windows-10-system-for-python-development-pydev-eclipse-python/
helpful in setting up your environment.

I have forwarded this query to the developers list, as I noticed that the
Windows releases page (https://www.python.org/downloads/windows/) tells the
reader a lot about what's available for Windows but doesn't mention which
versions of Windows are supported. I won't guarantee the developers will
have time to reply, but at least they know that this would be useful
information.

Thanks for your interest in Python. Clicking the links for the latest
downloads on the home page of python.org is the traditional way to get
started. Good luck!

regards
 Steve

Steve Holden

On Sat, Mar 12, 2016 at 2:34 PM, Sumit Mandal 
wrote:

> Sir/Mam
>
>
>
> I wanted to know if python runs on windows 10 or not and if it does how
> can I install it and get it running?
>
>
>
> Thanking you
>
> Yours sincerely
>
> Sumit Mandal
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> ___
> Webmaster mailing list
> webmas...@python.org
> https://mail.python.org/mailman/listinfo/webmaster
>
>
___
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 0404 and VS 2010

[Steve Holden]

Christian Tismer  stackless.com> writes:

> 
> Howdy friends,
> 
> according to pep 404, there will never be an official Python 2.8.
> The migration path is from 2.7 to 3.x.
> 
[...]
> And if not, what do you suggest then?

Stackless Python 2.799

> It will be submitted by end of November, thanks for your quick responses!
> 
Oops, too quick!

> all the best -- Chris
> 

And to you.

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] A "day of silence" on PEP 572?

[Steve Holden]

On Sat, Jul 7, 2018 at 12:18 AM, Ryan Gonzalez  wrote:

> On July 6, 2018 5:04:05 PM Antoine Pitrou  wrote:
>
>
>> (or contact the PEP's authors
>> privately).
>>
>>
> Hoenstly, this feels like a recipe for a disaster...
>
> ​Many of the people who have strong opinions in this know the PEP authors
from years of working together.​

​They might feel that personal channels are appropriate.​ I'd agree it
would be a bit presumptuous and spammy of others to use them.
___
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

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

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

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] 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] 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] 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] 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] 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] 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] 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 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] 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]

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: 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]

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

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

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