Re: [Python-Dev] Consolidating channel of record [was: 581 (Using GitHub issues for CPython) is accepted]

[Chris Barker - NOAA Federal via Python-Dev]

Frankly, multiple long meandering threads in s single mailing list are
not s very good archive either.

Ideally, the PEP is updated with a summary of the issues discussed as
the discussion unfolds.

(And links to the main discussion threads?)

It founds like that didn’t happen in this case, but it’s not
necessarily too late.

As the community seems to be moving to a wider variety of fora, this
will become all the more critical.

- CHB

> On May 15, 2019, at 1:09 PM, Stephen J. Turnbull 
>  wrote:
>
> Stripping the list of addressees, since I'm pretty sure all the
> people who will *make* the decision read Python-Dev regularly, except
> perhaps Carol.
>
> Paul Moore writes:
>
>> Thanks for all of these. I appreciate the time you took locating them
>> for me. But I do have to say that I still can't really follow any
>> useful "thread of discussion" - it all seems very fragmented, and it's
>> difficult to see the progress towards consensus. Maybe that's just
>> because I'm too used to mailing lists :-)
>
> Please, let's not start by privileging any particular type of channel
> in this discussion.  I know what I like, but it's far more important
> to have a single place to refer to past discussion IMO.  It's bad
> enough with python-ideas and python-dev.
>
> Maybe this fragmentation is OK in the long run, but at least while the
> Steering Council is shaking down (say, until release of 3.9?), the
> Council should consider anointing two archived "channels of record",
> one for private deliberations of the Council itself (for the sake of
> future members), and one for PEP discussions.
>
> Of course if the SC chooses Discourse for the PEP channel, people
> *will* discuss PEPs on Python-Dev and IRL.  The point is "no fair
> pointing people to *other* channels for reference".  If you want to
> make a public argument, make it in the proper place.  Everything else
> is effectively private.  If you want to refer to that in the public
> discussion, read it into the public record.
>
> The stricture for the Council deliberation channel is different, since
> I expect the archives would be private to Council members: if you came
> into this discussion in the middle, what conversations would you want
> to be able to review?
>
> While I'm here, is there a place where general Pythonistas can bring
> matters to the attention of the Council?
>
> 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/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP-582 and multiple Python installations

[Chris Barker - NOAA Federal via Python-Dev]

> I'd like to raise a potential edge case that might be a problem, and likely 
> an increasingly common one: users with multiple installations of the *same* 
> version of Python.

I would suggest that that use case is best addressed by a system that
isolates the entire python environment, such as conda.

> This is actually a common setup for Windows users who use WSL, Microsoft's 
> Linux-on-Windows solution, as you could have both the Windows and Linux 
> builds of a given Python version installed on the same machine.

Sure, but Isn’t the WSL subsystem pretty isolated already? Would
native Windows and WSL users be running in the same dir?

That being said, I’m pretty skeptical of the PEP — I understand the
motivation — I make a point of avoiding virtual environments in my
intro classes, but at some point folks will need to learn them.

I’ve had students think that virtualenv was a part of (or required by)
e.g. flask, because the tutorials include it in the setup.

But I think environments really need to be more distinct, not less,
I’m quite concerned about mingling them in one place.

Maybe I’m reading it wrong, but it seems that this could create
serious clashes with other “environment” systems, such as conda.

I suppose one could say: “don’t do that” — I.e. don’t create a
__pypackages__ dir if you are going to use conda — but many folks want
the same source to be runnable in multiple “styles” of Python.

Also, I see a major benefit for teaching,  but it does go a bit
against my philosophy of not hiding important details from newbies —
that is, don’t teach using an approach that is not suitable for
production.

And newbies could be really confused by the fact that pip installs
stuff differently depending on what dir they are in and what is in
that dir.

The PEP is listed as a draft — anyone know what’s going on with it?

-CHB
___
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] Another update for PEP 394 -- The "python" Command on Unix-Like Systems

[Chris Barker - NOAA Federal via Python-Dev]

> On Feb 13, 2019, at 9:13 AM, Steve Dower 
>
> I'm inclined to view "python" as the default, official command, with the 
> versioned ones being workarounds added by distributors.

