ave -s or -I.
-I should be the default for system scripts; it’s not on Debian/Ubuntu though
unfortunately.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
right around the
corner .
-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
e_reader(module)
># resources implements the ResourceReader ABC
BTW, just as a quick followup, this API suggestion was brilliant, Nick. It
solved the problem nicely, and let me add support for ResourceReader to
zipimport with only touching the bare minimum of zipimport.c. :)
https://
PR is approved, CI is all green, and no additional commits have been
pushed? I suppose the reason would be because in GH, you can’t modify the
commit message any other way pre-merge.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
gt; If not provided, I guess we'll use the GitHub PR title and description.
I think that’d be fine actually. When I merge things I almost always just
delete most of the default commit message anyway.
-Barry
signature.asc
Description: Message signed with OpenPGP
that Python’s best days
are ahead of us.
Enjoy,
-Barry
[1]
https://groups.google.com/forum/?hl=en#!original/comp.lang.misc/_QUzdEGFwCo/KIFdu0-Dv7sJ
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev
ned that, at least on macOS High Sierra (and probably going
back several releases), on a US keyboard you can press and hold the ‘L’ (cap-L)
key. A little popup will appear like the attached image (if this doesn’t get
stripped by Mailman). Hit ‘1’ and the slashy-L will get entered: Ł.
Cheers
-Bar
time.)
What, not the Contractual Obligation release? :)
-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.p
up to do it. Or
maybe no corporation thinks it a good business investment to pay employees to
do it. What other options are there, and if none, then which of those can you
solve?
Or to paraphrase a timeless quote: Ask not what Python can do for you, ask what
you can do for Pyt
t;the base class of the class heirarchy"
>
> "the root of the class heirarchy"
In all seriousness, either one of those works for me. While the first one does
repeat the word “class”, it seems the most clear description of what this
ch
with the current suite of tools.
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/mailma
On Feb 20, 2018, at 22:42, Nick Coghlan wrote:
>
> In the current PEP workflow, provisionally accepted PEPs are marked as
> "Accepted", and remain in that state until they're declared stable and
> moved to Final.
I left a review on the PR, but the substance o
ated comprehensions that are less readable than just expanding the
code into a for-loop?
for-loops-are-not-evil-ly y’rs,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pytho
omment pragmas in the code.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/opti
others, and once you’ve gone down that path, you just build up
technical debt to eventually try to clean it up.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.py
s,
> or be nitpicky about some variable or function name). YMMV :-)
Those are aesthetic comments that are important, and are also difficult to
automate. What I really don’t want to comment on are things like whitespace
(vertical, horizontal, trailing), import order or format, cons
long time to run, but you can
run your code style tests pretty quickly (e.g. flake8 and mypy), then you can
get more immediate feedback about your PR code style, and it’s not so painful
if your test suite is slow.
-Barry
signature.asc
Description: Message signed wit
s a great
solution if you want to participate in just a few threads. I personally use
Postbox for that, but there good free open source MUAs too, depending on your
platform. My favorite on Linux is Claws Mail.
Cheers,
-Barry
signature.asc
Description: Message signed wit
import
system.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev
On Mar 22, 2018, at 12:33, Oleg Broytman wrote:
>
> On Thu, Mar 22, 2018 at 12:30:02PM -0700, Barry Warsaw
> wrote:
>> Developers are mostly going to use pip, and maybe a requirements.txt,
>
> +virtual envs to avoid problems with global site-packages.
Yep, that was
ng shorter. But if
releases come more quickly, that has implications for the deprecation policy
too. And it puts pressure on the second digit because something like Python
3.53 is distasteful (especially because it would be easily confused with
3.5.3). Python 21.12 anyone? :)
Cheers,
-Barry
ly so. And if you count the multiyear hiatus between reboots on
this topic, yes it will likely go on forever. :)
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
; SomeFlag.TWO == 2 is True.
Well, now I’m confused:
Python 3.7.0b2+ (heads/3.7:f328caf4ca, Mar 26 2018, 19:57:33)
[Clang 9.0.0 (clang-900.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from enum import
the assignment
expression operator just ugly enough that people won’t overuse it. Since I
can’t have ‘>>’ or ‘<>’ back, I propose ‘===‘.
go-ahead-count-‘em-every-time-ly y’rs,
-Barry
signature.asc
Description: Message signed with OpenPGP
s
print(x)
This is one of my favorite Python oddities because it always makes me look like
a genius when I diagnose it. :)
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
expressions rather than introducing new, weird, symbols.
I also think it effectively solves the switch-statement problem:
if (get_response() as answer) == 'yes':
do_it()
elif answer == 'no':
skip_it()
elif answer == 'maybe'
okay_then()
That’s Pythonic eno
On Apr 24, 2018, at 06:55, Antoine Pitrou wrote:
>
> If the ambition is to find a piece of syntax that reads as "binds",
> then we can use a variation on the FLUFL operator: "<->".
FLUFL Override Approved!
-Barry
signature.asc
Descr
ommunity was just small enough to
be able to handle such a disruptive change, but wouldn’t ever be so again. The
latter is definitely true today, even if the former was overly optimistic.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
should be written to supersede the old PEP. We even have an
official `Superseded` Status value, and a `Superseded-By` header.
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
ge for CLIs. That would be sad, and
definitely has a long term impact on Python’s popularity.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listi
time. That makes things better but still not ideal. Ultimately though
that means we don’t suffer from the slowness of zlib since we don’t count cold
cache times (i.e. before the initial pyz unpacking operation).
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
...
Oh, I’m well aware of the history of this patch. :) I’d love to see it
available on the platforms I use, and agree it’s well worth someone’s time to
continue to shepherd this through the processes to make that happen. Even if
it did take years to roll out, Python could use it with the p
me, but I do
think it’s time to discuss whether it will still be appropriate moving forward.
I’m not saying it is or isn’t, but with the release of 3.7, I think it’s a
great time to explore our options.
Cheers,
-Barry
signature.asc
Description: Mes
On May 11, 2018, at 12:23, Guido van Rossum wrote:
>
> Indeed, we have an implementation of this specific to mypy.
Is there anything in mypy’s implementation that can be generalized into a
library?
-Barry
signature.asc
Description: Message signed with O
lue in spinning a tarball though, for
downstream consumers who need a tagged and blessed release.
Cheers,
-Barry
signature.asc
Description: Message signed with OpenPGP
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/li
f whom
>are still dealing with the fallout of the Python 3 transition).
I'm not convinced that relaxing the maintenance release constraints lessens
the pain for anybody.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@pytho
ey would work with an all-volunteer developer community. But
time-based releases do have advantages too, and maybe those would outweigh the
disadvantages for Python at this point.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
ble to
>execute this particular code so you can specialize what that includes.
I'd love to see Python itself gain such a tool, but if it had the critical
pieces to execute in this way, that would enable a common approach to
supporting this in third party tools
Is for loading resources
from your packages, otherwise you're gonna have problems with zip
executables. We've talked before about adopting some of these APIs into
Python's stdlib. pkgutil is a start, and the higher level APIs from
pkg_resources should probably go there.
Cheers,
-Barr
On May 28, 2015, at 09:23 AM, Chris Barker wrote:
>Barry Warsaw wrote:
>>I do think single-file executables are an important piece to Python's
>>long-term competitiveness.
>
>Really? It seems to me that desktop development is dying. What are the
>critical use-cases
one approach (or not, if we don’t want to).
Sounds good to me!
Cheers,
-Barry
pgp1R37cL1HEu.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
.
Yep, I mentioned this in an earlier message (probably buried in the
centithread avalanche). Both static and dynamic linking have valid use
cases.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/p
thon 2, folks
getting paid by employers who need Python 2 to continue to be maintained, will
step up and go through the mentorship process so that they can more directly
apply such patches. I.e. they can start to take over some of the active
maintenance of the Python 2.7 branch.
Cheers,
;re pushing that
forward too.
In many cases where you have a long lived stable release and active
development releases, it's generally the policy that fixes show up in the dev
release first. At least, this is the case with Ubuntu and SRUs, and it makes
a lot of sense.
Cheers,
-Barry
___
On May 30, 2015, at 10:09 AM, Serhiy Storchaka wrote:
>Isn't it a time to assign release manager for 3.6-3.7?
Indeed! Please welcome Ned Deily as RM for 3.6:
https://www.python.org/dev/peps/pep-0494/
Cheers,
-Barry
pgpArSFCqg7XM.pgp
Description: OpenPGP digital s
he results upstream to Debian as much as possible.)
Follow up here on any of the CC'd mailing lists, email me directly, or ping me
on IRC (nick 'barry' on python-dev, ubuntu-release @ freenode, debian-python @
OFTC).
Python 3.5 is in beta, with a final release scheduled for September
reak actual packages.
Thanks for volunteering to do this work David, and for doing it in the past
other-David!
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://ma
else who would
like to review the patch, I'd like to get a beta release exemption for the
change.
Patch on the issue includes implementation, test, and docs.
Cheers,
-Barry
pgpmv5dAdlx7Z.pgp
Description: OpenPGP digital signature
___
Python-De
ime to think about the problem. My impression is that the latter is
>unlikely because the problem is inherent in the new auth methods.
I generally like the approach that initially added with issue #15014. This is
a subtle corner of the RFC and an unexpected regression from Python 3.4.
n the review, so I'll be committing
this at some point today.
Cheers,
-Barry
pgpnvCoLggNc_.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
bute.
It's seems like a dubious special case.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d probably want the third argument to be optional (I wouldn't use
it).
If '{foo}' or '${foo}' syntax is adopted (with no allowance for '$foo'), it's
very unlikely I'd use that over string.Template for internationalization, but
the above would still be u
ted. The same goes for any !r or other formatting modifiers. In an
i18n context, you want to stick to the simplest possible substitution
placeholders.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
On Aug 10, 2015, at 02:49 PM, Eric V. Smith wrote:
>It's possible. But my point is that Barry doesn't even want
>attribute/item getters for an i18n solution, and I'm not willing to
>restrict it that much.
Actually, attribute chasing is generally fine, and flufl.i18n su
quot;"")(..., Naming.args_cname)}
>
>{self.starstar_arg.entry.cname} =
>({Naming.kwds_cname}) ? PyDict_Copy({Naming.kwds_cname})
> : PyDict_New();
>
>if (unlikely(!{self.starstar_arg.entry.cname})) return {self.error_value()};
&g
he file?
Currently, a lot of these types of problems can be found much earlier on
through the use of such linters. Putting arbitrary expressions in strings
will just hide them to these tools for the foreseeable future. I have a hard
time seeing how Emacs's syntax highlighting
'd love to hear from the maintainers of pyflakes, pylint,
Emacs, vim, and other editors, linters, and other static analyzers on a rough
technical assessment of whether they can support this and how much work it
would be.
Cheers,
-Barry
___
Python-De
On Aug 17, 2015, at 01:36 PM, Guido van Rossum wrote:
>> 1. Barry wants the substitutions to look like $identifier and possibly
>> ${identifier}, and the PEP 498 proposal just uses {}.
>>
>> 2. There needs to be a way to identify interpolated strings and i18n
>> stri
used in test suites to force style compliance within
a project. That's fine except that, to paraphrase Dr. Strangelove, the whole
point of such tests is lost if you don't run those tests! I've actually had
to fix several packages recently whose pep8 tests fail.
I'm often relu
ings, but I'll let others
propose language for that.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sep 08, 2015, at 10:02 AM, Guido van Rossum wrote:
>#2 sounds fine to me.
Agreed.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/opti
ects I use
Mercurial on), I can usually get the job done without a lot of cursing. :)
So, for this very interesting informational PEP, I'd like to see detailed
documentation on best practices for applying patches to multiple active
branches using git, in the context of CPython development.
Cheers,
-Ba
;,
which I can change my installer to cope with.
However the key for the 64bit install is ‘3.5’ but not '3.5-64'.
Why was this changed and why not consistently between 32 and 64 bit versions?
Barry
PyCXX, PySVN maintainer
___
Python-Dev mai
I still find that it's
a great first-stop when trying to do something out of the ordinary with git.
Call me old skool but looking up something in the index can be faster than
using da googles. :)
Cheers,
-Barry
___
Python-Dev mailing list
Python-De
> On 15 Sep 2015, at 18:39, Barry Scott wrote:
>
> I am used to looking in
> HKLM:\SOFTWARE\Python\PythonCore\%(py_maj)d.%(py_min)d\InstallPath
> to find out where python is installed so that my installation kit can add
> itself to site-packages.
>
> I just found th
rily obvious that it's Python 3).
That's why in Debian/Ubuntu we include /usr/bin/pyvenv-X.Y for all supported
versions (currently 3.4 and 3.5 in Ubuntu 15.10), and then symlink
/usr/bin/pyvenv to the default one. So I'm sympathetic t
milar discussion is pip, and the suggested move to
`python -m pip`, which makes a lot of sense. However, *inside* a virtualenv,
there's no ambiguity about the Python version associated with direct `pip`
invocation, so it still makes sense to install that there.
Cheers,
-Barry
pgpltiap26Kr2.pgp
and
fun next time, please get in touch.
Here's a write-up of the sprint:
https://gitlab.com/python-smtpd-hackers/aiosmtpd/wikis/2015-09-27-hackfest
Special thanks to the PSF and Brian Curtin for sponsoring the sprint.
Cheers,
-Barry
pgp4qaLhPZXB9.pgp
Description: OpenPGP digital sign
tion for very
different audiences. What's there seems mostly great for reference, and maybe
the stdlib docs aren't the right place for what I want, but as the 500 Lines
chapter promotes, asyncio is pretty powerful so it would be nice to have
Python documenta
On Sep 28, 2015, at 02:38 PM, Guido van Rossum wrote:
>Your comments make total sense -- we're just short on people who can write
>that kind of docs. :-(
Oh well, maybe someday we will! ;)
-Barry
pgpGVDxk58hN8.pgp
Description: OpenPGP digita
g. "hey
we're discussing PEP 4000 over on py-in-the-sky-t...@python.org") and after.
I do think Standards-Track PEPs (i.e. those that change the language or
stdlib) must be discussed and/or posted on python-dev prior to resolution.
Cheers,
-Barry
cker.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Oct 03, 2015, at 01:05 AM, Victor Stinner wrote:
>Ubuntu is also working on a similar change. I don't know when it will happen.
For the desktop, we're aiming for 16.04 LTS.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@pyt
ment.
Right. Have we ever done that though? We shouldn't!
>From my understanding on how this tag is used, this wouldn't be a
>problem (because the magic number in the file also changes). But I want
>to make sure I'm not misun
he logical extension of PEP 488 for your use case.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
While I'm a part of the community, that wasn't always the case and it's very
large, so I'll take this opportunity to come in and say a big thank you as well!
From: br...@python.org
Date: Tue, 10 Nov 2015 18:09:37 +
To: a.r.ka...@gmail.com; python-dev@python.org
Subject: Re: [Python-Dev] This
vailable on your system, what your preference is, etc. and then
execute your script using that version-specific binary. I would expect the
launcher to eventually be provided by the upstream Python development
community.
AFAIK, there have been a few stabs at writing such a launcher, but nothing
t
On Nov 24, 2015, at 10:18 AM, Nick Coghlan wrote:
>Since we already know Red Hat are OK with the draft recommendations,
>and I missed the RHEL 7.2 release date anyway, perhaps Barry or
>Matthias might be interested in tilting at the Ubuntu 14.04 LTS stable
>release update windmill?
r:
This is an example of my problem with the tone of PEP 493 (sorry Nick, nothing
personal!). "Improved default behavior"... for whom? It's not improved for
the folks whose applications are broken by changing the default.
Cheers,
-Barry
_
convenience method above, then the sample code could be
simplified down to a default for the `enable` parameter and a call to
ssl.verify_certificates().)
Is it too late to include both of those suggestions in PEP 493 and Python
2.7.11?
Cheers,
-Barry
___
although I'll note the preference to
minimize the unique-to-downstream changes.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/optio
On Nov 24, 2015, at 02:12 PM, Nick Coghlan wrote:
>On 24 November 2015 at 11:59, Barry Warsaw wrote:
>> We'd have to also handle
>> migration paths to newer Ubuntu releases, which probably means removing the
>> config file on future upgrades.
>
>You'll nee
added too. I'm -0 on
the config file though since while I think it might be useful, I'm not sure
we'd actually install that on Ubuntu.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listi
As someone who plays around a *lot* with descriptors, I would be interested in
reviewing it. I may not have the same knowledge as a core developer, but I can
still help.
Date: Wed, 25 Nov 2015 14:31:09 -0600
From: sad2proj...@gmail.com
To: python-dev@python.org
Subject: [Python-Dev] Help with a
end-administrators. Although I think it could safely sneak in after rc1, that
would be for the RM to decide. Even if it were deferred to 2.7.12, it would
still provide a better, more consistent experience if implemented upstream.
Cheers,
-Barry
pgp1_rS2ossYp.pgp
Descri
ython 3. You're just moving the change out of the code and
into the environment, where it's arguably more difficult to re-discover down
the road.
Cheers,
-Barry
pgptqBXhMF998.pgp
Description: OpenPGP digital signature
___
Python-Dev mailing lis
rd-only argument, but
of course this is Python 2. Instead, I'd like to force passing True or False
(and document using `enable=True` or `enable=False`) and not rely on a default
argument. But I'm only +0 on that detail.
Cheers,
-Barry
pgpkeUFzn5kLf.pgp
Description: OpenPGP digital signatu
> From: victor.stin...@gmail.com
> Date: Wed, 2 Dec 2015 15:46:37 +0100
> To: random...@fastmail.com
> Subject: Re: [Python-Dev] Deleting with setting C API functions
> CC: python-dev@python.org
>
> 2015-12-02 15:40 GMT+01:00 Random832 :
> > Are there plans for a Python 4?
>
> No. Don't. Don't sc
would be when Python's Einstein, er
David Beazley, finally cracks the nut of the GIL. Should that require a new
backward incompatible C API, Python 4.0 would be the time to do it.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https
On Dec 02, 2015, at 11:26 PM, Gregory P. Smith wrote:
>Except that we should skip version 4 and go directly to 5 in homage to
>http://www.montypython.net/scripts/HG-handgrenade.php.
Five is right out.
https://youtu.be/QM9Bynjh2Lk?t=3m35s
-Barry
pgplrHBCVtY0F.pgp
Description: OpenPGP d
n asyncio for a long time could
write that up? I don't think I'm the right person to do that, but I'd be very
happy to review it.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python
From: gu...@python.org
Date: Sun, 20 Dec 2015 14:33:46 -0800
To: ros...@gmail.com
Subject: Re: [Python-Dev] Change the repr for datetime.timedelta (was Re:
Asynchronous context manager in a typical network server)
CC: python-dev@python.org
> I'm just curious on the backward compatibility impact.
ge the repr for datetime.timedelta (was Re:
Asynchronous context manager in a typical network server)
To: vgr...@live.ca
CC: ros...@gmail.com; python-dev@python.org
On Sun, Dec 20, 2015 at 3:05 PM, Emanuel Barry wrote:
From: gu...@python.org
> I'm just curious on the backward compatibility impac
7;s too
much tooling that would have to change to do so. However, if either task
really interests you, please get in touch with the PEP editors.
it-only-took-15-years-ly y'rs,
-Barry (on behalf of the PEP editors)
[*] Status: Withdrawn being about the only currently appropriate resolutio
On Jan 11, 2016, at 03:25 PM, anatoly techtonik wrote:
>On Wed, Jan 6, 2016 at 2:49 AM, Barry Warsaw wrote:
>
>> reStructuredText is clearly a better format
>
>Can you expand on that? I use markdown everywhere
reST is better than plain text. Markdown is not a PEP format opti
creator add their own __bool__ if they want something different?
The latter. I think in general enums are primarily a symbolic value and don't
have truthiness. It's also so easy to override when you define the enum that
it's not worth changing the curren
ywhere.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
nificant optimization. Since
you probably can't prove that without some experimentation, this API should be
provisional.
Cheers,
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
On Jan 25, 2016, at 07:16 PM, Victor Stinner wrote:
>Barry also wrote: "Did you address my suggestion on python-ideas to
>make the new C API optionally compiled in?"
>
>Well, it is an option, but I would prefer to have the API for AST
>optimizer directly built in Python.
Just as long as you can still build and run Python on Guido's ancient SGI
machine .
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/p
201 - 300 of 2826 matches
Mail list logo
