Hi,
I'm currently working on exposing posix_spawn in the posix module (and by
extension in the os module). You can find the initial implementation in
this PR:
https://github.com/python/cpython/pull/5109
As pointed out by Gregory P. Smith, some changes are needed in the way the
file_actions argum
I think I really like Antoine's suggestion so I'm going to finish
implementing it that way. I think this keeps the API simple, does not bring
in the os module new dependencies, keeps the C implementation clean and is
consistent with the rest of the posix module. I will post an update when is
ready.
month if possible.
Thanks you very much everyone for your time and suggestions!
On Wed, 10 Jan 2018, 09:17 Pablo Galindo Salgado,
wrote:
> I think I really like Antoine's suggestion so I'm going to finish
> implementing it that way. I think this keeps the API simple, does not bri
Hello everyone,
In today's episode of exposing useful Linux system calls I am exposing
preadv2 in this PR:
https://github.com/python/cpython/pull/5239
as requested in this issue:
https://bugs.python.org/issue31368
As njsmith has commented in the PR, preadv2 only exists because regular
preadv w
The docs for sys.settrace mention that:
>> event is a string: 'call', 'line', 'return', 'exception', >> 'c_call',
'c_return', or 'c_exception'
But in the code for ceval.c the only point where call_trace is invoked with
PyTrace_C_CALL or PyTrace_C_RETURN is under the C_TRACE macro. In this
macro t
Hi,
I am working on the release blocker https://bugs.python.org/issue32232. I
tried to apply the patch proposed by Matthias Klose and I found that it
works on Unix but it fails to build on Windows (probably because circular
imports). I tried to add some tests but after some work on the problem and
> > Pablo's issue35378 evolved to add a weak reference in iterators to try
> > to detect when the Pool is destroyed: raise an exception from the
> > iterator, if possible.
> That's an ok fix for me.
I am playing with weakreferences inside the iterator and result objects,
but this may not be enoug
uns) and that is the reason I was
experimenting with the weakreference.
On Tue, 11 Dec 2018 at 18:37, Paul Moore wrote:
> On Tue, 11 Dec 2018 at 17:50, Pablo Galindo Salgado
> wrote:
> > I agree that misusage of the pool should not be encouraged but in this
> situation the f
into two forums (discourse and
python-dev),
we kindly ask you to go to discourse if you want to participate in the
debate :)
Here is the full document of the PEP:
https://www.python.org/dev/peps/pep-0570/
Pablo Galindo Salgado
___
Python-Dev mailing list
Hi everyone,
TLDR
=
I propose to remove the current parser module and expose pgen2 as a
standard library module.
Some context
===
The parser module has been "deprecated" (technically we recommend to prefer
the ast module instead) since Python2.5 but is still in the standard
library.
cal new package (with some new API over it may be) is already
undocumented
as an implementation detail of lib2to3 (and some people are already using
it directly).
On Thu, 16 May 2019 at 23:41, Nathaniel Smith wrote:
> On Thu, May 16, 2019 at 2:13 PM Pablo Galindo Salgado
> wrote:
> >
ib2to3 in the same
email.
Perhaps we can be more productive if we focus on just deprecating the
"parser" module, but I thought it was an opportunity to solve two (related)
problems at once.
On Mon, 20 May 2019 at 17:28, Guido van Rossum wrote:
> On Thu, May 16, 2019 at 3:51 PM Pablo Galindo
>
> I propose to make co_argcount meaning the number of positional
> parameters (i.e. positional-only + positional-or-keyword). This would
> remove the need of changing the code that uses co_argcount.
>
I like the proposal, it will certainly make handling normal cases
downstream much easier becaus
Opened https://bugs.python.org/issue37122 to track this in the bug tracker.
___
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%40ma
cross several timezones
is very difficult to get them all.
Thanks to everyone that is helping solving these bugs :)
Regards from sunny London,
Pablo Galindo Salgado
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/lis
Hi,
Recently, we moved the optimization for the removal of dead code of the form
if 0:
to the ast so we use JUMP bytecodes instead (being completed in PR14116).
The reason is that
currently, any syntax error in the block will never be reported. For
example:
if 0:
return
if 1:
pass
> Until a solution which makes everyone happy can be found, I suggest to
move back to the status quo: revert the change.
>More people seems to expect "if 0: ..." to be removed, than people who
care of syntax errors on "if 0".
I don't think this is that clear. As Paul wrote on the issue this is th
uot;
guard off an "if 1:" block.
Ok, these were very good points. I am convinced. I agree that the better
thing to do at this pointis to revert this until we can think this a bit
more :)
I have made a PR to revert the change.
On Fri, 5 Jul 2019 at 23:27, Tim Peters wrote:
> [Pablo Galin
I think this summarizes the situation very well :)
https://xkcd.com/1172/
On Fri, 5 Jul 2019 at 22:28, Pablo Galindo Salgado
wrote:
> Hi,
>
> Recently, we moved the optimization for the removal of dead code of the
> form
>
> if 0:
>
>
> to the ast so we use JU
I am fundamentally wrong
(which is possible as is late here) is very simple and covers all the
cases.
It would be great if someone could review the PR to check if I missed
anything with this argument.
On Fri, 5 Jul 2019 at 22:28, Pablo Galindo Salgado
wrote:
> Hi,
>
> Recently, we moved th
Thanks Terry for your comments!
> I presume that most of us agree that the last option, doing both, would be
> best, or at least agreeable.
I created a PR reverting the change but I (may) have found a way of doing both
things :)
___
Python-Dev mailin
>. If it doesn't, could this one optimization
be left in the peephole optimizer at bytecode level?
Sadly no, because at that time there is not enough information left to do
things correctly. The problem manifest with constructs like
if something or __debug__:
...
You cannot just look at the b
Hi Stefano,
One of the problems you have is that the rule for slices has a negative
lookahead for the comma:
slices[expr_ty]:
| a=slice !',' { a }
IIRC the reason that is there is to allow "x[3,]" to be parsed.
Also, to allow "a[k=3]" you need to to create a rule that allows skipping
the "
lations Mark Shannon!
Thanks also to everyone else who provided feedback on this PEP!
Regards from rainy London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
htt
gain, I am pretty sure it will be negligible
impact and the performance check should be just a routine confirmation.
Cheers,
Pablo
On Thu, 29 Oct 2020, 09:47 Mark Shannon, wrote:
> Hi,
>
> That's great. Thanks Pablo.
>
> On 29/10/2020 1:32 am, Pablo Galindo Salgado wrote:
>
le change as a whole then.
Cheers,
Pablo
On Thu, 29 Oct 2020 at 10:55, Mark Shannon wrote:
> Hi Pablo,
>
> On 29/10/2020 9:56 am, Pablo Galindo Salgado wrote:
> > > Performance compared to what?
> >
> > Compared before the patch. The comparison that I mentioned
the implementation :)
On Thu, 29 Oct 2020 at 13:29, Mark Shannon wrote:
> Hi Pablo,
>
> On 29/10/2020 11:08 am, Pablo Galindo Salgado wrote:
> > > The new semantics may well result in some slowdowns. That's stated in
> > the PEP.I don't think I can reliabl
Regarding having a Solaris buildbot: if someone provides a Solaris buildbot
then the deal is that that someone or some other party must look after that
buildbot and fix problems that appear in it in a timely manner. Broken
buildbots stop releases and I don't want to be in a situation in which I
nee
>Two volunteer core developers and at least one buildbot would help a
> lot to ensure that Python is working on Solaris for real, and reduce
> the number of open Solaris issues. If it happens, I'm perfectly fine
> with keeping Solaris support.
> I also hope that more people will contribute to maint
infinities are bigger than others. These infinite
cardinalities normally are represented using aleph numbers. Infinite sets
are strange beasts indeed.
Regards from cold London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To
It's starting to get very cold (at least on the Northern hemisphere) so we
have been carefully packaging a total of three new Python releases to keep
you warm these days!
Python 3.9.1 is the first maintenance release of Python 3.9, and also the
first version of Python to support macOS 11 Big Sur n
://discuss.python.org/t/cpython-codebase-plots/6267
Regards from cloudy London,
Pablo Galindo Salgado
___
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
isingly, the movement of a test particle in such spacetime is not
only a very chaotic system but also has some fractals
<https://arxiv.org/abs/gr-qc/9502014> hiding the complexity of its movement.
Regards from cold London,
Pablo Galindo Salgado
___
Pytho
This may be related to the changes in https://bugs.python.org/issue42246.
Could you open a new issue and add Mark Shannon to it if that turns to be
the case?
Pablo
On Mon, 11 Jan 2021 at 19:36, Chris Angelico wrote:
> On Tue, Jan 12, 2021 at 6:00 AM Mats Wichmann wrote:
> >
> >
> > On 1/8/21 4
One worry that I have in general with this move
is the usage of _PyType_GetModuleByDef to get the type object
from the module definition. This normally involves getting a TLS in every
instance creation,
which can impact notably performance for some perf-sensitive types or types
that are created a l
to because what's underneath (pymalloc or libc
malloc or whatever else) may actually allocate even more
than what you asked.
Regards from cloudy London,
Pablo Galindo Salgado
On Thu, 14 Jan 2021 at 16:10, Julien Danjou wrote:
> Hi there,
>
> I've spent quite some time on
> Exactly, which is a bit a bummer. Considering Python provides 3
> different memory allocator, it'd be great if there was some ability to
> be sure that PyObject_Malloc pointer are actually PyObject, not
> Py_GC_HEAD.
The allocators are specialized based on the allocation strategy
and efficiency,
ment
I forced
PyObject_Init and _PyObject_Init to not be inlined and that made a 7-13%
speed
impact overall in the performance test suite.
If you want to track all objects creation, your best bet IMHO is a debug
build and to use sys.getobjects().
Regards from sunny London,
Pablo Galindo Salgado
object in the stack (like gdb does).
Is this change going to affect these tools or they will continue working as
before? In case this change will affect this tools,
is there any workaround to produce the unified C/Python call stack given the
Python stack and the C stack?
Kind regards,
P
along all the other pros and cons.
Regards from cloudy London,
Pablo Galindo Salgado
On Wed, 20 Jan 2021 at 15:12, Mark Shannon wrote:
> Hi Pablo,
>
> On 19/01/2021 6:46 pm, Pablo Galindo Salgado wrote:
> > Hi Mark,
> >
> > Thanks for gathering this proposal! Looks
thing.
Cheers,
Pablo Galindo Salgado
On Wed, 20 Jan 2021 at 16:06, Mark Shannon wrote:
> Hi Pablo,
>
> On 20/01/2021 3:18 pm, Pablo Galindo Salgado wrote:
> > >It depends on what you mean by "similar tools".
> >
> > Any 3rd party tool or debugger that is
London,
Pablo Galindo Salgado
___
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
neutron star or black hole. Those with masses up to the limit remain stable
as white dwarfs. The currently accepted value of the Chandrasekhar limit is
about 1.4 M☉ (2.765×1030 kg). So we can be safe knowing that our sun is not
going to become a black hole!
Re
as negative mass/energy).
Regards from rainy London,
Pablo Galindo Salgado
___
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/
Messa
ip Thorne to imagine traversable wormholes
created by holding the "throat" of a Schwarzschild wormhole open with
exotic matter (material that has negative mass/energy).
Regards from rainy London,
Pablo Galindo Salgado
___
Python-Dev mailing l
ow to proceed.
Regards from cloudy London,
Pablo Galindo Salgado
___
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
un the following commands to update the name of the default branch.
$ git branch -m master main
$ git fetch origin
$ git branch -u origin/main main
Apart from that, you should update any local script or command that uses
the name "master" to use the name "ma
d help them update within this timescale.
>
> Has this analysis been published anywhere? I know there are lots of places
> where discussions/documentation happens
>
> Thanks
>
> Steve
>
>
>
> On Wed, Mar 10, 2021 at 2:10 PM Pablo Galindo Salgado
> wrote:
>
>>
ally.
On Thu, 11 Mar 2021, 07:37 Serhiy Storchaka, wrote:
> 10.03.21 16:06, Pablo Galindo Salgado пише:
> > # What you need to do?
> >
> > You just need to update your local clone after the branch name changes.
> > From the local clone of the repository on a compute
Hi,
I think this may be https://bugs.python.org/issue41701.
If that's the case this is not on the buildbot worker itself but the proxy.
-
Pablo
On Sun, 21 Mar 2021, 17:12 Antoine Pitrou, wrote:
>
> Hello,
>
> It seems the buildbot Web UI has the bad habit of auto-refreshing
> itself (by doi
> f I have branch fix_something that is branched off master from a while
ago, do I need to do anything to it?
In general no, branches are basically a file that points to a given commit
so even if they branched from master the actual
commit sha is what matters. The only case if you have a branch th
g
the concerts raised.
Congratulations, Christian!
With thanks from the whole Python Steering Council,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.pytho
emselves.
Cheers,
Pablo Galindo Salgado
On Wed, 31 Mar 2021 at 00:34, Nick Coghlan wrote:
>
>
> On Wed, 31 Mar 2021, 3:15 am Barry Warsaw, wrote:
>
>> . We would like to eventually go farther, including deprecation of pth
>> files entirely, but that is outside the scope
thanks from the whole Python Steering Council,
Pablo Galindo Salgado
___
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
Your friendly release team,
Pablo Galindo Salgado @pablogsal
Ned Deily @nad
Steve Dower @steve.dower
___
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/p
you have any questions or concerns, please contact me as soon as
possible.
Regards from sunny London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.py
M3O/
)
If you have any questions or concerns, please contact me as soon as
possible.
Regards from sunny London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://m
I had I and still don't know what's going on. Mine was in a response to a
release announcement so it was extra weird. Here is what I received:
I have now formally filed a final lawsuit against the manager of the python
> program company, because all of him is also a criminal act, and GNU has EU
>
vious
communication about how this will be done and how you should
proceed
https://mail.python.org/archives/list/python-dev@python.org/thread/QWW7KGBW5UH2N5FOZOFXQBQPYELWQM3O/
)
If you have any questions or concerns, please contact me as soon as
possible.
Regard
have some urgent fix or PR that you absolutely need
to get merge before
feature freeze, you can add me as a reviewer to said PR so we can evaluate
the merge.
Thanks for your understanding.
I will update once master is unblocked again.
Regards from cloudy London, Pablo Galindo Salgado
We believe this is extra cost is very
much worth the better error reporting but we understand and respect
other points of view.
Does anyone see a better way to encode this information **without
complicating a lot the implementation**? What are people thoughts on the
feature?
Thanks in advance,
Reg
Technically the main concern may be the size of the unmarshalled pyc files
in memory, more than the storage size of disk.
On Fri, 7 May 2021, 23:04 Antoine Pitrou, wrote:
> On Fri, 7 May 2021 22:45:38 +0100
> Pablo Galindo Salgado wrote:
> >
> > The cost of this is havin
Thanks a lot Gregory for the comments!
An additional cost to this is things that parse text tracebacks not knowing
> how to handle it and things that log tracebacks generating additional
> output.
We should provide a way for people to disable the feature on a process as
> part of this while they
This is actually a very good point. The only disadvantage is that it
complicates the parsing a bit and we loose the possibility of indexing
the table by instruction offset.
On Fri, 7 May 2021 at 23:01, Larry Hastings wrote:
> On 5/7/21 2:45 PM, Pablo Galindo Salgado wrote:
>
> Given th
at 23:35, Gregory P. Smith wrote:
>
> On Fri, May 7, 2021 at 3:24 PM Pablo Galindo Salgado
> wrote:
>
>> Thanks a lot Gregory for the comments!
>>
>> An additional cost to this is things that parse text tracebacks not
>>> knowing how to handle it and things that
2021 at 23:21, Irit Katriel
wrote:
>
>
> On Fri, May 7, 2021 at 10:52 PM Pablo Galindo Salgado
> wrote:
>
>>
>> The cost of this is having the start column number and end column number
>> information for every bytecode instruction
>>
>
>
> Is i
it easier for reporting
the exception as the current traceback display removes indentation.
On Fri, 7 May 2021 at 23:37, MRAB wrote:
> On 2021-05-07 22:45, Pablo Galindo Salgado wrote:
> > Hi there,
> >
> > We are preparing a PEP and we would like to start some early di
al
So that's an increase of 8.56 % over the original value. This is storing
the start offset and end offset with no compression
whatsoever.
On Fri, 7 May 2021 at 22:45, Pablo Galindo Salgado
wrote:
> Hi there,
>
> We are preparing a PEP and we would like to start some early discu
One last note for clarity: that's the increase of size in the stdlib, the
increase of size
for pyc files goes from 28.471296MB to 34.750464MB, which is an increase of
22%.
On Sat, 8 May 2021 at 01:43, Pablo Galindo Salgado
wrote:
> Some update on the numbers. We have made so
, 8 May 2021 at 02:41, MRAB wrote:
> On 2021-05-08 01:43, Pablo Galindo Salgado wrote:
> > Some update on the numbers. We have made some draft implementation to
> > corroborate the
> > numbers with some more realistic tests and seems that our original
> > calculations w
sion as offsets would be quite
random (although predominantly in the range 10 - 120).
On Sat, 8 May 2021 at 01:56, Pablo Galindo Salgado
wrote:
> One last note for clarity: that's the increase of size in the stdlib, the
> increase of size
> for pyc files goes from 28.471296MB to 34.7
pping this extra data.
This is indeed the plan, sorry for the confusion. The opt-out mechanism is
using -OO, precisely as we are already dropping other data.
Thanks for the clarifications!
On Sat, 8 May 2021 at 19:41, Brett Cannon wrote:
>
>
> On Fri, May 7, 2021 at 7:31 PM Pablo G
rpreter compiled without the flag.
On Sat, 8 May 2021 at 21:13, Gregory P. Smith wrote:
>
>
> On Sat, May 8, 2021 at 11:58 AM Pablo Galindo Salgado
> wrote:
>
>> Hi Brett,
>>
>> Just to be clear, .pyo files have not existed for a while:
>>> https://w
ngs and I think is overkill.
On Sat, 8 May 2021 at 21:45, Gregory P. Smith wrote:
>
> On Sat, May 8, 2021 at 1:32 PM Pablo Galindo Salgado
> wrote:
>
>> > We can't piggy back on -OO as the only way to disable this, it needs
>> to have an option of its own. -OO is
hat the reasons to deactivate this option exist, but I expect them
to be very rare, I would prefer to maximize simplicity and maintainability.
On Sat, 8 May 2021 at 21:50, Pablo Galindo Salgado
wrote:
> > I don't think the optional existence of column number information needs
> a
Pablo Galindo Salgado wrote:
> >> We can't piggy back on -OO as the only way to disable this, it needs to
> >> have an option of its own. -OO is unusable as code that relies on
> "doc"
> >> strings as application data such as http://www.dabeaz.com/p
object (None), but that's much much better than something that scales
with the
number of instructions :)
What's your opinion on this?
On Sat, 8 May 2021 at 21:45, Gregory P. Smith wrote:
>
> On Sat, May 8, 2021 at 1:32 PM Pablo Galindo Salgado
> wrote:
>
>> > We c
wrote:
>
>
> On Sat, May 8, 2021 at 2:09 PM Pablo Galindo Salgado
> wrote:
>
>> > Why not put in it -O instead? Then -O means lose asserts and lose
>> fine-grained tracebacks, while -OO continues to also
>> strip out doc strings.
>>
>> What if so
-tracebacks/8629
To avoid splitting the discussion, *please redirect your comments there*
instead of replying to this thread.
Thanks!
Regards from sunny London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send
That is going to be very hard to read, unfortunately. Especially when the
line is
not simple. Highlighting the range is quite a fundamental part of the
proposal and
is driven by the great welcoming of highlighting ranges for syntax errors,
which many
users have reached to say that they find it extr
thon 3.10.
Thanks for helping to make Python3.10 a great release.
Regards from sunny London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.py
I think it would be better to provide an API like PEP 626 and not
restrict the internal format used.
Indeed, that is what we are doing. Check
https://www.python.org/dev/peps/pep-0657/#id10
Cheers,
Pablo Galindo Salgado
On Mon, 17 May 2021 at 14:17, Mark Shannon wrote:
> Hi everyone,
>
&
P.S. We will add "using a single caret" to the "rejected ideas section"
with some rationale.
On Mon, 17 May 2021, 14:28 Pablo Galindo Salgado,
wrote:
> Hi Mark,
>
> Thanks for your useful feedback. Some comments:
>
> > 1. Errors spanning multiple lines.
&
e all this information is lost,
although one could argue that then is not extremely useful...
Regards from sunny London,
Pablo Galindo Salgado
On Tue, 18 May 2021, 01:43 Nathaniel Smith, wrote:
> On Mon, May 17, 2021 at 6:18 AM Mark Shannon wrote:
> > 2. Repeated binary operations on the s
;t in the Python API (to preserve
all possible information about the original code), so this complicates
quite a lot the API to get this, as `ast.parse` is not enough to get the
original tree.
On Tue, 18 May 2021 at 08:53, Pablo Galindo Salgado
wrote:
> Hi Nathaniel,
>
> Thanks a lot for y
on't get assigned (and the parser doesn't have an easy way to know how
many IDs has thrown away). This forces us to either use something
bigger than an integer (probably a size_t) or to deal with overflow.
On Tue, 18 May 2021 at 10:23, Pablo Galindo Salgado
wrote:
> Hu, actually an
to check this).
On Tue, 18 May 2021 at 13:25, Pablo Galindo Salgado
wrote:
> Yet another problem that I found:
>
> One integer is actually not enough to assign IDs. One unsigned integer can
> cover 4,294,967,295 AST nodes, but is technically possible
> to have more than that in a
doesn't give more
functionality.
On Tue, 18 May 2021 at 13:47, Pablo Galindo Salgado
wrote:
> > One integer is actually not enough to assign IDs.
>
> Actually, disregard this particular problem. I think that we could
> perfectly stop assigning IDs if we reach the overflow limi
gt;>> ast.dump(ast.parse("continue"))
'Module(body=[Continue()], type_ignores=[])'
>>> ast.dump(ast.parse("await x"))
"Module(body=[Expr(value=Await(value=Name(id='x', ctx=Load(],
type_ignores=[])"
On Thu, 20 May 2021 at 03:22, Nathan
, 21 May 2021 at 01:55, Nathaniel Smith wrote:
> On Wed, May 19, 2021 at 7:28 PM Pablo Galindo Salgado
> wrote:
> >>
> >> Excellent point! Do you know how reliable this is in practice, i.e.
> >> what proportion of bytecode source spans are something you can
> >
ta release.
Thanks for your help,
Regards from stormy London,
Pablo Galindo Salgado
___
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.
/all/#/builders/693/builds/21
https://buildbot.python.org/all/#/builders/677/builds/22
https://buildbot.python.org/all/#/builders/669/builds/22
...
You can access the release dashboard for the buildbots here:
https://buildbot.python.org/all/#/release_status
On Mon, 24 May 2021 at 23:45, Pablo
> - Cython doesn't work because of _PyGen_Send change [1]
I think this is fixed on the latest cython (0.29.23)
On Wed, 26 May 2021 at 01:05, Neil Schemenauer
wrote:
> On 2021-05-04, Łukasz Langa wrote:
> > We strongly encourage maintainers of third-party Python projects
> > to test with 3.10 d
Hi,
Friendly reminder that the Python3.10 beta 2 is still blocked on:
https://bugs.python.org/issue42972
Thanks for your help,
Regards from stormy London,
Pablo Galindo Salgado
On Mon, 24 May 2021 at 23:54, Pablo Galindo Salgado
wrote:
> Small correction:
>
> https://bugs.p
After fighting with some release blockers, implementing a bunch of GC
traversal functions, and fixing some pending reference leaks, we finally
have Python 3.10.0 beta 2 ready for you! Thanks to everyone that helped to
unblock the release!
https://www.python.org/downloads/release/python-3100b2/
#
Summer is almost here (at least in half of the planet) and Python 3.10 is
finishing baking in the oven. For those of you that want to taste it before
is finally ready (and if you are a library developer, you certainly do!)
you can have the second-to-last beta now, but be careful as is still very
ho
ould be beneficial and could help to avoid
misunderstandings. It was decided that some devguide changes could be
proposed.
Regards from rainy London.
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an ema
> I was expected the announcement of a BDFL delegate for PEP 657, as the
author is a steering council member.
Just to clarify this: as I was the author I didn't get to vote on the
approval or rejection of the PEP. Also, there is nowhere that I know where
this situation requires a BDFL delegate lik
econds of difference.
On Tue, 29 Jun 2021 at 16:39, Pablo Galindo Salgado
wrote:
> > I was expected the announcement of a BDFL delegate for PEP 657, as the
> author is a steering council member.
>
> Just to clarify this: as I was the author I didn't get to vote on the
> appro
hem into a single table,
then you are more than welcome to make a Pull Request improving upon the
initial version.
Regards from cloudy London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an em
1 - 100 of 243 matches
Mail list logo
