On Feb 22, 2018, at 11:04, Serhiy Storchaka wrote:
>
> Stephan Houben proposed an idiom which looks similar to new hypothetic syntax:
>
>result = [y + g(y) for x in range(10) for y in [f(x)]]
>
> `for y in [expr]` in a comprehension means just assigning expr to y. I never
> seen this idiom
On Feb 21, 2018, at 19:03, Dan Stromberg wrote:
>
> Is flake8 that much better than pylint, that pylint wouldn't even be
> discussed?
I honestly don’t use pylint all that much these days, but when I was evaluating
them years ago, I found pylint to be too noisy about not-incorrect code. I
als
On Feb 22, 2018, at 02:12, Antoine Pitrou wrote:
> Everytime I contribute to a project which has automatic style checks in
> CI, I find myself having to push pointless "cleanup" commits because
> the CI is barking at me for some ridiculous reason (such as putting two
> linefeeds instead of one be
> On Feb 22, 2018, at 08:08, Antoine Pitrou wrote:
>
> That's a fair point I hadn't considered. OTOH the style issues I
> usually comment on as a reviewer aren't the kind that would be caught
> by an automated style check (I tend to ask for comments or docstrings,
> or be nitpicky about some va
On Feb 22, 2018, at 09:09, Eric Snow wrote:
>
> I had exactly that experience on one particularly large Go project (on
> GitHub, with slow CI, driven by bots).
One thing that’s nice to set up if you can is multiple, parallel, independent
CI runs. E.g. if your full test suite takes a long time
On Mar 2, 2018, at 20:41, Dan Stromberg wrote:
>
> Maybe gmane combined with a threaded newsreader (NNTP client) would be
> close enough?
While I guzzle the firehose of python-dev from my inbox, Gmane+NNTP is how I
read many other Python mailing lists, including python-ideas. It’s a great
sol
On Mar 22, 2018, at 09:58, Gregory Szorc wrote:
>
> Not all consumers of Python packages wish to consume Python packages in the
> common `pip install ` + `import ` manner. Some Python
> applications may wish to vendor Python package dependencies such that known
> compatible versions are always
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
On Apr 3, 2018, at 05:51, Paul G wrote:
> Switching to CalVer is a pretty clear sign that there is now a "rolling
> backwards compatibility window", and it allows Python to skip right over the
> mythical "Python 4" and directly to "Python 21". Additionally, since the
> version number will be t
On Apr 3, 2018, at 13:08, Brett Cannon wrote:
> Are we at the PEP/language summit topic point yet in this discussion since
> Guido has said he's not interested in changing the status quo? ;) Versioning
> is like naming variables, so this thread could go on forever.
Yeah probably so. And if yo
On Apr 4, 2018, at 11:32, Ethan Furman wrote:
>
> (A) A standard Enum class is a container of Enum members. It cannot hold
> anything else. However, it has been returning False both in cases where the
> in-question object was an Enum of a different class (a Fruit in a Color, for
> example) a
On Apr 18, 2018, at 10:43, MRAB wrote:
> Some languages use '=' for assignment, others for equality, but do you know
> of a language that uses ':=' for equality' or '==' for assignment?
Clearly we should take a page from the ternary operator and make the assignment
expression operator just ugl
On Apr 18, 2018, at 11:17, Chris Angelico wrote:
> At the moment, it isn't aware of 'del’.
I don’t know if it’s relevant to the current discussion, but don’t forget about
implicit dels:
def foo():
x = 1
try:
1/0
except ZeroDivisionError as x:
pass
print(x)
Thi
On Apr 23, 2018, at 13:01, Ethan Furman wrote:
>
> On 04/22/2018 10:44 PM, Tim Peters wrote:
>>
>>
>> I find myself warming more to binding expressions the more I keep them
>> in mind while writing new code.
And I really like the term “binding expressions” because that’s how I think
about thi
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
Description: Message signed with OpenPGP
On Apr 26, 2018, at 09:28, Eric Snow wrote:
>
> On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow
> wrote:
>> In pondering our approach to future Python major releases, I found
>> myself considering the experience we've had with Python 3. The whole
>> Py3k effort predates my involvement in the commu
On Apr 30, 2018, at 06:36, Nick Coghlan wrote:
> Instead of editing old PEPs, would it make sense to write a new one
> which replaces the old one?
As a general rule, at least the way I think about it, Informational PEPs can
mostly be updated inline, evolving with new insights as we go along. A
Thanks for bringing this topic up again. At $day_job, this is a highly visible
and important topic, since the majority of our command line tools are written
in Python (of varying versions from 2.7 to 3.6). Some of those tools can take
upwards of 5 seconds or more just to respond to —help, whic
On May 2, 2018, at 09:42, Gregory Szorc wrote:
> As for things Python could do to make things better, one idea is for "package
> bundles." Instead of using .py, .pyc, .so, etc files as separate files on the
> filesystem, allow Python packages to be distributed as standalone "archive"
> files.
On May 2, 2018, at 15:24, Gregory Szorc wrote:
>
> FWIW, Google has a patched glibc that implements dlopen_with_offset().
> It allows you to do things like memory map the current binary and then
> dlopen() a shared library embedded in an ELF section.
>
> I've seen the code in the branch at
> htt
On May 7, 2018, at 11:49, Craig Rodrigues wrote:
>
> Would it be reasonable to request a 10 year moratorium on making changes to
> the core Python language,
> and for the next 10 years only focus on things that do not require core
> language changes,
> such as improving/bugfixing existing libra
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 OpenPGP
___
On May 16, 2018, at 00:35, Alex Walters wrote:
>
> In the spirit of learning why there is a fence across the road before I tear
> it down out of ignorance [1], I'd like to know the rationale behind source
> only releases of cpython.
Historically, it was a matter of resources. Making binary rele
On May 27, 2015, at 06:34 PM, Nick Coghlan wrote:
>I'd actually like to pursue a more nuanced view of what's permitted in
>maintenance releases, based on a combination of the language moratorium
>PEP, and an approach inspired by PEP 466, requiring that every feature
>added in a maintenance release
On May 27, 2015, at 05:15 PM, Terry Reedy wrote:
>How about a feature release once a year, on a schedule we choose as best for
>us.
We discussed timed releases ages ago and they were rejected by the majority.
Time-based releases can make a lot of sense, especially if the interval is
short enough.
On May 28, 2015, at 11:39 AM, Donald Stufft wrote:
>You don’t need a "fully functioning Python" for a single file binary, you
>only need enough to actually run your application. For example, if you're
>making an application that can download files over HTTP, you don't need to
>include parts of the
Go seems to be popular where I work. It is replacing Python in a number of
places, although Python (and especially Python 3) is still a very important
part of our language toolbox.
There are several reasons why Go is gaining popularity. Single-file
executables is definitely a reason; it makes de
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
On May 28, 2015, at 12:44 PM, Donald Stufft wrote:
>Pex would be improved by having native support for importing .so’s from within
>a zipfile via zipimport. It would also be improved by having good, built in
>support for extraneous resources in the stdlib too.
Completely agree on both points. Ha
On May 28, 2015, at 11:48 PM, Matthias Klose wrote:
>And the very same place where you are working is investing in getting shared
>libraries working for Go. Single binaries may be popular for distributing end
>user applications, but definitely not for distributing a core OS or a SDK.
Yep, I ment
On May 29, 2015, at 04:04 PM, Guido van Rossum wrote:
>There are a fair number of people on this thread whose employer pays them to
>work on Python.
My guess is that as Python 2.7 gets longer in the tooth, and it becomes harder
to motivate volunteers to shepherd contributed patches into Python 2,
On May 30, 2015, at 06:55 PM, Nick Coghlan wrote:
>Intel are looking to get involved in CPython core development
>*specifically* to work on performance improvements, so it's important
>to offer folks in the community good reasons for why we're OK with
>seeing at least some of that work applied to
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 signature
[Apologies for the cross-posting! -BAW]
For Ubuntu 15.10 (Wily Werewolf), we want to make Python 3.5 the default
Python 3 version. It's currently undecided whether we will keep Python 3.4 as
a supported version, but a lot of that depends on how easily an archive port
to Python 3.5 goes. Ideally,
On Jul 06, 2015, at 09:32 PM, Raymond Hettinger wrote:
>FWIW, it took me 100+ hours. Doing this right is a non-trivial undertaking
>(in modern times, there are an astonishing number of changes per release).
>That said, it is rewarding work that makes a difference.
Indeed. During distro Python
Larry and others,
I'd like to bring your attention to issue #15014. This issue added arbitrary
auth methods to smtplib, which is a good thing. Implicitly though, a
regression was introduced w.r.t. RFC 4954's optional initial-response for the
AUTH command, for authentication methods that support
On Jul 07, 2015, at 02:53 PM, Terry Reedy wrote:
>To me, the main question is whether you are sure that your proposal is the
>right fix, or whether you might reasonably do something different (with the
>new arguments) if changes were reverted for the present and you two took more
>time to think ab
On Jul 09, 2015, at 08:47 PM, Nick Coghlan wrote:
>That strikes me as just the kind of
>not-quite-as-finished-as-we-thought case that the beta cycle is
>designed to flush out, so the minor further enhancement sounds like a
>good idea to me.
Cool. RDM provided some good feedback in the review, so
On Jul 14, 2015, at 02:06 PM, Dima Tisnek wrote:
>Michael and Kushal are of the opinion that "assret" is a common typo
>of "assert" and should be supported in a sense that it also triggers
>AttributeError and is not silently ignored like a mocked user
>attribute.
It's seems like a dubious special
On Aug 09, 2015, at 06:14 PM, David Mertz wrote:
>That said, there *is* one small corner where I believe f-strings add
>something helpful to the language. There is no really concise way to spell:
>
> collections.ChainMap(locals(), globals(), __builtins__.__dict__).
>
>If we could spell that as,
On Aug 11, 2015, at 03:26 AM, Steven D'Aprano wrote:
>I think I would be happy with f-strings, or perhaps i-strings if we use
>Nick's ideas about internationalisation, and limit what they can evaluate to
>name lookups, attribute lookups, and indexing, just like format().
I still think you really
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 supports that.
Translators can
On Aug 10, 2015, at 11:05 PM, ISAAC J SCHWABACHER wrote:
>code.putlines(f"""
>static char {entry.doc_cname}[] = "{
>split_string_literal(escape_bytestring(docstr))}";
>
>{ # nested!
>f"""
>#if CYTHON_COMPILING_IN_CPYTHON
>struct wrapperbase {entry.wrapperbase_cname};
>#endif
>""" if entry.
On Aug 17, 2015, at 11:02 AM, Paul Moore wrote:
>print(f"Iteration {n}: Took {end-start) seconds")
This illustrates (more) problems I have with arbitrary expressions.
First, you've actually made a typo there; it should be "{end-start}" -- notice
the trailing curly brace. Second, what if you
On Aug 18, 2015, at 12:58 AM, Chris Angelico wrote:
>The linters could tell you that you have no 'end' or 'start' just as
>easily when it's in that form as when it's written out in full.
>Certainly the mismatched brackets could easily be caught by any sort
>of syntax highlighter. The rules for f-s
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
>> strings, and possibly combinations
On Sep 05, 2015, at 03:57 PM, Jim J. Jewett wrote:
>Would it be reasonable to ask PEPs to start including a section on any
>recommended changes to PEP8? (e.g., "If an embedded expression
>doesn't fit on a single line, factor it out to a named variable.")
Yes, I think it's reasonable to encourage
On Sep 04, 2015, at 08:01 PM, Guido van Rossum wrote:
>And I'm ready to accept it.
As I've mentioned to Eric, I think it's a great PEP, so congratulations on
getting one through The Gauntlet. I know that in my own code, I'm looking
forward to using it in however many years it takes for 3.6 to be
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/options/pytho
On Sep 12, 2015, at 03:54 PM, Oleg Broytman wrote:
>This Informational PEP collects information about git. There is, of course, a
>lot of documentation for git, so the PEP concentrates on more complex (and
>more related to Python development) issues, scenarios and examples.
Thanks for this Oleg.
On Sep 16, 2015, at 09:34 AM, R. David Murray wrote:
>My experience with DVCS started with bazaar, moved on to hg for the
>CPython project, and finally git. Through all of that I did not
>understand the DAG, and had trouble wrapping my mind around what was
>going on, despite being able to get thi
On Sep 17, 2015, at 06:40 PM, Brett Cannon wrote:
>I propose that the pyvenv script be deprecated in Python 3.5.1 and
>removed in Python 3.8. The reason for this proposal is because it is
>non-obvious what version of Python a pyvenv command is tied to (heck,
>it isn't necessarily obvious that it's
On Sep 18, 2015, at 07:53 PM, Nick Coghlan wrote:
>I currently use pyvenv directly, but I agree with starting a migration
>to only supporting the more explicit "python -m venv". There's always
>an inherent ambiguity on *nix with unqualified version sensitive
>Python commands as to whether they're
Yesterday (27-Sep-2015), four Washington DC area Python developers got
together for a local Python hacking sprint. Andrew, Eric, Jason, and I were
joined remotely by the esteemed R. David Murray. We did stuff and had fun!
We hope to do stuff and have fun again! If you want to join us for stuff a
On Sep 28, 2015, at 08:22 AM, Guido van Rossum wrote:
>I saw that you had a need for an asyncio tutorial. I wonder if the "500
>lines" chapter on asyncio would help? I didn't write it; I only write the
>500 lines of code, A. Jesse Jiryu Davis wrote the text, and it's wonderful:
>http://aosabook.or
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 digital signature
_
On Sep 30, 2015, at 09:14 PM, Alexander Belopolsky wrote:
>When I faced a similar situation with PEP 495, Guido's advise was "I think
>that a courtesy message to python-dev is appropriate, with a link to the
>PEP and an invitation to discuss its merits on datetime-sig." [1]
Certainly Discussions-
On Oct 02, 2015, at 11:46 AM, Victor Stinner wrote:
>Should I write a PEP for a new field in sys.implementation?
Specifically PEP 421 says that a PEP is needed if the new sys.implementation
attribute is required to be defined in all implementations, i.e. it's a new
required attribute. Will debug
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@python.org
https://mai
On Oct 28, 2015, at 08:35 AM, Eric V. Smith wrote:
>The "following table" is a comment, that contains a few references to
>the tag "cpython-", specifically cpython-32. It doesn't seem
>that the tag is routinely updated in the comment.
IIRC, it used to have to be changed in the code, but with this
On Nov 05, 2015, at 11:33 AM, Victor Stinner wrote:
>- Lib/__pycache__/os.cpython-36.pyc: default mode
>- Lib/__pycache__/os.cpython-36.fat-0.pyc: FAT mode
>
>With -O:
>
>- Lib/__pycache__/os.cpython-36.opt-1.pyc: default mode
>- Lib/__pycache__/os.cpython-36.fat-1.pyc: FAT mode
>
>
>With -OO:
>
>
On Nov 13, 2015, at 10:32 PM, Damien George wrote:
>1. What is the true intent of PEP 394 when only Python 3 is installed? Is
>"python" available or not to run scripts compatible with 2.x and 3.x?
>
>2. Is it possible to write a shebang line that supports all variations of
>Python installations o
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? I know there wa
On Nov 17, 2015, at 11:44 PM, Nick Coghlan wrote:
>For Debian, Ubuntu and SUSE, their original determinations for the
>relevant CVE were "too intrusive to backport", so folks currently need
>to upgrade to newer versions of those distros to get the improved
>default behaviour:
This is an example o
There's a lot to process in this thread, but as I see it, the issue breaks
down to these questions:
* How should PEP 493 be implemented?
* What should the default be?
* How should PEP 493 be worded to express the right tone to redistributors?
Let me take on the implementation details here.
On
On Nov 24, 2015, at 09:16 AM, Toshio Kuratomi wrote:
>It sounds like the implementation sections of the PEP are acceptable
Well, see my follow up to MAL's email. From Rob's and RDM's responses, it
seems we're not alone. :)
I like all your other proposed changes, although I'll note the preferenc
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
On Nov 25, 2015, at 03:39 PM, R. David Murray wrote:
>I think we should include the environment variable support in CPython
>and be done with it (nuke the PEP otherwise). Which is what I've
>thought from the beginning :)
+1. I'd like to see my proposed convenience function added too. I'm -0 on
On Nov 26, 2015, at 02:13 PM, Nick Coghlan wrote:
>PEP 476 rejected providing a public indefinitely maintained API for this, so
>PEP 493 is specifically about helping commercial redistributors offer a
>smoother transition plan to customers without affecting the public Python
>level API, and withou
On Nov 26, 2015, at 03:06 PM, Nick Coghlan wrote:
>I'm not a big fan of it either, but it's the way sustainable
>commercial open source distribution works in practice:
While it's inevitable that redistributors have to deviate from upstream, in
Debian and Ubuntu, we really try to keep that at a mi
On Nov 27, 2015, at 04:04 PM, Nick Coghlan wrote:
>New draft pushed: https://hg.python.org/peps/rev/f602a47ea795
>
>This is a significant rewrite that switches the PEP to a Standards Track PEP
>proposing two new features for 2.7.12+: an "ssl._verify_https_certificates()"
>configuration function, a
On Dec 02, 2015, at 08:35 AM, Guido van Rossum wrote:
>I wholeheartedly agree with what Nick writes there
As do I.
One interesting point will be what *nix calls the /usr/bin thingie for Python
4. It would seem weird to call it /usr/bin/python3 and symlink it to say
/usr/bin/python4.0 but maybe
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 digital s
On Dec 15, 2015, at 05:29 PM, Roy Williams wrote:
>@Kevin correct, that's the point I'd like to discuss. Most other
>mainstream languages that implements async/await expose the programming
>model with Tasks/Futures/Promises as opposed to coroutines PEP 492 states
>'Objects with __await__ method
I don't think this will be at all controversial. Brett suggested, and there
was no disagreement from the PEP editors, that plain text PEPs be deprecated.
reStructuredText is clearly a better format, and all recent PEP submissions
have been in reST for a while now anyway.
I am therefore withdrawin
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
On Jan 15, 2016, at 10:22 AM, Ethan Furman wrote:
>So the question now is: for a standard Enum (meaning no other type besides
>Enum is involved) should __bool__ look to the value of the Enum member to
>determine True/False, or should we always be True by default and make the
>Enum creator add thei
On Jan 17, 2016, at 07:10 PM, Brett Cannon wrote:
>Anyone object if I update PEP 7 to remove the optionality of curly braces
>in PEP 7?
+1 for requiring them everywhere, -1 for a wholesale reformatting of existing
code. New code and significant refactoring/rewriting can adopt braces
everywhere.
On Jan 18, 2016, at 11:43 PM, Victor Stinner wrote:
>Is someone opposed to this PEP 509?
>
>The main complain was the change on the public Python API, but the PEP
>doesn't change the Python API anymore.
>
>I'm not aware of any remaining issue on this PEP.
Have you done any performance analysis fo
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.
In my plan, it would be,
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/python-
On Feb 01, 2016, at 11:40 AM, R. David Murray wrote:
>Well, Brett said it would be optional, though perhaps the above
>paragraph is asking about doing it in our Windows build. But the linux
>distros might make also use the option if it exists, so the question is
>very meaningful. However, you'd
On Feb 06, 2016, at 04:38 PM, Chris Angelico wrote:
>Right, sure. The technical problems are still there. Although I'm
>fairly confident that Debian's binaries would correspond to Debian's
>source - but honestly, if I'm looking for sources for anything other
>than the kernel, I probably want to ge
On Feb 11, 2016, at 09:22 AM, Georg Brandl wrote:
>based on the feedback so far, I revised the PEP. There is now
>a much simpler rule for allowed underscores, with no exceptions.
>This made the grammar simpler as well.
I'd be +1, but there's something missing from the PEP: what the underscores
*
On Feb 11, 2016, at 05:57 PM, Georg Brandl wrote:
>D'oh :) I added (hopefully) clarifying wording.
I saw the diff - perfect! Thanks.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscr
As BDFL-Delegate, I am officially accepting PEP 493.
Congratulations Nick, Robert, and MAL. I want to personally thank Nick for
taking my concerns into consideration, and re-working the PEP to resolve
them. Thanks also to everyone who contributed to the discussion.
Cheers,
-Barry
pgp7WPyEgE2s
On Apr 05, 2016, at 09:29 PM, Ethan Furman wrote:
>We should either remove it or make the rest of the stdlib work with it.
>Currently, pathlib.*Paths are second-class citizens, and working with them is
>not significantly better than working with os.path.* simply because we have
>to cast to str eve
On Apr 06, 2016, at 12:44 PM, Nick Coghlan wrote:
>The next challenge would then be to make a list of APIs to be updated
>for 3.6 to implicitly accept "rich path" objects via the agreed
>convention, with pathlib.PurePath used as a test class:
>
>* open()
>* codecs.open() (et al)
>* io.*
>* os.path
On Apr 14, 2016, at 09:49 PM, Victor Stinner wrote:
>It would be nice to hear Barry Warsow who was opposed to the PEP in
>january. He wanted to wait until FAT Python was proven to really be faster,
>which is still not case right now. (I mean that I didnt't run seriously
>benchmarks, but early macr
On Apr 14, 2016, at 11:17 PM, Victor Stinner wrote:
>You're right that incrementing the global version is useless for these
>specific cases, and using the version 0 should work. It only matters
>that the version (version? version tag?) is different.
>
>I will play with that. If I don't see any iss
On Apr 15, 2016, at 09:53 AM, Guido van Rossum wrote:
>After a fruitful discussion on python-ideas I've decided that it's fine to
>break lines *before* a binary operator.
Thanks Guido, your changes look great.
-Barry
___
Python-Dev mailing list
Python-
On Apr 21, 2016, at 10:43 PM, Chris Angelico wrote:
>I still have no clue what you're talking about. Every project has a
>leader. If Guido dies, goes insane [1], or gets bored with the Python
>project, someone else can and will take over.
Fortunately, the Python Secret Underground (PSU) which mos
On Apr 26, 2016, at 09:02 AM, Paul Moore wrote:
>I'm not against having an easy reminder of how to unsubscribe, but the
>clickable link on every message that requests that the poster be
>unsubscribed seems like the wrong way to do it, to me...
And yet, we have it anyway!
This list turns on full
On Apr 27, 2016, at 01:40 AM, Steven D'Aprano wrote:
>I don't think it's just Google. If I remember correctly, having a clearly
>visible and *working* unsubscribe link in the body of the email (not merely
>hidden away in the headers where non-technical users would never think to
>look) is a requir
On May 05, 2016, at 11:58 PM, Mark Lawrence via Python-Dev wrote:
>On 05/05/2016 23:22, Stefan Krah wrote
>>
>> Fredrik Lundh is also affected (and might not have received any mail,
>> same as me):
>>
>> https://pypi.python.org/pypi/PIL
Maybe, but then there's the friendly fork:
https://pypi.p
On May 13, 2016, at 06:37 PM, Brett Cannon wrote:
>PEP: NNN
>Title: Adding a file system path protocol
>Version: $Revision$
>Last-Modified: $Date$
>Author: Brett Cannon ,
>Koos Zevenhoven
>Status: Draft
>Type: Standards Track
>Content-Type: text/x-rst
>Created: 11-May-2016
>Post-History:
On May 24, 2016, at 02:03 PM, Koos Zevenhoven wrote:
>I guess we might consider adding __fspath__ in maintenance releases,
>and make open() support it? That would cover a significant share of
>use cases, although it might be weird if code written for 3.5.2
>doesn't run on 3.5.1...
Please, no. We
On Jun 06, 2016, at 01:02 PM, Łukasz Langa wrote:
>There’s a problem with this approach. It will force people to write
>deprecated code because you never know if your library is going to run on
>3.5.0 or 3.5.1. Barry, Ubuntu wily, xenial and yakkety currently package
>3.5.0 or 3.5.1. When 3.5.2 is
On Oct 21, 2013, at 08:46 PM, Nick Coghlan wrote:
>There's also the fact that I prefer the current lower case names, but
>strongly dislike using lower case names for classes (despite the fact
>closing was included in the original contextlib with a non PEP 8 compliant
>class name).
Ha! The only t
On Oct 21, 2013, at 08:46 PM, Nick Coghlan wrote:
>There's also the fact that I prefer the current lower case names, but
>strongly dislike using lower case names for classes (despite the fact
>closing was included in the original contextlib with a non PEP 8 compliant
>class name).
I think PEP 8 n
201 - 300 of 2704 matches
Mail list logo
