t -- but many of us
>learn more from examples than the specification, so maybe I'll submit a
>patch with an example like that.
I also very much doubt you'd get consensus on that as a requirement, and I
would oppose the PEP taking a stand one way or the other.
bing both policy and implementation (i.e. which
platforms we officially support) is worthwhile. While I think you could write
a new PEP, I also think it might just make sense to co-opt PEP 11 and broaden
its scope, since as you say, removing support is only half the story.
Cheer
14/05/msg00162.html
The question remains whether Jessie will drop Python 3.3, but I expect it to.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
nt. With
True/False, it was a runtime-wide change that affected every Python program,
and there was no such "special dispensation".
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python
yes the latter has been preferred for
a long time now.
Given that 2.7 is a long term support release, it's inevitable that we'll
break the 2-digit micro release number barrier. So be it. A 2.7.10 isn't the
end of the world.
-Barry
___
yntactic and semantic issues have been narrowed and prohibited, and I can see
myself using this sparingly. It’s not the first time I’ve found myself in this
position with a new Python feature, and it’s one of the reasons I deeply trust
Guido’s intuition and sensibilities.
Cheers,
-Barry
[*
ing code. The intent wasn’t to use `subdirs` outside
of the assert statement, but I’m warm to it because it means I don’t have to do
wasted work outside of the assert statement, or repeat myself in the assert
message part.
-Barry
signature.asc
Description: Message signe
xception
> detail. The assignment-expression version cannot.
Tim, you’re dangerously tempting me into +1 territory. :)
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
sequences.
I’ll use a boolean test (e.g. `not` or false-iness) when the subject could be
empty, None, or the empty string, and `len() == 0` when the subject is supposed
to be a sequence.
-Barry
signature.asc
Description: Message signed with OpenPGP
_
On Jul 18, 2018, at 13:54, Victor Stinner wrote:
> Last May, we worked hard to fix many random test failures on all CIs
> before Python 3.7 final release.
Thank you thank you thank you Victor for work on keeping the buildbots happy!
-Barry
signature.asc
Description: Message signe
a lot of changes. I'm not sure yet
> what is the best option.
Do you have WIP branch for the backport? I agree that it’s probably low enough
risk given the private nature of the API in 3.7, but that it’s up to Ned to
decide.
-Barry
signature.asc
Description: Message signed with O
m Benjamin (the 2.7 release manager) on the (tentative)
exact final release date, and then codify that in the PEP. I’d be very happy
if that, or say December 31 2019 were the actual last release date.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
__
pretty evident what
they mean.
Perhaps we could have a single format code plus an optional '#' for the
"alternate form":
%T for short form
%#T for fully qualified name
OTOH, if %T and variants meant "type" but %t mean
tforward
translation from the original C, so it could use some clean ups (and I think
Serhiy is planning that). So the problem you describe should be easier to fix
now in 3.8. It would be interesting to see if we can squeeze more performance
and better behavior out of it now that it’s in Python.
the interpreter relies heavily on them.
Maybe this is better off discussed in doc-sig but I think we need to consider
documenting the private C API.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing
on’t have any great ideas about how to balance
that, and I don’t know what documentation techniques would help, but it does
often bother me that I can’t search for them on docs.python.org.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
On Sep 25, 2018, at 10:08, Jeroen Demeyer wrote:
>
> On 2018-09-25 16:01, Barry Warsaw wrote:
>> Maybe this is better off discussed in doc-sig but I think we need to
>> consider documenting the private C API.
>
> Even the *public* C API is not fully documented.
the idea of an “internals” C API documentation, separate from the public
API.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsu
C API, or in a separate
directory, listed or not under “Parts of the documentation” on the front
landing page. But I agree they shouldn’t be intermingled with the public C API.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
> until the governance situation gets resolved. That's the only reason why PEP
> 544 is not yet accepted for example.
Correct. It’s entirely possible that the different governance models will have
different ways to pick delegates.
-Barry
signa
. The question is, do we have to support uses where people
> intentionally smuggle non-identifier strings as keys via **kwargs?
I would not be in favor of that. I think it doesn’t make sense to be able to
smuggle those in via **kwargs when it’s not supported by Python’s
grammar/syntax.
-Ba
le.
>
>> 5. Use quotes around type name or not?
Ideally yes, if it’s easy to implement.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
On https://wiki.python.org/moin/WindowsCompilers details for 3.7 are missing.
I'm assuming its still VC V14
Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
taller doesn't include the IDE
> itself).
>
> Feel free to update the wiki.
Just got around to doing this. That page is marked as Immutable Page for me.
Do I need to apply for edit permissions? I'm user BarryScott on the wiki.
Barry
>
> Cheers,
> Steve
>
> On
ut porting py2
> to 3 during these years. Any not-yet-answered question surely can be
> done in a list with more participants.
>
> Can we kill this list?
Is it a maintenance burden? If not, then maybe we should wait until 2.7 is
EOL’d? There might be an uptick in traffic as reality
ython 3.8 user will
get bitten by this. Therefore...
> Option 4) Just make the change directly in 3.8,
JFDI!
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
short circuiting label), but
that might be unpopular.
-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.o
happen and we get too late in the release cycle to
roll the change back.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
just pushed an update for the latest Python 3.8 alpha and
3.7.2. It’s building now, but the image should be published on quay.io as soon
as that’s done.
Contributions most welcome!
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Py
etter way to publicize these
images?
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/mail
hould be reserved for some future mythical GIL-less interpreter or
other major API breaking change. It might never happen.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
On Feb 13, 2019, at 15:07, Victor Stinner wrote:
>
> Le mer. 13 févr. 2019 à 21:26, Barry Warsaw a écrit :
>> I don’t think this should be conflated with PEP 394. IMHO, 3.10 is just
>> fine. Python 4 should be reserved for some future mythical GIL-less
>> interp
expect to only ship /usr/bin/python.
-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/opti
I’m not sure that I agree
with all the proposed changes to PEP 394, but those are the guidelines I think
I’ll re-evaluate the PR by.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
ht
ybe we should have a
Py_I_TOO_LIKE_TO_LIVE_DANGEROUSLY?).
Let's call it Py_POINTED_STICK of course!
http://www.montypython.net/scripts/fruit.php
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth
t opens a new GitHub issue with
that information pre-populated.
-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://m
er (too easy?).
-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/ar
now whether this analysis is complete or correct, but perhaps it helps
inform a way forward on PEP 394.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
l have substantially different
opinions than what you’ve gathered already?
-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
Y
>
> rather than
>
>#!/usr/bin/env python
Indeed. I used to fight that battle quite a bit, although at least in my
circles that lesson has by now been learned. `/usr/bin/env python` is great
for development and terrible for deployment.
-Barry
signature.asc
Descriptio
already surprising to many users, so we should be careful not to
make the situation worse.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
ave any expectation of them having
> anything to do with each other.
I’m just relaying a data point. Some Python folks I’ve worked with do make the
connection between dicts and sets, and have questions about the ordering
guarantees of then (and how they relate).
-Barry
signature.asc
Descriptio
were first to do it.
Debuntu’s pip installs to the user path by default, and you have to do
something explicit to install into the system Python.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@py
although sponsors
can of course have a range of involvement. Our core devs want you to succeed
(or conversely save you from wasting your time), and they’ve been there, done
that.
Core dev sponsors can be a great resource for folks new to the process.
Cheers,
-Barry
signature.asc
Description
many fun and scary paths to explore. See you in 6
months.
jeremy-is-salty-ly y’rs,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
ge will contain the last versions of Python 3.x
>
> https://gitlab.com/python-devs/ci-images/merge_requests/9
Thank you Stéphane! This is now merged and the updated image is available.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
Thanks for the update. I have made one small suggestion on the PR for
clarification, but otherwise the changes LGTM.
-Barry
> On Apr 12, 2019, at 07:53, Miro Hrončok wrote:
>
> Hello.
>
> Based on discussions in [1], Petr Viktorin and me have drafted a new update
> [2] t
On May 7, 2019, at 03:52, Steve Holden wrote:
>
> What's not to like?
My only complaint is that you steadfastly refuse use Guido’s time machine keys
to make this available in 3.7.
-Barry
signature.asc
Description: Message signed w
rb the
> culture."
>
> Perhaps we want to reverse the two sentences to put them in chronological
> order?
>
> I'm not sure what the proper forum for this discussion would be.
Here or -committers. Then postmasters to list owner to change the welcome text.
-Barry
s
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
proof, but it’s an option to perhaps
consider.
-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.or
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
signature.asc
Descript
probably
> have a discussion as a team about how we view the stdlib long-term and how
> that ties into maintaining it so that people's opinion of the stdlib's
> quality goes up rather than viewing the quality of it as varying
> module-to-module.
+1 :)
-Barry
signature.asc
anger all the existing devs.
IMHO, if the switch to GH doesn’t improve our workflow, then it definitely
warrants a reevaluation. I think things will be better, but let’s prove it.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Pyt
On Jun 5, 2019, at 02:08, Victor Stinner wrote:
>
> Our kind postmasters Mark Sapiro and Abhilash Raj migrated
> python-ideas and python-dev mailing lists from Mailman 2 to Mailman 3
> (running on Python 3 ;-))!
Gosh, it warms my heart. :)
Thank you Mark, Abhilash!
-Barry
s
Ls are guaranteed to be reproducible from the original message
source. The downside is that they are less friendly.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe s
y years ago, with
discussions among list owners, third party archive maintainers, and developers.
This page gives additional details and background:
https://wiki.list.org/DEV/Stable%20URLs
(standard-in-quotes because no one’s ever proposed an official RFC.)
-Barry
signature.asc
Description: Message si
agement, discoverability, understanding, and
use too unwieldy if we simply map all the bpo data to labels? This might be
one area where we want to get closer interaction with the GH folks on their
plans or suggestions.
Thanks for all your work on these PEPs.
-Barry
signature.asc
D
> Is there a solution to this that would enable moderators to approve
> more frequently?
Volunteers are welcome! :)
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubsc
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.
Che
I’ve updated the official images to include 3.8.0b2:
https://gitlab.com/python-devs/ci-images/tree/master
Cheers,
-Barry
> On Jul 4, 2019, at 15:05, Łukasz Langa wrote:
>
> Signed PGP part
> After a few days of delay, but somewhat cutely timed with the US Independence
> Day
took care with private underscore names and some
> didn't). To me this has mostly worked out fine and didn't require a strict
> rule for all modules everywhere. IMO, there is no need to sweep through the
> library and change long-standing policies on existing modules.
EIBT
all__ manually. And once it's public API, we
> shouldn't be making it too easy to rename the function anyway ;)
My package has a C version. If public() were a builtin (which I’ve
implemented) it wouldn’t have that much import time overhead.
-Barry
signature.as
ing in __all__ doesn’t match an existing name in
the module. Some tools like Sphinx will complain when names appear in __all__
don’t appear in the module. All of this points to the root problem; it should
be easy to keep __all__ in sync!
“””
Think of it this way: __all__ is an implementation detai
ogise for mentioning that people care about import performance.
> Let's ignore them/that issue for now and worry instead about making sure
> people (including us!) know what the canonical reference for public/internal
> is.
+1
-Barry
I have updated the official docker images with 3.8b3:
https://gitlab.com/python-devs/ci-images/tree/master
-Barry
> On Jul 29, 2019, at 14:48, Łukasz Langa wrote:
>
> Signed PGP part
> This time without delays, I present you Python 3.8.0b3:
>
> https://www.python.org/downlo
implementations at
Facebook. You might want to reach out to him.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
That’s what I was going to suggest. I’m not doing any Debian or Ubuntu work
these days, but Matthias Klose should be watching both lists, and should be
able to handle the Debuntu stack.
-Barry
> On Nov 16, 2020, at 07:45, Miro Hrončok wrote:
>
> On 11/16/20 4:10 PM, Paul Gans
On Nov 16, 2020, at 11:51, Paul Ganssle wrote:
>
> Not to put words in Barry's mouth, but I took Barry's comment to be more an
> answer to the question of how to contact "distro packagers" as a group, more
> than he was taking a position about this particular
ithout needing to read the
PEP in detail.
I like that a lot.
I quickly read 642 v3 and missed an explanation about why the syntax to match a
string object is
str{} and not str. Are you saying that I MUST use {} so that when case is
parsed its clear that its a class
with no constraints?
in the "Cha
PEP are gated with:
>
> from __future__ import co_annotations
Given that PEP 563 is now the default in unreleased Python 3.10, does it make
sense to introduce yet another __future__ import? What would happen if you
just piggybacked your idea onto that change?
-Barry
signature.
turn this
off
for for people like me that have many versions of python installed.
I think of two things that could be checked for.
1. A marked in the .bashrc/.zshrc file. '# python-disable-path-edit'
2. A file in ~/Library somewhere that disabled the behavour
Barry
>
> --
to this (thanks to Matthew Barnett for the improved names:
python-3.10.0a5-win32-setup.exe
python-3.10.0a5-win64-setup.exe
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https
I raised https://bugs.python.org/issue43155 for the missing
PyCMethod_New that was added in 3.9 but is missing from the
python3.lib.
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
I think this fix for the limited API on Windows is not in the RC.
I could not fine the new code in the tarball.
Can it be added?
https://bugs.python.org/issue43155 <https://bugs.python.org/issue43155>
Barry
> On 17 Feb 2021, at 12:50, Łukasz Langa wrote:
>
> I’m happy
ception?
I'm -1 on that as its confusing.
Having checked that its python code and not a C extension function you could
use the info
in fn.__code__ to get the filename and line of where the function is defined
and put that info into the exception.
Example of the info:
|
nger (32-bit) alignment requirements, so m68k is actually
> less likely to break.
On x86 you can make unaligned access to memory.
Alignment is a nice to have for performance.
But on m68k you MUST align or you get a SIGBUS.
Barry
___
Python-Dev mailing l
d raising a App/Lib specific exception
that provides the context. For example AppFailedToSaveConfigError and
AppFailedToSaveDataError as oppose to a two permission OSError's.
With context I can imagine that handling the ExceptionGroup would be
a lot easier for the App designer.
If that the pattern that emerges
,
-Barry
On Mar 9, 2021, at 16:27, Terry Reedy wrote:
>
> On 3/9/2021 3:27 PM, Pablo Galindo Salgado wrote:
>
>> The Steering Council just published the community update for February:
>
> Thank you for posting this.
>
>>The Steering Council discussed rena
need to discuss whether the typing language and the general Python syntax
needs to continue to track.
Cheers,
-Barry
> On Mar 15, 2021, at 13:07, Guido van Rossum wrote:
>
> Let me clarify what the typing-sig folks wanted out of this PEP. We only care
> about adding support for `x[
hat reading the files can be audited.
Conclusion
The Python Steering Council again wants to thank you for your PEP contribution!
We hope you find this feedback constructive and helpful. We look forward to
your responses, and an updated PEP.
Cheers,
-Barry (on behalf of the Python Steering C
Great points Christian, thanks.
-Barry
> On Mar 30, 2021, at 10:59, Christian Heimes wrote:
>
> On 30/03/2021 19.01, Barry Warsaw wrote:
>> Hello Mario,
>>
>> Thank you for your submission of PEP 648 (Extensible customizations of the
>> interpreter at start
pth files and finding something
better, but maybe not.
In any case, this is outside the scope of PEP 648 so just pretend that part
wasn’t in my response.
-Barry
> On Mar 30, 2021, at 17:00, Pablo Galindo Salgado wrote:
>
> Hi Nick,
>
> Please don't, since that would for
his would be a hard nut to crack.
def func(fixed, *args):
print("my func", fixed, args)
Barry
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mai
perhaps you could add some language to the Rejected Ideas about it. Ultimately
we couldn’t come up with anything better, so we decided that the PEP as it
stands solves the problem in a practical manner, and that this is for the most
part a wart that users will just have to learn and internal
a little ecosystem of
its own, and given that many Python users are still not fully embracing typing,
maybe continuing to tie the typing syntax to Python syntax is starting to
strain.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
le example! Who’s maintaining the list? :D
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailma
nting in Python.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Mess
n parameter or
> function return value must be specified?) Some of us don't use type hinting
> or annotations (I don't even pretend to understand what they are) and don't
> intend to. No offence to those who like them, carry on doing your thing.
> Please reassure
making that change. importlib.metadata is a much better
approach to programmatically determining package versions.
https://docs.python.org/3/library/importlib.metadata.html#distribution-versions
-Barry
signature.asc
Description: Message signed
g a new PEP and referring back to 396.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/li
On Apr 15, 2021, at 09:54, Antoine Pitrou wrote:
>
> On Thu, 15 Apr 2021 09:38:41 -0700
> Barry Warsaw wrote:
>> On Apr 14, 2021, at 23:11, Christopher Barker wrote:
>>>
>>> You wrote the original PEP, so of course you can withdraw it (or reject
>>&
(this whole topic is on our agenda for next Monday), but it might be the
best thing to do given where we are in the 3.10 release cycle. It would give
everyone a chance to breathe and come up with the right long term solution.
Cheers,
-Barry
signature.asc
Description: Message signed with O
on’t know whether I’ll have time to *start* something any time soon, but I
would also volunteer to be a reviewer and/or provide some content.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev
eries of curated videos under the Python/PSF
banner would be awesome.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
/OGYZZZ4A54RI24YEKZEPPLWU4WPRLJPE/
We on the SC extend our thanks again for the PEP, and encourage you to continue
to work on this PEP for pronouncement in Python 3.11.
Cheers,
-Barry
(on behalf of the Python Steering Council)
signature.asc
Description: Message signed with OpenPGP
>> Slapping my forehead,
>
> You probably mean "Slap my forehead”.
Actually, he probably meant “Slappa da bayss”.
-Barry
P.S. I was going to say that I prefer past tense when writing news items, but
then I looked at the change log files for some of my personal projects and I
not pass this argument”
construct would have to work with the Optional type too.
The other use case I have for a special case single use singleton is for
dict.get(), i.e.
missing = object()
value = somedict.get(‘key’, missing)
if value is missing:
# It ain’t there.
-Barry
signature.asc
Descriptio
I think it makes sense, and I do see a difference between Provisional and
Unstable. Is this anything more than a documentation label?
-Barry
> On Jun 3, 2021, at 13:10, Guido van Rossum wrote:
>
> This is not a complete thought yet, but it occurred to me that while we have
> dep
tps://docs.gitlab.com/ee/user/project/import/github.html
Of course, that would still be infrastructure we’d have to run (unless we used
gitlab.com, but then some people might still object), and that migration would
also have to deal with Roundup issues if we don’t complete that migration.
-Barry
401 - 500 of 2826 matches
Mail list logo
