On Sep 7, 2017, at 18:03, Fernando Perez wrote:
> Ah, perfect! I've subscribed to the PR on github and can pitch in there
> further if my input is of any use.
Awesome, thanks!
-Barry
signature.asc
Description: Message signed w
ive.
You better watch out Nick. You’re starting to sway me on adding the
environment variable.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
I couldn’t resist one more PEP from the Core sprint. I won’t reveal where or
how this one came to me.
-Barry
PEP: 559
Title: Built-in noop()
Author: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2017-09-08
Python-Version: 3.7
Post-History: 2017-09-09
then! (Yes, it was serious, but I claim post-sprint
euphoria/delirium).
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
sys.breakpointhook() with something else, then oh well, Python just ignores
$PYTHONBREAKPOINT.
Feedback welcome.
-Barry
[*] Probably not $PYTHONBREAKPOINTHOOK although if we choose to implement that
in sys.breakpointhook(), it might still makes sense.
signature.asc
Description: Message signed
ibly conflict with normal usage.
I have working code for `PYTHONBREAKPOINT=0` and `PYTHONBREAKPOINT= ` (i.e. the
empty string as given by getenv()) meaning “disable”. I don’t think we also
need `PYTHONBREAKPOINT=pass`.
Cheers,
-Barry
signature.asc
Descr
re.none
unordered = Compare.unordered
ordered = Compare.ordered
——dataclasses/__init__.py-
from dataclasses import dataclass, unordered
@dataclass(compare=unordered)
class Foo:
# …
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
P
ot;unordered"; better to say what they are rather than what they are
> not.
The language reference calls them “equality” comparisons, so maybe that’s the
term we should use.
-Barry
signature.asc
Description: Message signed with OpenPGP
_
sed ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Guido, I’ll implement it this way in my PR and update the PEP.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
On Sep 10, 2017, at 13:46, Nathaniel Smith wrote:
>
> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote:
>> For PEP 553, I think it’s a good idea to support the environment variable
>> $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get
at 30 ms or whatever of startup time is an important enough
> optimization to justify the special case?
I’m probably too steeped in the implementation, but it feels to me like not
just loading the envar callable on demand makes reasoning about and using this
more complicated. I think
tion can use `is` instead of `==` to compare keyword argument
values.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
t for this flag.
You’d have to disallow the combination `order=True, eq=False` then, right? Or
would you ignore eq for any value of order=True? Seems like a clumsier API
than a single tri-value parameter. Do the module constants bother you that
much?
-Barry
signature.asc
Description: Mess
Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class
feature. I’ve also updated PR #3355 with the implementation to match.
Cheers,
-Barry
PEP: 553
Title: Built-in breakpoint()
Author: Barry Warsaw
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 2017
On Sep 14, 2017, at 09:56, Mike Miller wrote:
> Record is the most common name for this ubiquitous concept.
Mind if we call them Eric Classes to keep it clear? Because if its name is not
Eric Classes, it will cause a little confusion.
g’day-bruce-ly y’rs,
-Barry
signature.asc
Descript
well
could have been an abundance of caution over how far to take the new syntax
(and understanding of course that it’s easier to relax than restrict).
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Pyt
Barry Warsaw wrote:
> Here’s an update to PEP 553, which makes $PYTHONBREAKPOINT a first class
> feature. I’ve also updated PR #3355 with the implementation to match.
I've been in contact with Elizaveta Shashkova from JetBrains. She gave
a great talk at Pycon 2017 which influenced
will use this low
traffic, high value forum as the primary way the PSRT will communicate security
issues of high importance back to the wider Python community. All follow-ups
to postings to this list are redirected to the security-sig mailing list.
Cheers,
-Barry (on behalf of the PSRT
On Sep 27, 2017, at 11:56, Jesus Cea wrote:
>
> On 21/09/17 17:30, Barry Warsaw wrote:
>> https://mail.python.org/mailman/listinfo/security-announce
>
> "No such list security-announce".
>
>> https://mail.python.org/mailman/listinfo/security-sig
>
>
On Sep 27, 2017, at 12:24, Guido van Rossum wrote:
>
> Can we add redirects to the old list locations?
I’m not sure we need it for security-announce given how new that list is and
that we only have one message to it. I’ve forwarded this request to
postmaster@ though.
-Barry
signatu
at look like, how would it be invoked, and how would that change
the behavior of the interpreter?
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pytho
1580
https://github.com/python/cpython/pull/3755
I think there are opportunities for an explicit API for lazy compilation of
regular expressions, but I’m skeptical of the adoption curve making it
worthwhile. But maybe I’m wrong!
-Barry
signature.asc
Description: Mess
ook = pdb.pm`
> right? So this hardly deserves an open issue.
Correct, and I’ve removed this open issue.
> - I haven't read the actual implementation in the PR. A PEP should not depend
> on the actual proposed implementation for disambiguation of its specification
incomplete
gain. But of course it’ll take forever for all your dependencies to use
whatever new API we come up with, and if it’s not as convenient to write as
‘import foo’ then I suspect it won’t much catch on anyway.
-Barry
signature.asc
Description: M
e 3, in foo
TypeError: 'NoneType' object is not callable
I’m open to special-casing this if you think it’s useful.
(I’ll update the pseudocode in the PEP.)
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
P
On Oct 2, 2017, at 18:43, Guido van Rossum wrote:
>
> OK. That then concludes the review of your PEP. It is now accepted! Congrats.
> I am looking forward to using the backport. :-)
Yay, thanks! We’ll see if I can sneak that backport past Ned. :)
-Barry
signature.asc
Description
ce given that the documentation does say that
identifiers are ASCII by default, but it also means that a client who wants to
use Unicode previously didn’t have to touch flags, and after this change would
now have to do so. `flags` is part of the public API.
Maybe for subclasses you could say tha
o represent the
precompiled regex in the bytecode, and it would technically be a semantic
change since regex problems would be discovered at compilation time instead of
runtime - but that might be a good thing. You could also make that an
optimization flag for opt-in, or a flag to allow opt
e: Optional[bytes]
bit_field: Optional[bytes]
code_object: bytes
def parse_pyc(path: str) -> PycFileSpec:
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python
hink it makes sense to follow the top-level organization of
the library manual:
https://docs.python.org/3/library/index.html
That already provides a mapping from module to category, and for the most part
it’s a taxonomy that makes sense and is time proven.
Cheers,
-Barry
signature.asc
Descript
On Oct 3, 2017, at 13:29, Benjamin Peterson wrote:
> I'm not sure turning the implementation details of our internal formats
> into APIs is the way to go.
I still think an API in the stdlib would be useful and appropriate, but it’s
not like this couldn’t be done as a 3rd party modu
have a strong opinion either way, please follow up here, on the PR, or
on the bug tracker.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo
ctice until
Python 3.7 is released, so maybe I just choose one and document that the
behavior of PYTHONBREAKPOINT under -E is provision for now. If that’s
acceptable, then I would just treat -E for PYTHONBREAKPOINT the same as all
other environment variables, and we’ll see how it goes.
Cheer
thon gist you referenced, you wouldn’t even need that convenience
function. Just set sys.breakpointhook=conditional_breakpoint.breakpoint_ and
viola!
You could also PYTHONBREAKPOINT=conditional_breakpoint.breakpoint_ python3.7 …
and it should Just Work.
Cheers,
-Barry
signature.asc
Description: Message signed with Op
back Nick. For now we’ll go with the standard behavior of
-E and see how it goes. We can always add a -X later.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
their optimizations, and rewrite new files with the proper
format.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
T
the same as all other environment variables when -E is present. Let’s see how
that goes.
Thanks all for the great feedback and reviews. Now I’m thinking about putting
a backport version on PyPI. :)
Cheers,
-Barry
signature.asc
Description: Message signe
lfNotBees.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ent to python-dev. python-list is included because it’s the primary
mailing list followed by people who aren’t developing Python but are still
interested in it.
Maybe this needs to be reconsidered here in 2017, but that’s the rationale for
the wording of PEP 1.
Cheers,
-Barry
signature.asc
Descr
s is not mutually exclusive.
Practically speaking though, there just aren’t a ton of well maintained FLOSS
archivers to choose from. HyperKitty *is* well maintained. Frankly speaking,
Pipermail is not.
Cheers,
-Barry
signature.asc
Description: Message signed with
ggy Pipermail was for a
long time. (And trust me, you really don’t even want to look at the code. ;)
Cheers,
-Barry
[1] https://wiki.list.org/DEV/Stable%20URLs
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-
This is a process change though, so I’ll work with the PR#441 author to get the
update into the PEPs, and then make the announcement on the relevant mailing
lists.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mail
and/or python-dev. In the effort to keep the
forums of record to a manageable number, python-list is dropped.
If you have been watching for new PEPs to be posted to python-list, you are
invited to follow either python-dev or python-ideas.
Cheers,
-Barry (on behalf of the Python development
Gmane too (although not for python-dev), and agree
with everything your saying here. Right now however, MM3 does not have a
built-in NNTP server.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
P
ported to Python
3.
mailmanclient, the official library of bindings to the Core REST API, is of
course both Python 2 and 3.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https:
cially Mark Sapiro, on the migration.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/m
ew UI
* Has the BDFL as a member :)
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
kept in stdlib typing, and can we provide an
extension or override mechanism if you want the latest and greatest?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
374 | collections.abc
import time: 15124 | 46226 | typing
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
htt
On Nov 3, 2017, at 17:09, Luca Sbardella wrote:
>
> Impressive stats! I didn’t know this command, thanks!
Neither did I until a day or so ago. I already only want to use Python 3.7. :)
-Barry
signature.asc
Description: Message signed with O
multi-Python-version code.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/
e::DeprecationWarning`).
+1
I’d also consider adding convenient shortcuts for each of these. I think
DeprecationWarning is special enough to warrant it. Possibly:
warnings.silence_deprecations()
python -X silence-deprecations
PYTHONSILENCEDEPRECATIONS=x
Cheers,
-Barry
signatu
ects that
*want* to do the right thing but don’t because those warnings are essentially
hidden until they are breakages. We have tools to help, so let’s use them.
Staying current and code clean is hard and never ending. Welcome to software
development!
-Barry
signature.asc
Description: Messa
ng, so the above may look
> like:
>
>warnings.ignore_deprecations((3, 7))
>python -X ignore-deprecations=3.7
>PYTHONIGNOREDEPRECATIONS=3.7
That could be cool as long as we also support wildcards, e.g. defaults along
the lines of my suggestions above to ignore everything.
e wave and adopt the latest and greatest features as
soon as they’re available?
Neither answer is wrong or right… for everyone. It’s also a debate as old as
the software industry. Every package, project, company, developer, community
will have to decide for themselves. Once you realize you ca
creasing use
out in the wild, for the reasons that Steve and David have pointed out. (Let’s
let Eric be the one that breaks the mold with data classes. Then we can blame
him!)
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python
to spell
that.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-de
e a hardship in some environments,
it is on the whole a positive beneficial indicator that gives developers
some runway to fix such problems. These types of apparently sudden
breakages are the worse of all worlds.
Cheers,
-Barry
___
Python-Dev mailing lis
ordering for built-in dict *in the
language specification*. Otherwise we might need a section as big as chapter 5
in the Python Language Reference just to dict ordering semantics. ;)
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
_
ng guarantees for built-in dict in the Python Language Reference?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
nder
review or not. I can probably only tell that at run time.
So how to I accurately review that code? Is the order presumption valid or
invalid?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing l
s for whom setting an environment variable or flag isn’t that big of a
deal.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
ately left as implementation details.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/optio
o make it easy to import an externally
built and installed wheel, from some location outside of its own installed tree
(/usr/share/python-wheels).
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
P
uage make about the
ordering of kws that Foo.foo() is passing to Bar.foo()?
-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/archive%40mail-archive.com
robably deliberately randomize iteration order.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ried that instead of assuming it would generate the
same warning. Yes, that’s definitely a bug. I wonder if we should push back
making async/await reserved words until Python 3.8?
https://bugs.python.org/issue31973
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
tion that
Python held, e.g. versus Perl. I still believe it’s an important principle to
maintain.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
default, and setuptools were modified
to silence them in entry point generated mains, and we had a simple API
to easily silence them for manually written mains, wouldn't that handle
the majority of relevant use cases nicely?
-Barry
___
Python-Dev
Python < 3.7 would still have an “out”. (Yes, the simplified API
is just a convenience moving forward.)
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
On Nov 8, 2017, at 12:02, Guido van Rossum wrote:
>
> I hadn't seen that, but it requires too much cooperation of library owners.
Actually, mostly just setuptools and as Paul points out, pip.
Cheers,
-Barry
signature.asc
Description: Message signed w
ritten in
Python, and wouldn’t know what to do about those warnings anyway. And they do
cause anxiety.
I suppose there are lots of ways to do this, but at least I’m pretty sure we
all agree that end users shouldn’t see DeprecationWarnings, while developers
should.
-Barry
signature.asc
Des
etter suited to my
needs. It probably does strike the right balance to see that in my own test
suite only.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
rt annotations" I think "But
> we've had annotations since 3.0, why would they need a future
> import?".
+1 for lazy_annotations for the same reason.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Pyt
On Nov 16, 2017, at 06:53, Victor Stinner wrote:
> What do you think? Is it ok to include asyncio in the global "developer mode"?
I’m +1 on that, and the performance hit doesn’t bother me for a developer mode.
-Barry
signature.asc
Description: Message signed
dev? I’d rather not have to
look it up in some obscure docs page whenever I use it. If not that, then what
about having a -msettings module or some such that prints it out?
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-De
-X develo== now you’re talking (literally)
-X develop == thank you sir, may I have another?
-X develope == here comes the flood
-X developer == needle inna haystack!
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-D
On Nov 17, 2017, at 20:22, Victor Stinner wrote:
>
> Or maybe we should start adding new modes like -X
> all-warnings-except-PendingDeprecationWarning, -X
> I-really-really-love-warnings and -X warnings-hater, as Barry
> proposed?
Well, if I can’t convince you about a `-X t
n None
return wrapper
@noop
def do_something_important(x, y, z):
return blah_blah_blah(x, y, z)
print(do_something_important(1, 2, z=3))
Cheers?
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Pyth
re will be
taught, both to new Rust programmers and experienced ones. I love the emphasis
on teachability. Sometimes I really miss that when considering some of the
PEPs and the features they introduce (look how hard it is to teach asynchronous
programming).
Cheers,
-Barry
signature.asc
Desc
> On Nov 28, 2017, at 15:59, Paul Moore wrote:
>
> On 28 November 2017 at 20:38, Barry Warsaw wrote:
>> I had occasional to speak with someone very involved in Rust development.
>> They have a process roughly similar to our PEPs. One of the things he told
>
valent. You
would have to write:
val = name.strip()[4:].upper() except Exception as -1
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python
lly can’t be done, or that we really
don’t have a good understanding of the problem and we’re just chipping away at
the edges.
I know that’s unhelpful in deciding whether to accept the PEP or not. In the
absence of any clear consensus, I’m happy to trust Guido’s instincts or keep
the status quo
guous point in time. We just cannot know what
political timezone to choose.
I'd guess that it should use the UTC timezone in that case.
Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Uns
/
Cheers.
-Barry and Brett
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive
-ci.yml
We welcome contributors on the ci-images GitLab project!
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
On Dec 10, 2017, at 19:36, Ryan Gonzalez wrote:
>
> Question: why is this using GitLab while CPython itself is using GitHub +
> Travis?
Mostly because Brett gave me the option to use GitLab for importlib_resources,
and this grew out of that. Enjoy!
overturn-pep-507-ly y’r
)
--
Traceback (most recent call last):
File "/Users/barry/projects/python/cpython/Lib/test/test_embed.py", line 207,
in test_bpo20891
out, err = self.run_embedded_interpreter("bpo20891")
File "/Users/barry/projects/python/cpython/Lib/tes
On Dec 15, 2017, at 15:14, Raymond Hettinger
wrote:
>
> I saw this same test failure. After a "make distclean", it went away.
Dang, not for me.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing
and keeping them in sync would be easier). Brett says in the follow up:
"As for the type hints, I thought it was lifted such that new code could
include it but we wouldn't be taking PRs to add them to pre-existing code?”
So, what’s the deal?
-Barry
signature.asc
On Dec 18, 2017, at 21:11, Chris Barker wrote:
> Will changing pprint be considered a breaking change?
Yes, definitely.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
ht
details though, e.g. should we
special case dictionary sorting only? Should we use a sort `key` to mirror
sorted() and list.sort()?
We can figure those things out and whether it’s even worth doing. I don’t
think that’s PEP-worthy, so if someone is sufficiently motivated, please open
an issue on b
) is indeed mostly for debugging, but not always. As an example
of what will break if you change the sorting guarantee: in Mailman 3 the REST
etag is calculated from the pprint.pformat() of the result dictionary before
it’s JSON-ified. If the order is changed, then it’s possible a client will
hav
y being handled?
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pyt
has been updated to use data:: so I’ll change my
branch accordingly.
> Concerning the question whether it makes to document types, I think it makes
> sense if it is a publicly available type (or type alias)
> that will be useful to annotate user code.
Thanks, that’s my feel
ocked into the API, I don’t see a whole lot of options.
Thoughts, feedback, suggestions are welcome.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinf
On Jan 6, 2018, at 11:43, Guido van Rossum wrote:
>
> Maybe we should not delete them outright but add something like "(UPDATE:
> during later discussions it was decided that this feature shouldn't be
> added.)"
+1
-Barry
signature.asc
Description:
es to call them).
Is it worth changing the quoting at all? I would say not.
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/arch
On Jan 13, 2018, at 11:12, Miro Hrončok wrote:
>
> We would very much like to see --user the default rather than having it
> removed.
Very much +1. In Debian/Ubuntu we’ve carried patches to do exactly that for
years, and I think our users have been very happy about it
101 - 200 of 2826 matches
Mail list logo