+1 — almost. I agree that “python” be the default, but it would be
good to require (or at least highly encourage) that there be a
“python3” as well.

There will be folks wanting to run python3 on systems where there is
still a “python” pointing to py2 — particularly since that is still
the “correct” way to do it!

> (And maybe this isn't currently how things are done, but I'd rather hold up 
> an ideal than pretend that the status quo can't be changed -

Exactly.

-CHB


> this list is literally for discussing changing the status quo of anything in 
> core Python ;) )
>
> Cheers,
> 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/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Add more SyntaxWarnings?

[Chris Barker - NOAA Federal via Python-Dev]

> But as a rule,
>> there are a LOT of errors that can be pretty mysterious to newbies.
>
> Isn't that the very definition of "newbie"?  That's half a joke, but I
> really don't think that programmers new to Python should be the
> standard.

Python is broadly advocated (and used) as a first language to learn.
Because it is.

So I think anything we can do to help newbies, *that doesn’t make the
language less powerful, or even more annoying for experienced
developers* is a good thing.

That is: prioritizing newbie-friendliness is good. Prioritizing it
over other important things is not.

-CHB



> The problematic cases are those where even a relatively
> experienced Python programmer needs to be told why an error is raised,
> because it's too hard to figure out from background knowledge of the
> language, you need to know about implementation internals.
>
>> I would love to see Python become generally more informative with
>> errors.
>
> I would love to see all automated systems become more informative with
> errors!  One thing I like about Python the development community is
> that people are doing something about it.  Slowly but surely 
>
>> I don’t think so — what we need are helpful error messages. If it
>> will be raised at compile time, then it won’t generally be
>> catchable in s try-except— so the actual exception type isn’t very
>> important.
>
> +1
>
> In general depending much on exception type is a hit-or-miss affair.
___
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] Add more SyntaxWarnings?

[Chris Barker - NOAA Federal via Python-Dev]

