* Erik, could you propose a change to the PEP text?
I just created https://github.com/python/peps/pull/2555 to address these issues.
-Erik
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le
ase send any comments there.
Any feedback would be appreciated!
Thanks,
Erik
___
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
My apologies! Must be an issue with my email client rendering.
Erik
On Mon, 11 Oct 2021, Guido van Rossum wrote:
On Mon, Oct 11, 2021 at 3:22 PM Erik Demaine wrote:
On Mon, 11 Oct 2021, Guido van Rossum wrote:
No, I didn't write that, Lukasz did.
> I always f
on't care"?
I think it'd be natural for types constructed via `typeof` to include the
argument names; I'd intend for an object "just like" this one. But you could
imagine another type operator that drops details like this, e.g.
`typing.forget_argument_names(typin
e
is it guarantees that the two grammars (and ast) remain synchronized.
2. PyPy
3. 3rd party library (e.g., my own repo)
Let me know what you think would be best.
Erik
--
Erik Demaine | edema...@mit.edu | http://erikdemaine.org/
___
Python-Dev ma
On Tue, Oct 2, 2018 at 8:54 PM Michael Felt wrote:
>
>
>
> On 10/2/2018 4:45 PM, Erik Bray wrote:
> > Michael, if there are any PRs you want to point me to that I might be
> > able to help review please do.
> A little trick I learned:
> https://github.com/python/cpy
On Tue, Oct 2, 2018 at 6:41 PM Simon Cross
wrote:
>
> Are there any core devs that Michael or Erik could collaborate with?
> Rather than rely on adhoc patch review from random core developers.
>
> Michael and Eric: Question -- are you interested in becoming core
> developer
On Tue, Oct 2, 2018 at 3:53 AM Tres Seaver wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 10/01/2018 06:41 PM, Michael Felt wrote:
>
> > And, while you may not give a damn about anything other than Windows,
> > macos and/or Linux - there are other platforms that would like a
> >
On Wed, Sep 5, 2018 at 4:32 PM Paul Moore wrote:
>
> On Wed, 5 Sep 2018 at 14:47, Zachary Ware
> wrote:
> >
> > On Wed, Sep 5, 2018 at 6:23 AM Antoine Pitrou wrote:
> > > On Wed, 5 Sep 2018 11:03:48 +0100
> > > Paul Moore wrote:
> > > > On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote:
> > >
On Fri, Aug 10, 2018 at 6:49 PM Steve Dower wrote:
>
> On 10Aug2018 0354, Erik Bray wrote:
> > Thanks! I'm not sure what you mean by "on other OS's" though. Do you
> > mean other OS's that happen to use Windows-style PE/COFF binaries?
> > Bec
On Thu, Aug 9, 2018 at 7:21 PM Steve Dower wrote:
>
> On 09Aug2018 0818, Erik Bray wrote:
> > On Mon, Aug 6, 2018 at 8:11 PM Eddie Elizondo wrote:
> >> 3) Special case the initialization of PyType_Type and PyBaseObject_Type
> >> within PyType_Ready to now make all
On Mon, Aug 6, 2018 at 8:11 PM Eddie Elizondo wrote:
>
> Background:
>
> Through the implementation of an alternate runtime I've been poking around
> some of the class initialization routines and I found out that there was a
> subtle bug with PyType_Ready and the header initializer PyVarObject_H
On Mon, Jul 30, 2018 at 5:26 PM Nick Coghlan wrote:
>
> On 26 July 2018 at 02:13, Erik Bray wrote:
> > I think a new approach that might be more practical for actually
> > getting this platform re-supported, is to go ahead and add a CI build,
> > and just skip all kn
On Sat, Jul 21, 2018 at 6:30 PM Jeroen Demeyer wrote:
>
> Hello,
>
> I finally managed to get some real-life benchmarks for why we need a
> faster C calling protocol (see PEPs 576, 579, 580).
>
> I focused on the Cython compilation of SageMath. By default, a function
> in Cython is an instance of
On Wed, Nov 8, 2017 at 3:39 PM Erik Bray wrote:
>
> Hi folks,
>
> As some people here know I've been working off and on for a while to
> improve CPython's support of Cygwin. I'm motivated in part by a need
> to have software working on Python 3.x on Cy
On Mon, Apr 16, 2018 at 4:49 AM, Shell Xu wrote:
> Well, I'm not sure weather or not this is what you're looking for, but pep-8
> (https://www.python.org/dev/peps/pep-0008/) suggest like this:
>
> For Python 3.0 and beyond, the following policy is prescribed for the
> standard library (see PEP 313
On Tue, Dec 26, 2017 at 3:00 PM, Benjamin Peterson wrote:
> I imagine Cython already takes care of this?
This appears to have a distinct purpose, albeit not unrelated to
Cython. The OP's program would generate boilerplate C code for
extension types the rest of which would perhaps be implemented
Sorry, completely fat-fingered my autocomplete and sent to to wrong list.
On Tue, Dec 19, 2017 at 12:12 PM, Erik Bray wrote:
> Hi all,
>
> I have a ticket [1] that's hung up on a failure in one doctest in the
> form of sage.doctest.sources.FileDocTestSource._test_enough_doctes
standing.
I would propose to just remove the test. If there are any actual
regressions it's responsible for catching then more focused regression
tests should be written for those cases.
Erik
[1] https://trac.sagemath.org/ticket/24261#comment:24
_
On Wed, Nov 8, 2017 at 5:28 PM, Zachary Ware
wrote:
> On Wed, Nov 8, 2017 at 8:39 AM, Erik Bray wrote:
>> a platform--in particular it's not clear when a buildbot is considered
>> "stable", or how to achieve that without getting necessary fixes
>> merged int
but before this gets too long I'd just like to float the
idea of having the discussion in the first place. It's also not
exactly clear to me how to meet the standards in PEP 11 for supporting
a platform--in particular it's not clear when a buildbot is considered
"stable", or h
On Fri, Sep 8, 2017 at 4:37 PM, Nick Coghlan wrote:
> On 8 September 2017 at 00:30, Masayuki YAMAMOTO
> wrote:
>> Hi folks,
>>
>> I submit PEP 539 third draft for the finish. Thank you for all the advice
>> and the help!
>
> Thank you Erik & Yamamoto-san f
On Thu, Aug 31, 2017 at 10:16 AM, Masayuki YAMAMOTO
wrote:
> Hi python-dev,
>
> Since Erik started the PEP 539 thread on python-ideas, I've collected
> feedbacks in the discussion and pull-request, and tried improvement for the
> API specification and reference implementat
On 16/06/17 12:32, Robert Vanden Eynde wrote:
Hello, I would like to propose an idea for the language but I don't know
where I can talk about it.
Robert, I have replied to this on the "python-ideas" ML.
Regards, E.
___
Python-Dev mailing list
Python
On 24/05/17 21:56, Ben Hoyt wrote:
But interesting to know you got not much of a
speedup!
I think that improvements at the hardware level in terms of
parallelizing instruction and data fetching (and branch prediction) in
even the cheapest processors these days have largely trivialized the
a
Hi Ben,
On 24/05/17 19:07, Ben Hoyt wrote:
I'm not proposing to do this yet, as I'd need to benchmark to see how
much of a gain (if any) it would amount to, but I'm just wondering if
there's any previous work on this kind of thing. Or, if not, any other
thoughts before I try it?
This is exac
make sense to rename them--e.g. have PEP 539 and
PEP 540 trade places, since PEP 539 has nothing to do with this and is
awkwardly nestled between them. Or would that only confuse matters at
this point?
Thanks,
Erik
___
Python-Dev mailing list
Python-De
ure at my university). I
wanted to wait until the tests on Cygwin were more stable, but since
you allow unstable buildbots I could include it among them for now.
Is the buildbot setup documentation on the wiki page still accurate?
Thanks,
Erik
___
Pytho
promises anyone will have time for mentorship, but I'd be willing to
point you in the right direction. I'm not a core developer but I know
Python internals reasonably well and might be able to help *depending*
on the issue.
Best,
Erik
[1] http://bugs.python.org/
Hi.
I'm looking at stuff proposed over on Python-Ideas, and I'd appreciate
some pointers as to the basics of how C-level objects are generally
compared in Python 3.
The issue is related to the performance of PyObject_RichCompare. I got
to the point where I was trying to work out what was the
On 17/01/17 06:32, INADA Naoki wrote:
With designated initializer, it becomes:
0, /* tp_free */
+.tp_fastcall = (fastternaryfunc)attrgetter_call,
};
It's readable, and easy to review.
FWIW, I dislike mixing the two forms (because it still prevents th
this file in the first place. In other
words, why not install $LDLIBRARY regardless?
Thanks,
Erik
[1] https://hg.python.org/cpython/file/496e094f4734/Makefile.pre.in#l1097
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
Hi Nick,
On 29/12/15 02:46, Nick Coghlan wrote:
1. The interpreter's bytecode generation is inconsistent with the
implementation of the eval loop
Essentially, this was my problem. I'd neglected to add the reference to
TARGET_NEW_OP2 to Python/opcode_targets.h (so staring hard at the op
gener
On 28/12/15 00:41, Guido van Rossum wrote:
Can you show the diffs you have so far? Somebody's got to look at your code.
Sounds like it's not a well-known symptom then. I agree, but that
Somebody should be me (initially, at least) - I don't want to waste
other people's time if I made a silly m
Thanks for your help so far (I'm experimenting with the peephole
optimizer - hence my question before as I was trying to work out how to
know what the small integer hard-coded offsets should be when looking
ahead in the bytecode).
I've successfully added a new opcode (generated by the optimiz
On 26/12/15 23:10, Joe Jevnik wrote:
All arguments are 2 bytes, if there needs to be more, EXTENDED_ARG is used
OK, got it - many thanks.
E.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Hi Joe,
On 26/12/15 22:36, Joe Jevnik wrote:
The number and meaning of the arguments are documented in the dis
module: https://docs.python.org/3.6/library/dis.html
OK - I *did* find that, but perhaps didn't immediately understand what
it was telling me.
So, something documented as "OP_CODE"
Hi.
Looking at ceval.c and peephole.c, there is - of course - lots of
specific hard-coded knowledge of the bytecode (e.g., number of operands
and other attributes). I'd like to experiment at this level, but I can't
seem to find a reference for the bytecode.
Is there the equivalent of somethi
th, I've had good luck compiling *most* extension
modules on Windows using the gcc from MinGW-w64.
The big notable exception was that last time I tried compiling Numpy
with it I got a segfaulting Numpy. But I never had a chance to
investigate why or if it's fixable. My own extension mod
Hi.
I realise I'm coming late to the party on this, but I have a question
about something I don't think the PEP makes clear.
When is the bytecode for the embedded expressions created?
Is it when the source code is parsed, or at runtime when the f-string is
evaluated?
If the latter, the
e from, in my mind, making more sense philosophically, using
specialized assert functions for this has absolutely none of the
spelling ambiguities or other problems of the magic methods.
I'm -0 on removing the assret_ methods unless no one is using them
yet. I don't care if they'
nt to follow
it, but let's please avoid judgments on entire mailing lists and, by
extension, the people holding conversations there.
Thanks,
Erik
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
Baldomero,
Veo que perteneces al estado de Puebla, México, existe la lista de Python
México https://mail.python.org/mailman/listinfo/python-mx, habemos varios
de Puebla que te podemos apoyar.
Saludos.
El 14 de abril de 2015, 19:50, Baldomero Perez martinez <
bpma...@yahoo.com.dmarc.invalid.mx> e
fileio_readall is renamed to
io_FileIO_readall_impl or whatever we need to also go through and fix
any references to fileio_readall. Should be easy enough, but I wonder
if there are any broader side-effects of this. Might it be safer for
the first round to keep the existing function names?
Erik
___
ath_importer_cache[dirname].invalidate_caches()
But that's a bit onerous considering that this wasn't even necessary
before 3.3. There should be an easier way to do this, as there's no
sense in invalidating all the directory caches
(such as bento) so if we have better support for a
feature like that it's not necessary to "bless" any preferred tool.
Erik
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Fri, Sep 14, 2012 at 1:57 PM, Daniel Holth wrote:
> On Fri, Sep 14, 2012 at 1:43 PM, Erik Bray wrote:
>> On Fri, Sep 14, 2012 at 12:30 PM, Daniel Holth wrote:
>>> Add to metadata 1.3:
>>>
>>> Description-File: README(\..+)?
>>>
>>> Mea
in a subdirectory of .dist-info could be a
reasonable workaround.
Erik
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Thu, Sep 13, 2012 at 5:38 AM, Antoine Pitrou wrote:
> On Thu, 13 Sep 2012 11:14:17 +1000
> Nick Coghlan wrote:
>> On Thu, Sep 13, 2012 at 8:43 AM, R. David Murray
>> wrote:
>> > When the removal was being pondered, the possibility of keeping certain
>> > bits that were more ready than others
her build systems like waf, or even provide
an entry-point to meta-build systems like bento. Am I making sense?
Erik
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ot
containing importable code. Not sure what the best approach to that
would be, especially since one of the goals of this PEP seems to be to
avoid marker files.
Erik
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Wed, Sep 2, 2009 at 10:35 AM, James Y Knight wrote:
> On Sep 2, 2009, at 6:15 AM, Rob Cliffe wrote:
>
>> So - the syntax restriction seems not only inconsistent, but pointless; it
>> doesn't forbid anything, but merely means we have to do it in a slightly
>> convoluted (unPythonesque) way. So p
ach type
created with this metatype, such as is intended by the JObjectMeta
struct?
Best regards
Erik Groeneveld
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
m not properly initialized. If I call
PyString_Str(self) in JObjectMeta_init, it seg faults. De Python code
that initiates this is:
class MyJObject(JObject):
pass
Below is the complete, contained code of the extension.
Thanks in advance,
Erik Groeneveld
#include
/*** JObjec
orge tracker is so hard
to use that you really don't want to use it". Yeah, it's kind of
ironic that roundup isn't running a roundup tracker..
Regards,
\EF
- --
Erik Forsberg http://efod.se
GPG/PGP Key: 1024D/0BAC89D9
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.
their Roundup code
> in svn so they need commit access.
Now when that's clarified, here's my data:
Public SSH key: http://efod.se/about/ptkey.pub
First.Lastname: erik.forsberg
I'd appreciate if someone with good taste could tell us where in the
tree we should add our code :-).
te count and would
> never be negative.
>
> I've CC'd Erik de Castro Lopo, whose word is more definitive than
> random websites.
libsndfile treats the chunk lengths as unsigned int.
Erik
--
+--
m will make it pretty
obvious.
Erik
--
+---+
Erik de Castro Lopo [EMAIL PROTECTED] (Yes it's valid)
+---+
"Neither noise nor information is predictable.&qu
mitation in
> wave files?
No.
> Multiple chunks?
No.
Other file formats allow file sizes larger than 4Gig. I would suggest
you have a look at AU and W64.
Erik
--
+---+
Erik de Castro Lopo [EM
is copyrighted, it's not truly open. However,
it can be freely used and redistributed, even commercially."
Huh? Where did THAT come from? You might argue the merits of Python
being associated with Perl/PHP, but it's a fact that it i
60 matches
Mail list logo
