rate
existing code to the stable ABI.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
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
I don't care about the deprecation either way. But can we fix the
individual decorators so both orders work? Even if it requires a special
case in the code, it seems worthwhile to remove a subtle user-visible
footgun.
On Wed, May 15, 2019, 12:39 Ethan Furman wrote:
> In issue 11610* abstractclas
hese exceptions into a file (the output on the Python test suite
> is interesting!). It also becomes trivial to reimplement Thomas's idea
> (kill the process):
What happens if the hook raises an exception?
-n
--
Nathaniel J. Smith -- https://vorpus.org
_
On Thu, May 16, 2019, 09:07 Steve Dower wrote:
>
> Actually, if the default implementation prints the exception message,
> how is this different from sys.excepthook? Specifically, from the point
> of customizing the hooks.
>
sys.excepthook means the program has fully unwound and is about to exit
exception that triggered it?
A clever hook might want the actual object, so it can pretty-print it,
or open an interactive debugger and let it you examine it, or
something. Morally this is similar to calling repr(obj), but it
doesn't literally call repr(obj).
-n
--
Nat
PyPI even if
the stdlib version were public, since the PyPI version can be updated
independently of the host Python.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
aisable() cannot avoid having 3 variables
> (exc_type, exc_value, exc_tb), since they are not consistent as you
> may expect.
I'm actually fine with it having three arguments -- even if it's
technically unnecessary, it's currently 100% consistent across these
low-level APIs,
rs between different coordinate systems. I don't see how that could
> be done via Pillow (which AFAICT only converts complete images).
> RGB<->HSV<->HLS conversion seems to be not available (or not obvious) in
> colorspacious.
Correct, colorspacious doesn't support HSV o
r quickstart example at the top of their README). Same with
flask, django, and probably a bunch of other frameworks. It's *very*
widely used.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail
notice in the docs saying
that it's unmaintained and any use is at your own risk. It's not a
pleasant thing to do, but if that's the reality of the situation then
it's probably better to be up front about it than to stick our fingers
in our ears and waste folks time with spurious te
On Wed, May 22, 2019, 12:14 Sean Wallitsch
wrote:
> Dear python-dev,
>
> I'm writing to provide some feedback on PEP-594, primarily the proposed
> deprecation and reason for the removal of the aifc and audioop libraries.
>
> The post production film industry continues to make heavy use of AIFFs,
On Wed, May 22, 2019, 04:32 Christian Heimes wrote:
> On 22/05/2019 12.19, Steven D'Aprano wrote:
> > I don't think this PEP should become a document about "Why you should
> > use PAM". I appreciate that from your perspective as a Red Hat security
> > guy, you want everyone to use best practices
On Fri, May 24, 2019, 08:08 Ben Cail wrote:
>
> Why not have the PSF hire someone (or multiple people) to be paid to
> work on the maintenance burden? This could be similar to the Django
> fellows:
> https://www.djangoproject.com/fundraising/#who-is-the-django-fellow. It
> seems like a good thing
ourse to discuss some "what if" scenarios
here, in the hopes it will help us make more informed decisions:
https://discuss.python.org/t/1738
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
On Sat, May 25, 2019, 07:38 Guido van Rossum wrote:
> This looks great.
>
> I only have two nits with the text.
>
> First, why is the snapshot called a "dynamic snapshot"? What exactly is
> dynamic about it?
>
It's dynamic in that it can spontaneously change when certain other events
happen. For
nd so far seem pretty minor, on par
with what we do in every point release. (In fact, in 3/4 of the cases
I looked at, [snapshot] is actually what users seemed to trying to use
in the first place.)
For [proxy] versus [snapshot], a lot depends on what we think of
changing the semantics of exe
On Mon, May 27, 2019 at 9:16 AM Guido van Rossum wrote:
>
> I re-ran your examples and found that some of them fail.
>
> On Mon, May 27, 2019 at 8:17 AM Nathaniel Smith wrote:
[...]
>> The interaction between f_locals and and locals() is also subtle:
>>
>> def f(
oxy] adds "justified" action-at-a-distance, and removes "spooky"
action at a distance.
[snapshot] gets rid of both kinds of action-at-a-distance (at least in
function scope).
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python
lobal it does
a direct lookup in the globals object, so it's important that we do
this lookup as fast as possible, and forcing the globals object to be
a actual dict allows some optimizations. For locals, though, we
usually use the "fast locals" mechanism and the mapping object is
most
On Tue, May 28, 2019 at 6:48 PM Greg Ewing wrote:
>
> Nathaniel Smith wrote:
> > - [proxy]: Simply return the .f_locals object, so in all contexts
> > locals() returns a live mutable view of the actual environment:
> >
> > def locals():
> > return get_
n we covered our sin with
new patches, until Simplicity was obscured.
(The current design does makes sense, but you really have to look at
it as a hard-fought compromise between the elegant original design
versus ~30 years of real-world demands. And hey, it could be worse –
look at the fun Intel&#
ace for b1, and tidying up the documentation and comments for b2.
>
> Cheers,
> Nick.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> htt
to do that anyway,
and having it formally written down might reassure people. It might
also encourage more people to actually try out the prototypes if we
make it very clear that they're going to be asked for feedback.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
quires a proper deprecation
> period, and that hasn't happened.
> Maybe .pyc files need to be extended to store a list of syntax-related
> DeprecationWarnings and SyntaxWarnings, that are re-issued every time the
> .pyc is loaded? Then we'd at least have the technical capab
https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/RDXLCH22T2EZDRCBM6ZYYIUTBWQVVVWH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
Nathaniel J. Smith -- https://vorpus.
On Thu, Jan 28, 2021 at 9:03 PM Gregory P. Smith wrote:
>
> On Thu, Jan 28, 2021 at 10:52 AM Charalampos Stratakis
> wrote:
>>
>>
>>
>> - Original Message -
>> > From: "Mark Shannon"
>> > To: "Python Dev"
>>
r with ExceptionGroups. I think this would happen if you're
implementing Trio, or implementing a higher-level backport library for
catching ExceptionGroups, something like that. So this only applies to
like half a dozen users total, but they are important users :-).)
-n
--
Nathaniel J. Smit
ould be good enough is
like saying that bare 'except:' is good enough for regular
non-concurrent Python (after all, you can always do an isinstance
check inside the 'except' block and re-raise the ones you don't want,
right?), and that 'except ' is a poin
an obvious way to do that, that works for
all functions, not just ones that happen to raise ExceptionGroups:
try:
f = obj.func
except AttributeError:
...
try:
f()
except ...:# or except *...:
...
-n
--
Nathaniel J. Smith -- https://vorpus.org
_
any changes) to the proposed
> semantics of except*, hopefully this is because everyone thought they are
> sensible.
>
> Irit, Yury and Guido
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe sen
On Mon, Apr 5, 2021 at 9:48 AM Irit Katriel wrote:
> On Mon, Apr 5, 2021 at 11:01 AM Nathaniel Smith wrote:
>> - I'm uncomfortable with how in some contexts we treat EG's as placeholders
>> for the contained exceptions, and other places we treat them like a single
I'm not even sure that this *is* nominal typing. You could just as
well argue that "the operation `isinstance(..., Sequence)` returns
`True`" is just another of the behavioral constraints that are
required to quack like a sequence.
-n
--
Nathaniel J. Smith -- https://vorpus.org
__
hould probably be handled the same
way as a ValueError. I have no idea what a KeyError([ValueError])
would mean. Is that a KeyError or a ValueError? Adding flexibility
doesn't necessarily make things simpler :-)
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
On Tue, Apr 20, 2021 at 3:15 AM Irit Katriel wrote:
> On Tue, Apr 20, 2021 at 2:48 AM Nathaniel Smith wrote:
>>
>>
>> The problem is that most of the time, even if you're using concurrency
>> internally so multiple things *could* go wrong at once, only one thing
On Wed, Apr 21, 2021 at 4:50 PM Guido van Rossum wrote:
> On Wed, Apr 21, 2021 at 3:26 PM Nathaniel Smith wrote:
>> Sure. This was in my list of reasons why the backwards compatibility
>> tradeoffs are forcing us into awkward compromises. I only elaborated
>> on it b/c i
nto? Or... something?
-- Forwarded message -
From: Hoi lam Poon
Date: Fri, Apr 23, 2021, 02:01
Subject: Re: [Python-Dev] Re: PEP 654: Exception Groups and except* [REPOST]
To: Nathaniel Smith
Stop pretending, I can definitely get the key control file, your working
group, all past acti
On Fri, Apr 23, 2021 at 2:45 AM Chris Angelico wrote:
>
> On Fri, Apr 23, 2021 at 6:25 PM Nathaniel Smith wrote:
> > The main possibility that I don't think we've examined fully is to
> > make 'except' blocks fire multiple times when there are multiple
>
e for sake
> of async def" when native coroutines ultimately depend on a generator
> to be driven by the event loop.
>
> What am I missing?
>
> Perhaps in asyncio the generator magic is now written in C, but as
> Nathaniel J. Smith points out, Trio and Curio both use
On Fri, Apr 23, 2021 at 4:08 AM Irit Katriel wrote:
>
> On Fri, Apr 23, 2021 at 9:22 AM Nathaniel Smith wrote:
>> I'm not trying to filibuster here -- I really want some form of EGs to
>> land.
>
> I'm very glad to hear that. It's been hard to know wher
no need for conflict :-).
Irit, Yury, would you be interested in co-authoring a PEP for the
"flat EG" approach? Basically trying to set down the best possible
version of each approach, so that we can put them next to each other?
-n
--
On Thu, May 6, 2021 at 2:17 AM Nathaniel Smith wrote:
>
> On Thu, Apr 29, 2021 at 9:14 AM Yury Selivanov
> wrote:
> > Nathaniel, at this point it's clear that this thread somehow does not
> > help us understand what you want. Could you please just write your own
>
store a reference to the
file + offset to load them lazily on demand. No need for mmap.
Could also store them in memory, but with some cheap compression
applied, and decompress on access. None of these get accessed often.
-n
--
Nathaniel J. Smith -- https://vorpus.org
_
eger
per bytecode offset). And it would allow for arbitrarily rich traceback
display.
(I guess in theory you could make this even cheaper by using it to replace
lnotab, instead of extending it. But I think keeping lnotab around is a
good idea, as a fallback for cases where you can't find
to do this would be to make the
traceback or code object have a pointer back to the function object.
See also https://bugs.python.org/issue12857.
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.org
To unsubscrib
it x"))
> "Module(body=[Expr(value=Await(value=Name(id='x', ctx=Load(],
> type_ignores=[])"
Ah, nice! I guess I was confused by memories of the behavior in 3.6
and earlier, where 'await' was a pseudokeyword:
❯ docker run -it --rm python
imea are
allowed to participate in OSS projects, just not give GitHub money.
(They do disallow use by North Koreans and "Specially Designated
Nationals".)
It is even possible for the PSF to do better without breaking the law?
I'm not an expert in this area at all, so happy to be educat
() semantics is an actual language
change, even though it may not affect much real code, so that's what
stands out for me.
I *think* (please correct me if I'm wrong) that what that calls
[PEP-minus-tracing] is now corresponds to the current PEP draft, and
[proxy] corresponds to Mark's d
/message/TX44HOPXBSHDPA5ZXCAUGWTQDHCTD723/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@p
s?
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
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://m
d 3.10
isn't even out yet. So it's certainly possible to do, even for
projects with a tiny fraction of Tensorflow's engineering budget.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.
hon's
ABI stability or release cadence.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
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.
TF::Lock. Did you try
alternatives like that? If so, I assume they didn't work well -- can
you give more details?
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to p
Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14)
system, but using a different sysroot (that is, a separate
/usr/include, /usr/lib, etc., not the real one for my system).
I have shell script wrappers around GCC and its various tools that
invoke it with the right paths to fo
On Fri, 2013-05-31 at 01:21 -0700, Ned Deily wrote:
> In article <1369986770.4119.43.camel@homebase>,
> Paul Smith wrote:
>
> > Hi all. I'm trying to build Python 2.7.5 on a GNU/Linux (Linux Mint 14)
> > system, but using a different sysroot (that is, a separate
iled
output. And Cygwin GCC isn't even real Windows. Maybe switching to
Clang will make sense in 3.7 but that's a long ways off...
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
While I
> think this is a fine idea, the exact spelling, semantics, and per-platform
> implementation of these functions is far from settled, and nobody is
> proposing that we do something like that for 3.5.
We already have a function for non-crypto-strength pseudo-random bits:
rando
an error in 3.6?
(And it would probably be good even in the long run to issue a
prominent warning if hash seeding fails.)
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
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
On Thu, Jun 9, 2016 at 8:11 PM, Larry Hastings wrote:
>
> On 06/09/2016 07:58 PM, Nathaniel Smith wrote:
>
> I suspect the crypto folks would be okay with pushing this back to
> 3.6, so long as the final resolution is that os.urandom remains the
> standard interface for, as
On Jun 11, 2016 11:13 PM, "Theodore Ts'o" wrote:
>
> On Sat, Jun 11, 2016 at 05:46:29PM -0400, Donald Stufft wrote:
> >
> > It was a RaspberryPI that ran a shell script on boot that called
> > ssh-keygen. That shell script could have just as easily been a
> > Python script that called os.urandom
sing getrandom() in blocking mode, so they need to
patch that regardless, and could just as easily make it robust against
blocking /dev/urandom at the same time. I don't understand the RPM
world as well, but I can't find any evidence that Fedora or SuSE ship
systemd-cron at all.)
-n
On Jun 13, 2016 6:16 PM, "MRAB" wrote:
>
> On 2016-06-14 01:47, Larry Hastings wrote:
>>
>> On 06/13/2016 05:05 PM, MRAB wrote:
>>>
>>> This could be avoided by expanding the items to include the index of
>>> the 'previous' and 'next' item, so that they could be handled like a
>>> doubly-linked li
PYTHONWARNINGS=error::NoEntropyAtStartupWarning
(I guess the way to implement this would be for the SipHash
initialization code -- which runs very early -- to set some flag, and
then we expose that flag in sys._something, and later in the startup
sequence check for it after the warnings module
On Wed, Jun 15, 2016 at 10:25 PM, Theodore Ts'o wrote:
> On Wed, Jun 15, 2016 at 04:12:57PM -0700, Nathaniel Smith wrote:
>> - It's not exactly true that the Python interpreter doesn't need
>> cryptographic randomness to initialize SipHash -- it's more tha
n practice, your proposal means that ~all existing code that uses
os.urandom becomes incorrect and should be switched to either secrets
or random. This is *far* more churn for end-users than Nick's
proposal.
...Anyway, since there's clearly going to be at least one PEP about
this, maybe we should stop rehashing bits and pieces of the argument
in these long threads that most people end up skipping and then
rehashing again later?
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
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
On Jun 16, 2016 1:23 AM, "Stefan Krah" wrote:
>
> Nathaniel Smith pobox.com> writes:
> > In practice, your proposal means that ~all existing code that uses
> > os.urandom becomes incorrect and should be switched to either secrets
> > or random. This is *far*
On Jun 16, 2016 10:01 AM, "David Mertz" wrote:
> Python 3.6 is introducing a NEW MODULE, with new APIs. The 'secrets'
module is the very first time that Python has ever really explicitly
addressed cryptography in the standard library.
This is completely, objectively untrue. If you look up os.ura
t data on this to
confirm that it isn't a big issue, but intuitively, code like
WeirdFoo.__init__ is vanishingly rare, and this is just a best-effort
optimization anyway. Catching 98.9% of cases is good enough.
Is there something I'm missing here? Is this your option #3?
-n
--
Nathaniel J. Smi
On Jul 3, 2016 1:45 PM, "Paul Moore" wrote:
>
[...]
> Furthermore, pip/setuptools are just getting to the point of allowing
> for dependencies conditional on Python version. If independent stdlib
> releases were introduced, we'd need to implement dependencies based on
> stdlib version as well - co
y
running code like my example on PyPy very soon now.
tl;dr: AFAICT this revision of PEP 525 is enough to make it work
reliably on CPython, but I have serious concerns that it bakes a
CPython-specific design into the language. I would prefer a design
that actually aims for "level 2" clean
ffects the language spec bit.
(OTOH it doesn't matter that much anyway... the language spec is
definitely a useful thing, but it's largely aspirational in practice
-- other implementations target CPython compatibility more than they
target language spec compatibility.)
-n
--
Nathaniel J. S
build on gcc 4.4"
should be a fine rule that works for everyone. But I guess we probably
also want a CentOS 5+gcc 4.1 buildbot for testing 3.5 point releases.
-n
[1] https://gcc.gnu.org/c99status.html
[2] "The [different versions] of inlining behave similarly ... when
the inline
On Thu, Oct 6, 2016 at 10:10 PM, Nathaniel Smith wrote:
[...]
> And in practice this almost certainly doesn't matter -- the only
> reason people jump through hoops to get gcc 4.8 is for its improved
> C++ support. I just tried my c99 test file on CentOS 5's default gcc
> 4.
On Sat, Oct 8, 2016 at 9:23 AM, Steven D'Aprano wrote:
> On Thu, Oct 06, 2016 at 10:10:54PM -0700, Nathaniel Smith wrote:
>
>> The reason this matters is that the official vendor compiler on RHEL 5
>> is gcc 4.1, but there's also a separately-distributed version of gcc
he's suddenly
confusing us all by emphasizing that when you borrow a reference you
should know who you're borrowing it from, so you know which lock to
hold.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev
etter yet Victor Stinner's perf package:
https://perf.readthedocs.io/
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.pyth
, even for running exactly the same
code. I'm not sure what's going on, but it's weird. Making these kinds
of measurements is much more complicated than it looks and you really
need to use something like timeit or perf if you want trustworthy
results. Fortunately, they'
On Mon, Oct 10, 2016 at 3:27 PM, Greg Ewing wrote:
> Nathaniel Smith wrote:
>>
>> IIRC to handle
>> this gilectomy adds per-object mutexes that you have to hold whenever
>> you're mucking around with that object's internals.
>
>
> What counts
#x27;s the only thing you can get out of a bytearray
without double-copying. But returning bytes would feel a bit cleaner,
and this would allow that.
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https:/
On Tue, Oct 11, 2016 at 10:53 PM, Serhiy Storchaka wrote:
> On 12.10.16 08:03, Nathaniel Smith wrote:
>>
>> On Tue, Oct 11, 2016 at 9:08 PM, INADA Naoki
>> wrote:
>>>
>>> From Python 3.4, bytearray is good solution for I/O buffer, thanks to
>>> #19
On Wed, Oct 12, 2016 at 12:17 AM, Serhiy Storchaka wrote:
> On 12.10.16 09:31, Nathaniel Smith wrote:
>>
>> But amortized O(1) deletes from the front of bytearray are totally
>> different, and more like amortized O(1) appends to list: there are
>> important use cas
On Wed, Oct 12, 2016 at 4:55 AM, Victor Stinner
wrote:
> 2016-10-12 10:01 GMT+02:00 Nathaniel Smith :
>> It's more complicated than that -- the right algorithm is the one that
>> Antoine implemented in 3.4.
>> (...)
>> My point is that
>> forcing everyone w
but I suspect
that'd still be dramatically simpler than what they're doing now...)
-n
--
Nathaniel J. Smith -- https://vorpus.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Uns
on.org/pipermail/python-dev/2013-May/126592.html
--
Nathaniel J. Smith -- https://vorpus.org
___
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
On Fri, Oct 21, 2016 at 8:32 PM, Nick Coghlan wrote:
> On 21 October 2016 at 17:09, Nathaniel Smith wrote:
>> But that was 2.4. In the mean time, of course, PEP 442 fixed it so
>> that finalizers and weakrefs mix just fine. In fact, weakref callbacks
>> are now run *befor
On Sat, Oct 22, 2016 at 3:01 AM, Nick Coghlan wrote:
> On 22 October 2016 at 16:05, Nathaniel Smith wrote:
>> On Fri, Oct 21, 2016 at 8:32 PM, Nick Coghlan wrote:
>> But PEP 442 already broke all that :-). Now weakref callbacks can
>> happen before __del__, and they can h
Didn't 3.5 have to roll an extra last minute RC for an emergency
abi-breaking bug fix, though? (Thinking of the windows runtime stuff.)
On Nov 16, 2016 7:51 PM, "Nick Coghlan" wrote:
> On 17 November 2016 at 10:44, Steve Dower wrote:
> > On 16Nov2016 1618, Ned Batchelder wrote:
> >> Am I doing
On Dec 21, 2016 7:43 AM, "Steve Dower" wrote:
"Ok, now why should _Py_PrintReferences() function be exported?"
It probably shouldn't, but it needs an #ifndef Py_LIMITED_API check so it
is excluded from the headers (my list was automatically generated).
It sounds like the opt-out approach isn't
/github.com/tmbdev/iuprlab/blob/239918b5ec0f8deecbc7c2ec1283a837d11a7b5a/boostedmlp.py#L161
https://github.com/wcs211/BEM-3D-Python/blob/874aaeffc3dac5f698f875478c3accf2b5a14daf/FSI_bem3d.py#L25
https://github.com/neobonzi/SoundPlagiarism/blob/7cff7f014521
On Sun, Dec 25, 2016 at 5:55 PM, Nick Coghlan wrote:
> On 25 December 2016 at 09:48, Nathaniel Smith wrote:
>>
>> Or maybe make it so that even no-fpectl builds still export the
>> necessary symbols so that yes-fpectl extensions don't crash on import?
>> (This
e...
>
> On Mon, Jan 2, 2017 at 4:22 AM, Nick Coghlan wrote:
>>
>> On 2 January 2017 at 18:27, Nathaniel Smith wrote:
>>>
>>> So I guess that yeah, my suggestion would be to drop this feature
>>> entirely in 3.7, given that it's never been enabl
ild
CPython.)
OTOH it is definitely important that the Python header files remain
polyglot C99-and-C++ compatible.
Even a simple check like:
echo '#include ' > test.cc && g++ -c test.cc -o /dev/null
would probably catch most issues here.
-n
--
Nathaniel J. Smith -- https://v
On Jan 24, 2017 3:35 AM, "Thomas Wouters" wrote:
On Fri, Jan 20, 2017 at 1:40 PM, Christian Heimes
wrote:
> On 2017-01-20 13:15, INADA Naoki wrote:
> >>
> >> "this script counts static memory usage. It doesn’t care about dynamic
> >> memory usage of processing real request"
> >>
> >> You may
On Jan 25, 2017 8:16 AM, "Joe Jevnik" wrote:
List, set, and dict comprehensions compile like:
# input
result = [expression for lhs in iterator_expression]
# output
def comprehension(iterator):
out = []
for lhs in iterator:
out.append(expression)
return out
result = comprehe
coroutine function in every
way except that iscoroutinefunction returns False. And there's no
collections.abc.CoroutineFunction (not sure how that would even work).
Better to just call the thing and then do an isinstance(...,
collections.abc.Coroutine) on the return value.
I haven't h
t;> >
>> > ___
>> > Python-Dev mailing list
>> > Python-Dev@python.org
>> > https://mail.python.org/mailman/listinfo/python-dev
>> > Unsubscribe:
>> > https://mail.python.org/mailman/options/pytho
On Mar 20, 2017 1:26 PM, "Antoine Pitrou" wrote:
Hello Oleg,
On Mon, 20 Mar 2017 18:28:29 +0100
Oleg Nesterov wrote:
> I started to learn python a few days ago and I am trying to understand
what
> __del__() actually does. https://docs.python.org/3/
reference/datamodel.html
> says:
>
> ob
On Mar 28, 2017 8:29 AM, "Serhiy Storchaka" wrote:
On 28.03.17 14:24, Miro Hrončok wrote:
> However, recently we found an issue with this approach [1]: an extension
> module built against Python 3.6.1 cannot be run on Python 3.6.0, because
> it uses a macro that, in 3.6.1, uses the new PySlice_A
On Mar 28, 2017 10:54 AM, "Steve Dower" wrote:
On 28Mar2017 1035, Paul Moore wrote:
> On 28 March 2017 at 18:05, Glenn Linderman wrote:
>
>> Somewhere I got the idea that extension authors were supposed to build
>> against the n.m.0 releases, expressly so that the extensions would then be
>> co
On Wed, Mar 29, 2017 at 8:22 AM, Paul Moore wrote:
> On 28 March 2017 at 17:31, Nathaniel Smith wrote:
>> IMO this is a bug, and depending on how many packages are affected it might
>> even call for an emergency 3.6.2. The worst case is that we start getting
>> large numbers
ur original question is that PEP 342
says that generator finalization calls the generator's close() method,
which throws a GeneratorExit into the generator, and PEP 380 says that
as a special case, when a GeneratorExit is thrown into a yield from,
then this is propagated by calling .close() o
301 - 400 of 1817 matches
Mail list logo