>. There's nothing mysterious about e.g. `TypeError: unsupported operand
type(s) for +: 'int' and 'str'`, unlike the case of the two concatenated
tuples. (Surely people get errors about int+str all the time, and they've
never complained -- unlike the tuple tuple case.)

Well, yes, that particular example is pretty clear. But as a rule, there
are a LOT of errors that can be pretty mysterious to newbies.

I would love to see Python become generally more informative with errors.

In this case, you’d probably get a similar error, but it’s still nice to
get it sooner, and if the hooks are in place, We could have others that are
really helpful.

-CHB


Is there value in distinguishing
> "InevitableTypeError" from "InevitableAttributeError"?
>

I don’t think so — what we need are helpful error messages. If it will be
raised at compile time, then it won’t generally be catchable in s
try-except— so the actual exception type isn’t very important.

-CHB
___
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] Sub-interpreters: importing numpy causes hang

[Chris Barker - NOAA Federal via Python-Dev]

If your primary concern is module clashes between plugins, maybe you
can hack around that:

1) if the plugins are providing copies of any other modules, then you
can simply require them to put them in their own namespace — that is,
a plug-in is a single package, with however many sub modules as it may
need.

2) if plugins might require third party packages that need to be
isolated, then maybe you could use an import hook that
re-names/isolates the modules each plugin loads, so they are kept
separate.

I haven’t thought through how to do any of this, but in principle, you
can have the same module loaded twice if it has a different name.


Not that sub interpreters aren’t cool and useful, but you can probably
handle module clashes in a simpler way.

-CHB



Sent from my iPhone

> On Jan 23, 2019, at 11:41 AM, Stephan Reiter  wrote:
>
> You all do make me feel very welcome in this community! Thank you very much! 
> :-)
>
> And thank you for all the thought and time you put into your message,
> Eric. I do appreciate in particular all the alternatives you
> presented; you provide a good picture of my options.
> Not ruling out any of them, I'll stick with (single process + multiple
> subinterpreters + plugins can't keep state in Python + all my Python
> calls are performed on the main thread) for the time being. That's
> quite a limited environment, which I hope I can make work in the long
> run. And I think the concept of subinterpreters is nice and I'd like
> to spend some time on the challenge of improving the situation.
>
> So, I updated my changes and have the following on top of 3.6.1 at the moment:
> https://github.com/stephanreiter/cpython/commit/c1afa0c8cdfab862f409f1c7ff02b189f5191cbe
>
> I did what Henry suggested and ran the Python test suite. On Windows,
> with my changes I get as output:
>
> 357 tests OK.
>
> 2 tests failed:
>   test_re test_subprocess
>
> 46 tests skipped:
>   test_bz2 test_crypt test_curses test_dbm_gnu test_dbm_ndbm
>   test_devpoll test_epoll test_fcntl test_fork1 test_gdb test_grp
>   test_idle test_ioctl test_kqueue test_lzma test_nis test_openpty
>   test_ossaudiodev test_pipes test_poll test_posix test_pty test_pwd
>   test_readline test_resource test_smtpnet test_socketserver
>   test_spwd test_sqlite test_ssl test_syslog test_tcl
>   test_threadsignals test_timeout test_tix test_tk test_ttk_guionly
>   test_ttk_textonly test_turtle test_urllib2net test_urllibnet
>   test_wait3 test_wait4 test_winsound test_xmlrpc_net test_zipfile64
>
> Total duration: 6 min 20 sec
> Tests result: FAILURE
>
> I dropped my changes and ran the test suite again using vanilla Python
> and got the same result.
> So, it seems that the change doesn't break anything that is tested,
> but that probably doesn't mean a lot.
>
> Tomorrow, I'll investigate the following situation if I find time:
>
> If we create a fresh OS thread and make it call PyGILState_Ensure, it
> won't have a PyThreadState saved under autoTLSkey. That means it will
> create one using the main interpreter. I, as the developer embedding
> Python into my application and using multiple interpreters, have no
> control here. Maybe I know that under current conditions a certain
> other interpreter should be used.
>
> I'll try to provoke this situation and then introduce a callback from
> Python into my application that will allow me to specify which
> interpreter should be used, e.g. code as follows:
>
> PyInterpreter *pickAnInterpreter() {
> return activePlugin ? activePlugin->interpreter : nullptr; //
> nullptr maps to main interpreter
> }
>
> PyGILState_SetNewThreadInterpreterSelectionCallback();
>
> Maybe rubbish. But I think a valuable experiment that will give me a
> better understanding.
>
> Stephan
>
> Am Mi., 23. Jan. 2019 um 18:11 Uhr schrieb Eric Snow
> :
>>
>> Hi Stephan,
>>
>>> On Tue, Jan 22, 2019 at 9:25 AM Stephan Reiter  
>>> wrote:
>>> I am new to the list and arriving with a concrete problem that I'd
>>> like to fix myself.
>>
>> That is great!  Statements like that are a good way to get folks
>> interested in your success. :)
>>
>>> I am embedding Python (3.6) into my C++ application and I would like
>>> to run Python scripts isolated from each other using sub-interpreters.
>>> I am not using threads; everything is supposed to run in the
>>> application's main thread.
>>
>> FYI, running multiple interpreters in the same (e.g. main) thread
>> isn't as well thought out as running them in separate threads.  There
>> may be assumptions in the runtime that would cause crashes or
>> inconsistency in the runtime, so be vigilant.  Is there a reason not
>> to run the subinterpreters in separate threads?
>>
>> Regarding isolation, keep in mind that there are some limitations.  At
>> an intrinsic level subinterpreters are never truly isolated since they
>> run in the same process.  This matters if you have concerns about
>> security (which you should always consider) and stability (if a
>> subinterpreter crashes then your 

Re: [Python-Dev] 3.7.2rc1 and 3.6.8rc1 cutoffs ahead, last 3.6.x bugfix release!

[Chris Barker - NOAA Federal via Python-Dev]

I’m all for extending the life of 3.6, it sure feels recent to me!

> 3.6 is the default Python in Ubuntu 18.04 LTS and RHEL 8. And due to several 
> important syntax features it can be a minimal required version for long time.

Which is a good argument for why we may not need longer term support
for 3.5, but minimum requirement doesn’t mean we need to support it
longer term, as the alternative is to upgrade to 3.7 — and most code
that works on 3.6 will work on 3.7, yes?

That is — if you want recent bug fixes, upgrade your Python.

If you have a working 3.6 based system, you only need security fixes, yes?

I fully understand the need to keep a working older system up to date
with security fixes, but I’ve always been confused by the desire to
run an older base system, while still requiring newer subsystems,
whether that’s an older Linux with a newer python, or and older python
with a newer package.

-CHB






>
> I merged several PRs before releasing 3.6.8rc1, but there are still less 
> trivial bugfix PRs which need more time for reviewing, and there are bugs for 
> which no PR is created yet. There is also a number of documentation PRs. I 
> propose to allow backporting bugfixes to 3.6 if they do not need excessive 
> work, but stop to fix 3.6 only bugs. After migrating to GitHab, backporting 
> became less painful, most of backports to 3.6 can be done automatically from 
> master or from 3.7.
>
> ___
> 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/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Arbitrary non-identifier string keys when using **kwargs

[Chris Barker - NOAA Federal via Python-Dev]

> On the server side, the application could be doing something like
> assuming that the kwargs are e.g. column names

This is exactly a use-case for non-identifier strings in kwargs. The
rules for valid field names could very well be different than Python’s
rules.

The kwargs implementation is not the place for sanitizing to take
place — each app will need different sanitization rules.

-CHB
___
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] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

[Chris Barker - NOAA Federal via Python-Dev]

TL;DR-

+1 on advocating the term “generator comprehension” as a synonym for
“generator expression” in future documentation and instructional
materials.

The long version:

If we were starting from scratch, maybe it would makes sense to use “
builder” or something else, rather than comprehension. But we’re  not
starting from scratch.

And “list comprehension” has become a pretty universal (or at least
common) term in the python world. So we really can’t expect to re-name
that.

And despite the term having its roots in an esoteric corner of
mathematics, I’ve never seen anyone confused by it — it’s just a new
word for a new thing to most folks.

Which is actually why “generator expression” is a bit confusing — it
seems to have more in common with comprehensions than with generators

(As in: the things functions with a yield in them produce)

In fact, the term “generator” is a bit confusing itself — due to it
being a common English word, it seems to refer to the generic idea of
“a thing that generates values on the fly”, which, of course it can be
in Python. But it actually is a specific type. And you can make a
“thing that generates values in the fly” with a regular class that
follows the iterator protocol.

So re-using the word in “generator expression” just adds a bit to the
confusion. (Even though it’s technically correct, it does “make” an
actual generator object, doesn’t it? (On a phone, so I can’t check)
but that’s kind of an implementation detail.

Also: if you google: “python list comprehension” you get a LOT of hits
to tutorials, etc.

So it is WAY too late to change that name.

When you google “python generator expression” the top hit is the
python docs, and the next few are about comparing generator
expressions and list comprehensions.

So I think we could start a new naming scheme for those.

 ‘cause then we’d get lost of questions about the difference between
generator expressions and generator comprehensions ;-)


-CHB
___
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] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

[Chris Barker - NOAA Federal via Python-Dev]

Are we just having fun here?

Or might we actually start using a new naming convention for
the-syntax-formerly-known-as-generator-expressions?

-CHB

Sent from my iPhone

> On Jul 3, 2018, at 11:54 PM, Greg Ewing  wrote:
>
> Steven D'Aprano wrote:
>> - list builder syntax is syntax which returns a list;
>> - dict builder syntax is syntax which returns a dict;
>> - set builder syntax is syntax which returns a set;
>> - generator builder syntax is syntax which returns a generator.
>
> You only get a list/dict/set from the first three after
> you've run the iterators within it, but with a generator
> expression, you already have a generator before you've
> run it. That makes it feel different to me.
>
> --
> Greg
> ___
> 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/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Barker - NOAA Federal via Python-Dev]

> On Jul 2, 2018, at 8:34 AM, Steven D'Aprano  wrote:

Guido has decided — and despite my concerns, I’m going to enjoy my new
loop-and-a half construct:-)

But a comment on this:

> comprehension are no more special than
> assignments inside any other expression. They bind in the current scope,
> same as always, and keep the sensible identity that these two
> expressions are exactly equivalent in their visible semantics:
>
>   [x:=0, x:=1, x:=2]
>
>   [x:=i for i in (0, 1, 2)]
>
> including assignments.

Sure — and I don’t think that’s confusing.

However, generator expressions ( why don’t we call them generator
comprehensions?) are a different story, as they may be run at some
arbitrary time in the future. This hasn’t been an issue (except for
the loop variable, which has been addressed) because:

1) Much of the time, the gen_ex is run right away, in-line.

2) There aren’t many ways to manipulate the local namespace in a gen_ex.

With assignment expressions, it will be much easier to manipulate the
local namespace, so there is room for some real confusion here.

So a real local namespace gen_exp (and comprehensions, for
consistency) would be nice.

However, that ship has pretty much sailed.

Will it end up being a common problem? Probably not, because (a) is
still the case, and := will be used infrequently, and hopefully with
unlikely to clash names.

And as for all the other languages that have assignment expressions?
Do they have constructs like generator expressions?

-CHB
___
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)

[Chris Barker - NOAA Federal via Python-Dev]

> On Jun 28, 2018, at 8:21 PM, Tim Peters  wrote:

Seems it’s all been said, and Tim’s latest response made an excellent
case for consistency.

But:

> Regardless of how assignment expressions work in listcomps and genexps, this 
> example (which uses neither) _will_ rebind the containing block's `x`:
>
> [x := 1]

This reinforces my point that it’s not just about comprehensions, but
rather that the local namespace can be altered anywhere an expression
is used  — which is everywhere.

That trivial example is unsurprising, but as soon as your line of code
gets a bit longer, it could be far more hidden.

I’m not saying it’s not worth it, but it a more significant
complication than simply adding a new feature like augmented
assignment or terniary expressions, where the effect is seen only
where it is used.

A key problem with thinking about this is that we can scan existing
code to find places where this would improve the code, and decide if
those use-cases would cause confusion.

But we really can’t anticipate all the places where it might get used
(perhaps inappropriately) that would cause confusion. We can hope that
people won’t tend to do that, but who knows?

Example: in a function argument:

result = call_a_func(arg1, arg2, kwarg1=x, kwarg2=x:=2*y)

Sure, there are always ways to write bad code, and most people
wouldn’t do that, but someone, somewhere, that thinks shorter code is
better code might well do it. Or something like it.

After all, expressions can be virtually anywhere in your code.

Is this a real risk? Maybe not, but it is a complication.

-CHB
___
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)

[Chris Barker - NOAA Federal via Python-Dev]

Sent from my iPhone

> > So what about:
> >
> > l = [x:=i for i in range(3)]
> >
> > vs
> >
> > g = (x:=i for i in range(3))
> >
> > Is there any way to keep these consistent if the "x" is in the regular 
> > local scope?
>
> I'm not clear on what the question is.  The list comprehension would bind ` l 
> ` to [0, 1, 2] and leave the local `x` bound to 2.  The second example binds 
> `g` to a generator object, which just sits there unexecuted.  That has 
> nothing to do with the PEP, though.
>
> If you go on to do, e.g.,
>
> l = list(g)
>
> then, same as the listcomp, `l` will be bound to [0, 1, 2] and the local `x` 
> will be left bound to 2.

OK, it has been said that the priority is that

list(a_gen_expression)

Behave the same as

[the_same_expression]

So we’re good there. And maybe it’s  correct that leaving the running
of the gen_exp ‘till later is pretty uncommon, particularly for
newbies, but:

If the execution of the gen_exp is put off, it really confuses things
— that name being changed would happen at some arbitrary tone, and at
least in theory, the gen_exp could be passed off to somewhere else in
the code, and be run or not run completely remotely from where the
name is used.

So while this is technically the same as the comprehension, it is not
the same as a generator function which does get its own scope.

And we should be clear how it will work — after all, in py2, the
handling of the looping name was handled differently in gen_exp vs
comprehensions.

So I think a local scope for all comprehension-like things would be
the way to go.

But getting back to the original thread topic — python has a number of
places that you can only use expressions — adding the ability to bind
a name in all these places complicates the language significantly.

>   Put a body B in a listcomp and any side effects due to executing B

Maybe it’s just me, but re-binding a name seems like a whole new
category of side effect.

-CHB
___
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] Microsoft to acquire GitHub for $7.5 b

[Chris Barker - NOAA Federal via Python-Dev]

>  We shouldn't be uniquely or especially concerned just because
> Microsoft has purchased Github. Nothing has changed.

Exactly — but this change HAS made people think about an issue that we
should have already been thinking about.

At the end of the day, anyone, or any project, would be well served by
having a plan for potential loss of valuable data.

And the no brainer on that is : don’t have only one copy in one place.

That’s why my family photos are on my hard drive, and a backup drive,
and an online backup service.

My house could burn down, so I don’t want everything there. The backup
service could change its conditions, go out of business, or simply
have a technical failure — so I don’t want everything there, either.

Any service could change or fail. Period.

So we shouldn’t want valuable information about Python development
only in gitHub.

I don’t know how hard it is to backup / mirror an entire repo — but it
sure seems like a good idea.

-CHB
___
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] Docstrings on builtins

[Chris Barker - NOAA Federal via Python-Dev]

>
> This may even be a bug/feature of IPython,

Ahh, thanks! I’ll look into that.

-CHB
___
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] (Looking for) A Retrospective on the Move to Python 3

[Chris Barker - NOAA Federal via Python-Dev]

> between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it
>> easier to write py2/py3 compatible code.
>> u"string", b'bytes %i' % something -- and when where the various
>> __future__ imports made available?
>>
>
> You'll need to be more specific.  __future__ has been around for a
> long time.


I meant the various ones that support py2/3 compatibility — I know division
predates py3, not sure about the others.

But it was a rhetorical question anyway :-)
-CHB



https://github.com/python/cpython/blame/master/Lib/__future__.py


>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/wes.
> turner%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

[Chris Barker - NOAA Federal via Python-Dev]

> while the changes introduced by Python 3
> affect pretty much everyone, even people who only write small simple
> scripts.

Sure they do, but the *hard stuff* not so much.

I have found 2to3 conversion to be remarkably easy and painless.

And the whole Unicode thing is much easier.

CHB


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

Re: [Python-Dev] Python startup time

[Chris Barker - NOAA Federal via Python-Dev]

Inspired by chg:

Could one make a little startup utility that, when invoked the first
time, starts up a raw python interpreter, keeps it running somewhere,
and then forks it to run the actual python code.

Then every invocation after that would make a new fork. I presume
forking is a LOT faster than re-invoking the entire startup.

I suspect that many of the cases where startup time really matters is
when a command line utility is likely to be invoked many times — often
in the same shell instance.

So having a “pre-built” warm interpreter ready to go could really help.

This is way past my technical expertise to know if it’s possible, or
to try to prototype it, but I’m sure many of you would know.

-CHB

Sent from my iPhone

> On May 7, 2018, at 12:28 PM, Neil Schemenauer  wrote:
>
> On 2018-05-03, Lukasz Langa wrote:
>>> On May 2, 2018, at 8:57 PM, INADA Naoki  wrote:
>>> * Add lazy compiling API or flag in `re` module.  The pattern is compiled
>>> when first used.
>>
>> How about go the other way and allow compiling at Python
>> *compile*-time? That would actually make things faster instead of
>> just moving the time spent around.
>
> Lisp has a special form 'eval-when'.  It can be used to cause
> evaluation of the body expression at compile time.
>
> In Carl's "A fast startup patch" post, he talks about getting rid of
> the unmarshal step and storing objects in the heap segment of the
> executable.  Those would be the objects necessary to evaluate code.
> The marshal module has a limited number of types that it handle.
> I believe they are: bool, bytes, code objects, complex, Ellipsis
> float, frozenset, int, None, tuple and str.
>
> If the same mechanism could handle more types, rather than storing
> the code to be evaluated, we could store the objects created after
> evaluation of the top-level module body.  Or, have a mechanism to
> mark which code should be evaluated at compile time (much like the
> eval-when form).
>
> For the re.compile example, the compiled regex could be what is
> stored after compiling the Python module (i.e. the re.compile gets
> run at compile time).  The objects created by re.compile (e.g.
> SRE_Pattern) would have to be something that the heap dumper could
> handle.
>
> Traditionally, Python has had the model "there is only runtime".
> So, starting to do things at compile time complicates that model.
>
> 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/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com