Re: [Python-Dev] PEP 0492 __aenter__ & __aexit__

so knowing that the most up-to-date info is actually the docs and not the PEP would be good. I honestly just know all of this stuff because of a massive blog post I'm writing on async/await ATM. -Brett > > Yury > > On 2016-02-06 5:05 PM, Brett Cannon wrote: > > > &

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Wed, 10 Feb 2016 at 14:21 Georg Brandl wrote: > This came up in python-ideas, and has met mostly positive comments, > although the exact syntax rules are up for discussion. > > cheers, > Georg > > > > > PEP: 515 >

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Thu, 11 Feb 2016 at 02:13 Steven D'Aprano wrote: > On Wed, Feb 10, 2016 at 08:41:27PM -0800, Andrew Barnert wrote: > > > And honestly, are you really claiming that in your opinion, "123_456_" > > is worse than all of their other examples, like "1_23__4"? > > Yes I am, because 123_456_ looks li

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals

On Thu, 11 Feb 2016 at 00:23 Georg Brandl wrote: > Hey all, > > 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. > > --

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

On Sat, Feb 13, 2016, 00:49 Georg Brandl wrote: > Hi all, > > after talking to Guido and Serhiy we present the next revision > of this PEP. It is a compromise that we are all happy with, > and a relatively restricted rule that makes additions to PEP 8 > basically unnecessary. > +1 from me. >

Re: [Python-Dev] Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True)

On Tue, 16 Feb 2016 at 20:59 Mike Kaplinskiy wrote: > Hey folks, > > I hope this is the right list for this sort of thing (python-ideas seemed > more far-fetched). > > For some context: there is currently a issue with pex that causes > sys.modules lookups to stop working for __main__. In turns th

Re: [Python-Dev] Thank you.

This is the appropriate list to post "thanks" to, and you're welcome! Glad we have been able to make your life happier. On Sun, 21 Feb 2016 at 02:28 Alexander Walters wrote: > I don't know if it is appropriate for this list, or not. I don't > exactly care. As much as I might disagree with some

[Python-Dev] Responding in a nice way (was: Python should be easily compilable on Windows with MinGW

On Fri, 26 Feb 2016 at 10:18 Alexander Walters wrote: > You mean honestly pointing out what would happen with a suggestion? It > is a horrifically bad idea. I didn't say they were bad people. > You're right, you didn't directly insult Mathieu, but the tone was unnecessary. Calling mingw a "jenk

Re: [Python-Dev] Very old git mirror under github user "python-git"

On Sun, 28 Feb 2016 at 09:58 Chris Angelico wrote: > On Mon, Feb 29, 2016 at 4:46 AM, Georg Brandl wrote: > > Although I don't see much confusion; there's bound to be > > hundreds of forks of CPython, if not already, then definitely once we > move to > > GitHub. > > Forks made within the GitHub

Re: [Python-Dev] Question about sys.path and sys.argv and how packaging (may) affects default values

On Wed, 2 Mar 2016 at 09:12 Michael Felt wrote: > Hello all, > > 1) There are many lists to choose from - if this is the wrong one for > questions about packaging - please forgive me, and point me in the right > direction. > So in this instance you're after python-list since this is a general su

Re: [Python-Dev] Requesting review for the patch in issue26271

FYI I've reviewed Daniel's patch -- which LGTM -- and assigned it to myself to make sure it gets committed (although if someone has time to commit the patch today they can feel free). On Sat, 5 Mar 2016 at 11:27 Daniel Shaulov wrote: > Hi, > > issue26271 has a patch attached that fixes it. Can s

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

On Wed, 9 Mar 2016 at 06:57 Victor Stinner wrote: > 2016-02-08 15:18 GMT+01:00 Victor Stinner : > >> Perhaps if you add some guards somewhere :-) > > > > We have runtime checks but only implemented in debug mode for efficiency. > > > > By the way, I proposed once to add an environment variable to

Re: [Python-Dev] What does a double coding cookie mean?

On Tue, 15 Mar 2016 at 13:31 Guido van Rossum wrote: > I came across a file that had two different coding cookies -- one on > the first line and one on the second. CPython uses the first, but mypy > happens to use the second. I couldn't find anything in the spec or > docs ruling out the second in

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

Where did this PEP leave off? Anything blocking its acceptance? On Sat, 13 Feb 2016 at 00:49 Georg Brandl wrote: > Hi all, > > after talking to Guido and Serhiy we present the next revision > of this PEP. It is a compromise that we are all happy with, > and a relatively restricted rule that mak

Re: [Python-Dev] What does a double coding cookie mean?

On Thu, 17 Mar 2016 at 07:56 Guido van Rossum wrote: > On Thu, Mar 17, 2016 at 5:04 AM, Serhiy Storchaka > wrote: > >> Should we recommend that everyone use tokenize.detect_encoding()? > > > > Likely. However the interface of tokenize.detect_encoding() is not very > > simple. > > I just found th

Re: [Python-Dev] Counting references to Py_None

On Sun, 20 Mar 2016 at 09:44 Facundo Batista wrote: > Hello! > > I'm seeing that our code increases the reference counting to Py_None, > and I find this a little strange: isn't Py_None eternal and will never > die? > Semantically yes, but we have to technically make that happen. :) > > What's

Re: [Python-Dev] Not receiving bug tracker emails

I just got an email from b.p.o so it's working at least in general. On Tue, Mar 29, 2016, 16:31 Martin Panter wrote: > For the last ~36 hours I have stopped receiving emails for messages > posted in the bug tracker. Is anyone else having this problem? Has > anything changed recently? > > I have

Re: [Python-Dev] Not receiving bug tracker emails

This is probably the wrong place to be posting as there's an issue tracker for the issue tracker. Anyways this might be a solution: http://psf.upfronthosting.co.za/roundup/meta/issue568 On Sat, Apr 2, 2016, 00:54 Victor Stinner wrote: > Any progress on the issue? > > Victor > > > Le jeudi 31 ma

Re: [Python-Dev] Not receiving bug tracker emails

On Mon, 4 Apr 2016 at 14:05 Terry Reedy wrote: > On 3/29/2016 7:30 PM, Martin Panter wrote: > > For the last ~36 hours I have stopped receiving emails for messages > > posted in the bug tracker. Is anyone else having this problem? Has > > anything changed recently? > > My udel dot edu account is

[Python-Dev] Anyone want to lead the sprints at PyCon US 2016?

The call has started to go out for sprint groups to list themselves online. Anyone want to specifically lead the core sprint this year? If no one specifically does then I will sign us up and do my usual thing of pointing people at the devguide and encourage people to ask questions but not do a lot

[Python-Dev] When should pathlib stop being provisional?

After a rather extensive discussion on python-ideas about pathlib.PurePath not inheriting from str, another point that came up was that the use of pathlib has been rather light. Unfortunately even the stdlib doesn't really use pathlib because it's currently marked as provisional (or at least that's

Re: [Python-Dev] When should pathlib stop being provisional?

omment came from). > I'm sure there was a discussion about this when PEP 428 was originally > proposed, and I recall I was strongly in the camp of "it should not > inherit from str", but unfortunately the PEP has no mention of this > discussion or even the stated reason. &g

[Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

WIth Ethan volunteering to do the work to help make a path protocol a thing -- and I'm willing to help along with propagating this through the stdlib where I think Serhiy might be interested in helping as well -- and a seeming consensus this is a good idea, it seems like this proposal has a chance

Re: [Python-Dev] Defining a path protocol

erent semantic meaning. See the __index__ PEP for reasons why you would tightly bound protocols instead of overloading ones like __int__ for multiple meanings. -Brett > > Le 06/04/2016 19:26, Brett Cannon a écrit : > > WIth Ethan volunteering to do the work to help make a path protocol

Re: [Python-Dev] When should pathlib stop being provisional?

On Wed, 6 Apr 2016 at 10:41 Wes Turner wrote: > * +1 for __path__, __fspath__ > (though I don't know what each does) > Returns a string representing a file system path. > * why not Text(basestring / bytestring) and pathlib.Path(Text)? > See the points about next() vs __next__() >* are

Re: [Python-Dev] Defining a path protocol

On Wed, 6 Apr 2016 at 11:06 Ethan Furman wrote: > On 04/06/2016 10:26 AM, Brett Cannon wrote: > > > WIth Ethan volunteering to do the work to help make a path protocol a > > thing -- and I'm willing to help along with propagating this through the > > stdlib

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

On Wed, 6 Apr 2016 at 12:29 Ryan Gonzalez wrote: > -- > Ryan > [ERROR]: Your autotools build scripts are 200 lines longer than your > program. Something’s wrong. > http://kirbyfan64.github.io/ > > > On Apr 6, 2016 12:28 PM, "Brett Cannon" wrote: > > >

Re: [Python-Dev] Defining a path protocol

On Wed, 6 Apr 2016 at 12:32 Paul Moore wrote: > On 6 April 2016 at 19:32, Brett Cannon wrote: > >> > Now we need clear details. :) Some open questions are: > >> > > >> > 1. Name: __path__, __fspath__, or something else? > >> > >> __fsp

Re: [Python-Dev] Defining a path protocol

On Wed, 6 Apr 2016 at 12:38 Oleg Broytman wrote: > On Wed, Apr 06, 2016 at 11:54:08AM -0700, Ethan Furman > wrote: > > On 04/06/2016 11:32 AM, Brett Cannon wrote: > > >On Wed, 6 Apr 2016 at 11:06 Ethan Furman wrote: > > >>On 04/06/2016 10:26 AM, Brett Cannon wr

Re: [Python-Dev] Defining a path protocol

On Wed, 6 Apr 2016 at 13:20 Sven R. Kunze wrote: > On 06.04.2016 21:02, Alexander Belopolsky wrote: > > On Wed, Apr 6, 2016 at 2:32 PM, Brett Cannon wrote: > > +1 for __path__, +0 for __fspath__Â (I don't know how widespread the >> notion that "fs" means &quo

Re: [Python-Dev] Defining a path protocol

On Wed, 6 Apr 2016 at 13:54 Sven R. Kunze wrote: > On 06.04.2016 22:28, Brett Cannon wrote: > > On Wed, 6 Apr 2016 at 13:20 Sven R. Kunze < > srku...@mail.de> wrote: > > >> What about >> >> __file_path__ >> > > Can be a directory as well

Re: [Python-Dev] When should pathlib stop being provisional?

On Wed, 6 Apr 2016 at 14:03 Wes Turner wrote: > > On Apr 6, 2016 12:47 PM, "Brett Cannon" wrote: > > > > > > > > On Wed, 6 Apr 2016 at 10:41 Wes Turner wrote: > >> > >> * +1 for __path__, __fspath__ > >> (though I don'

Re: [Python-Dev] Defining a path protocol

On Wed, 6 Apr 2016 at 15:22 Paul Moore wrote: > On 6 April 2016 at 20:39, Brett Cannon wrote: > >> I'm a little confused by this. To support the older pathlib, they have > >> to do patharg = str(patharg), because *none* of the proposed > >> attri

Re: [Python-Dev] Defining a path protocol

On Wed, 6 Apr 2016 at 16:25 Nathaniel Smith wrote: > On Wed, Apr 6, 2016 at 3:46 PM, Brett Cannon wrote: > > > > > > On Wed, 6 Apr 2016 at 15:22 Paul Moore wrote: > >> > >> So I think we need a builtin. > > > > > > Well, the ugliness sh

Re: [Python-Dev] Defining a path protocol

odules and expect anything but pain. :P > Ah, good point. I think that kills __path__ then as an option. -Brett > > __gps__ > > > > On Wed, Apr 6, 2016 at 3:46 PM Brett Cannon wrote: > >> On Wed, 6 Apr 2016 at 15:22 Paul Moore wrote: >> >>> On 6 Apri

Re: [Python-Dev] Defining a path protocol

On Fri, 8 Apr 2016 at 08:33 Ethan Furman wrote: > On 04/08/2016 02:50 AM, Nick Coghlan wrote: > > >> Built-in? (name is dependent on #1 if we add one) > > > > os.fspath (alongside os.fsencode and os.fsdecode) > > I like this better. > > > >> Add the method/attribute to str? (I assume so, much lik

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

On Fri, 8 Apr 2016 at 09:05 Chris Barker wrote: > On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote: > >> On 7 April 2016 at 03:26, Brett Cannon wrote: >> > > >> > Method or attribute? (changes what kind of one-liner you might use in >> > libraries, b

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

On Fri, 8 Apr 2016 at 09:13 Koos Zevenhoven wrote: > Nick Coghlan wrote: > > On 7 April 2016 at 03:26, Brett Cannon wrote: > >> > >> Name: __path__, __fspath__, or something else? > > > > __fspath__ > > > > I think I might like this dunder nam

Re: [Python-Dev] Defining a path protocol

On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote: > On 04/08/2016 09:04 AM, Chris Barker wrote: > > On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote: > > >> Method, as long as there's a helper function somewhere > > > > what has the helper function got to do with whether it's a method or > > attr

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote: > On 04/08/2016 10:46 AM, Koos Zevenhoven wrote: > > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote: > >> On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote: > > >>> I'm still thinking a little bit about 'pathname', which to me sounds >

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote: > On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker > wrote: > > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven > wrote: > >> > >> > > >> > __pathstr__ # pathstring > >> > > >> > >> Or perhaps __pathstring__ in case it may be or return byte strings

Re: [Python-Dev] Incomplete Internationalization in Argparse Module

On Fri, 8 Apr 2016 at 14:05 Grady Martin wrote: > Hello, all. I was wondering if the following string was left untouched by > gettext for a purpose (from line 720 of argparse.py, in class > ArgumentError): > > 'argument %(argument_name)s: %(message)s' > > There may be other untranslatable string

Re: [Python-Dev] Defining a path protocol

On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote: > On Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon wrote: > > On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote: > >> > I thought the whole point off all this is that not any old string can > be > >> > a pa

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, 8 Apr 2016 at 15:21 Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > > On Apr 8, 2016, at 3:00 PM, Eric Snow > wrote: > > > >> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote: > >> I personally still like __ospath__ as we

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, Apr 8, 2016, 16:13 Glenn Linderman wrote: > On 4/8/2016 3:28 PM, Eric Snow wrote: > > All this matters because it impacts the value returned from > __ospath__(). Should it return the string representation of the path > for the current OS or some standardized representation? I'd expect >

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote: > On 04/11/2016 09:32 AM, Zachary Ware wrote: > > On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote: > > >> If those examples are anywhere close to accurate, an fspath protocol > that > >> supported both bytes and str seems a lot easier to work

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 11:28 Ethan Furman wrote: > On 04/11/2016 10:36 AM, Brett Cannon wrote: > > On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote: > > >> I'm not saying that bytes paths are common -- and if this was a > >> brand-new feature I wouldn't be

Re: [Python-Dev] pathlib+os/shutil feedback

On Mon, 11 Apr 2016 at 13:40 Sven R. Kunze wrote: > On 10.04.2016 16:51, Paul Moore wrote: > > On 10 April 2016 at 15:07, Sven R. Kunze wrote: > >> If there's some agreement to change things with respect to those 5 > points, I > >> am willing to put some time into it. > > In broad terms I agree

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 14:11 Ethan Furman wrote: > On 04/11/2016 01:42 PM, Victor Stinner wrote: > > 2016-04-11 21:00 GMT+02:00 Brett Cannon: > > >> I'm -0 on allowing __fspath__ to return bytes, but we can see what > others > >> think. > > > > W

[Python-Dev] Summary of the pathlib discussion (Re: Maybe, just maybe, pathlib doesn't belong.)

On Mon, 11 Apr 2016 at 14:42 Ben Finney wrote: > Alexander Walters writes: > > > That is great news. I just couldn't see it myself in the threads > > Agreed. A summary posting, from someone who has a good handle on the > issue and outcome, would be very helpful. > - Guido has put Chris Ang

Re: [Python-Dev] Not receiving bug tracker emails

Glad it's working again! And it was a combination or R. David Murray, Ezio Melotti, Mark Mangoba ( http://pyfound.blogspot.com/2016/04/the-psf-has-hired-it-manager.html in case you don't know who Mark is), and myself along with Upfront (b.p.o hosting provider). On Tue, 12 Apr 2016 at 21:40 Terry R

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Wed, 13 Apr 2016 at 05:57 Tim Golden wrote: > On 13/04/2016 12:40, Victor Stinner wrote: > > Last months, most 3.x buildbots failed randomly. Some of them were > > always failing. I spent some time to fix almost all Windows and Linux > > buildbots. There were a lot of different issues. > > Can

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Wed, 13 Apr 2016 at 06:14 Stefan Krah wrote: > Victor Stinner gmail.com> writes: > > Maybe it's time to move more 3.x buildbots to the "stable" category? > > http://buildbot.python.org/all/waterfall?category=3.x.stable > > +1 I think anything that is actually stable should be in that category

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, 13 Apr 2016 at 09:19 Fred Drake wrote: > On Wed, Apr 13, 2016 at 11:09 AM, Ethan Furman wrote: > > - a single os.fspath() with an allow_bytes parameter > > (mostly True in os and os.path, mostly False everywhere > > else) > > -0 > > > - a str-only os.fspathname() and a str/bytes os.f

Re: [Python-Dev] pathlib - current status of discussions

On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < python-dev@python.org> wrote: > Ethan Furman stoneleaf.us> writes: > > > Do we allow bytes to be returned from os.fspath()? If yes, then do we > > allow bytes from __fspath__()? > > De-lurking. Especially since the ultimate goal is b

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Wed, 13 Apr 2016 at 09:52 Random832 wrote: > On Wed, Apr 13, 2016, at 11:28, Ethan Furman wrote: > > On 04/13/2016 08:17 AM, Random832 wrote: > > > On Wed, Apr 13, 2016, at 10:21, Nick Coghlan wrote: > > > > >> I'd expect the main consumers to be os and os.path, and would honestly > > >> be su

Re: [Python-Dev] pathlib - current status of discussions

On Wed, 13 Apr 2016 at 12:25 Chris Angelico wrote: > On Thu, Apr 14, 2016 at 3:10 AM, Brett Cannon wrote: > > https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 > has the > > four potential approaches implemented (although it doesn't follow the

Re: [Python-Dev] pathlib - current status of discussions

On Wed, 13 Apr 2016 at 12:39 Fred Drake wrote: > On Wed, Apr 13, 2016 at 3:24 PM, Chris Angelico wrote: > > Is that the intention, or should the exception catching be narrower? I > > know it's clunky to write it in Python, but AIUI it's less so in C: > > > > try: > > callme = path.__fspath__

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Wed, 13 Apr 2016 at 13:17 Zachary Ware wrote: > [SNIP] > --- > > After receiving a suggestion from koobs several months ago, I've been > intermittently thinking about completely redoing our buildmaster setup > such that instead of a single builder per version on each slave, we > instead set up

Re: [Python-Dev] pathlib - current status of discussions

ide-tracked over some example code to just get a concept across. -Brett > > -CHB > > > > On Wed, Apr 13, 2016 at 12:54 PM, Brett Cannon wrote: > >> >> >> On Wed, 13 Apr 2016 at 12:39 Fred Drake wrote: >> >>> On Wed, Apr 13, 2016 at 3:24 PM

Re: [Python-Dev] pathlib - current status of discussions

On Wed, 13 Apr 2016 at 15:46 Nikolaus Rath wrote: > On Apr 13 2016, Brett Cannon wrote: > > On Tue, 12 Apr 2016 at 22:38 Michael Mysinger via Python-Dev < > > python-dev@python.org> wrote: > > > >> Ethan Furman stoneleaf.us> writes: > >> > &

Re: [Python-Dev] pathlib - current status of discussions

an exception than the rule. I > would be more a micro-optimization than a good reason to drive the API > design. > Yep, it's interesting to know but Chris and I won't let it drive the decision (I assume). -Brett > > Victor > > Le mercredi 13 avril 2016, Brett Can

Re: [Python-Dev] Most 3.x buildbots are green again, please don't break them and watch them!

On Thu, 14 Apr 2016 at 03:26 Victor Stinner wrote: > > Le 14 avr. 2016 11:16 AM, "Serhiy Storchaka" a > écrit : > > A desirable but nonexistent feature is to write emails to authors of > commits that broke buildbots. How hard to implement this? > > Yeah I also had this idea since many years but

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

.org/dev/peps/pep-0510/>`_ proposes an API to support > specialized functions with guards. It allows to implement static > optimizers for Python without breaking the Python semantics. > > Example of a static Python optimizer: the `fatoptimizer > <http://fatoptimizer.readthedocs.org/&g

Re: [Python-Dev] MAKE_FUNCTION simplification

On Thu, 14 Apr 2016 at 09:16 Nikita Nemkin wrote: > On Thu, Apr 14, 2016 at 8:32 PM, Victor Stinner > wrote: > > > > Would you like to work on a patch to implement that change? > > I'll work on a patch. Should I post it to bugs.python.org? > Yep. > > > Since Python 3.6 may get a new bytecode

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

On Thu, 14 Apr 2016 at 15:14 Victor Stinner wrote: > 2016-04-14 23:29 GMT+02:00 Barry Warsaw : > > I can see why you might want a global version number, but not doing so > would > > eliminate an implicit reliance on the GIL, or in a GIL-less > implementation > > a lock around incrementing the gl

Re: [Python-Dev] RFC: PEP 509: Add a private version to dict

On Thu, Apr 14, 2016, 17:14 MRAB wrote: > On 2016-04-14 21:42, Armin Rigo wrote: > > Hi Victor, > > > > On 14 April 2016 at 17:19, Victor Stinner > wrote: > >> Each time a dictionary is created, the global > >> version is incremented and the dictionary version is initialized to the > >> global v

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Sun, 17 Apr 2016 at 06:59 Koos Zevenhoven wrote: > On Sun, Apr 17, 2016 at 11:03 AM, Stephen J. Turnbull > wrote: > > Nick Coghlan writes: > > > > > str and bytes aren't going to implement __fspath__ (since they're > > > only *sometimes* path objects), so asking people to call the > > > pr

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 18 Apr 2016 at 12:26 Stephen J. Turnbull wrote: > Brett Cannon writes: > > > If we continue with the "str is an encoding of file paths", > > It's not. It's a representation, but not an encoding. In Python 3, > encoding means a representation

Re: [Python-Dev] Dependent packages not listed on PyPI

Questions about PyPI should be directed at the distutils-sig mailing list. On Tue, 19 Apr 2016 at 08:12 Andreas Maier wrote: > Hi, > I have a package "pywbem" which in its setup script specifies a number of > dependent packages via "install_requires". > > I should also say that it extends setupt

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, 19 Apr 2016 at 04:46 Stephen J. Turnbull wrote: > Brett Cannon writes: > > On Mon, 18 Apr 2016 at 12:26 Stephen J. Turnbull > wrote: > > > Well, it makes *your* head hurt; > > It doesn't, because I have a different (and IMHO better) model. I can &

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, 19 Apr 2016 at 15:22 Eric Snow wrote: > On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon wrote: > > Ah, but you see that doesn't make porting easy. If I have a bunch of > > path-manipulating code using os.path already and I want to add support > for > > pat

Re: [Python-Dev] Discussion on fspath: please wait for a PEP

On Wed, 20 Apr 2016 at 07:07 Chris Angelico wrote: > On Wed, Apr 20, 2016 at 11:58 PM, Ethan Furman wrote: > > On 04/20/2016 04:52 AM, Victor Stinner wrote: > > > >> Can you please wait for a PEP? Brett Canon and Ethan Furman are > >> working on a PEP. > I was actually going to send this email

Re: [Python-Dev] Discussion on fspath: please wait for a PEP

On Wed, 20 Apr 2016 at 10:51 Koos Zevenhoven wrote: > On Wed, Apr 20, 2016 at 7:34 PM, Victor Stinner > wrote: > > > > 2016-04-20 18:12 GMT+02:00 Brett Cannon : > >> > >> I thought Chris and I w/ Ethan helping with coding, but if it's just me > for &

Re: [Python-Dev] Terminal console

Can someone disable this person's subscription? On Mon, 25 Apr 2016 at 14:15 Kenny via Python-Dev wrote: > > fopen Terminal.app.python. > 3.5.0.() > > def fopen Termina.app.python.3.5.0.() > > %add.%data(CDATA[])::true||false > > fclose(); > > end Terminal.app.python.3.5.0.() > > Yours thingy >

Re: [Python-Dev] Terminal console

On Mon, 25 Apr 2016 at 14:45 Tim Peters wrote: > [Tim Golden , on Kenny the "thingy" guy] > > Not subscribed; probably via gmane. > > They were subscribed, but I already did the unsub. > > > > I've added him to a hold list via spam filter. See if that works. > > So now we're doubly safe ;-) > We

Re: [Python-Dev] Terminal console

;http://python.org> from python-dev here>...* > > So someone might have mistakenly clicked that link, thinking they were > helping to remove Kenny's subscription, for what it's worth. > Good point. Hopefully that's all it was then. -Brett > > > On Mon, Apr 25,

Re: [Python-Dev] Anyone want to lead the sprints at PyCon US 2016?

No one stepped forward to lead the sprints this year, so I will put myself as the sprint leader and lean on everyone else who appears to help. :) On Tue, 5 Apr 2016 at 09:36 Brett Cannon wrote: > The call has started to go out for sprint groups to list themselves > online. Anyone w

Re: [Python-Dev] Bug in 2to3 concerning import statements?

On Sat, 30 Apr 2016 at 21:51 Greg Ewing wrote: > It seems that 2to3 is a bit simplistic when it comes to > translating import statements. I have a module GUI.py2exe > containing: > > import py2exe.mf as modulefinder > > 2to3 translates this into: > > from . import py2exe.mf as modulefinde

Re: [Python-Dev] Looking for a Python programming mentor

If you mean for Python in general, then Python+list or python-tutor are a more appropriate mailing lists. If you mean for core development then core-workflow is where to ask for help. On Sun, May 1, 2016, 14:11 Burkhard Meier wrote: > I don't need Sigmund Freud... > > Burkhard >

Re: [Python-Dev] Yearly PyPI breakage

On Tue, 3 May 2016 at 12:06 Stefan Krah wrote: > > Hello, > > Could someone enlighten me which hoops I have to jump through > this year in order to keep pip downloads working? > > Collecting cdecimal > Could not find a version that satisfies the requirement cdecimal (from > versions: ) > No mat

Re: [Python-Dev] Restore functions pickling

On Wed, 4 May 2016 at 11:39 Всеволод Величко wrote: > Hello, > > I was recently porting my application from Py2 to Py3 and encountered > error, when I accidentally became unable to define my own pickling > mechanism for functions. > Before that I was using it to pickle pure lambdas, registering m

Re: [Python-Dev] Yearly PyPI breakage

On Thu, 5 May 2016 at 16:54 David Wilson wrote: > This is mostly just observational, and not meant primarily as criticism > of the fabulous work of Donald and others (ignoring pypa, also the > prompt, reliable, and skilled support responses common on such places as > IRC), however I can't help bu

Re: [Python-Dev] Yearly PyPI breakage

On Thu, 5 May 2016 at 16:00 Mark Lawrence via Python-Dev < python-dev@python.org> 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 > > > > He might be, but clear

Re: [Python-Dev] Anyone want to lead the sprints at PyCon US 2016?

idea or if this is just late night caffeine talking. > I have absolutely no problem if you want to pitch this idea to new contributors who show up at the sprints! -Brett > > > 2016-04-28 20:07 GMT+01:00 Brett Cannon : > >> No one stepped forward to lead the sprints this year, s

Re: [Python-Dev] Tracker Etiquette

I think if you leave a comment that to deleted your own comments and why you did it then it's fine. On Sat, May 7, 2016, 16:07 Ethan Furman wrote: > I just reviewed an issue on the tracker, and found that many, if not > all, of my comments made at the time I completely disagree with (both > now,

[Python-Dev] devinabox has moved to GitHub

https://github.com/python/devinabox The single issue for devinabox has moved to its own issue tracker, so there's no need to worry about those issues cluttering b.p.o in the future. I have made the Python core team I created on GitHub last week have write privileges and Nick and I as admins on the

Re: [Python-Dev] ctypes compatibility with 2.3

On Tue, 10 May 2016 at 01:18 Martin Panter wrote: > I am working on , to fix shell > injection problems with ctypes.util.find_library(). The proposal for > Python 3 is to change os.popen(shell-script) calls to use > subprocess.Popen(). > > However the Python 2.

Re: [Python-Dev] ctypes compatibility with 2.3

On Wed, 11 May 2016 at 04:35 Thomas Heller wrote: > Am 10.05.2016 um 19:39 schrieb Brett Cannon: > > > > > > On Tue, 10 May 2016 at 01:18 Martin Panter > <mailto:vadmium%2...@gmail.com>> wrote: > > > > I am working on <https://bugs.python

Re: [Python-Dev] ctypes compatibility with 2.3

On Wed, 11 May 2016 at 09:07 Thomas Heller wrote: > Am 11.05.2016 um 18:04 schrieb Brett Cannon: > > > > > > On Wed, 11 May 2016 at 04:35 Thomas Heller > <mailto:thel...@ctypes.org>> wrote: > > > > Am 10.05.2016 um 19:39 schrieb Brett Cannon:

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

Is there anything holding up PEP 515 at this point in terms of acceptance or implementation? On Sat, 19 Mar 2016 at 11:56 Guido van Rossum wrote: > All that sounds fine! > > On Sat, Mar 19, 2016 at 11:28 AM, Stefan Krah wrote: > > Guido van Rossum python.org> writes: > >> So should the preproc

[Python-Dev] file system path protocol PEP

$ Author: Brett Cannon Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 11-May-2016 Post-History: 11-May-2016 Abstract This PEP proposes a protocol for classes which represent a file system path to be able to provide a ``str`` or ``bytes`` representation. Changes to

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

On Wed, 11 May 2016 at 09:47 Guido van Rossum wrote: > If the authors are happy I'll accept it right away. > > (I vaguely recall there's another PEP that's ready for pronouncement -- > but which one?) > PEP 509 is the only one I can think of. -Brett > > On

Re: [Python-Dev] PEP 515: Underscores in Numeric Literals (revision 3)

On Wed, 11 May 2016 at 10:49 Guido van Rossum wrote: > On Wed, May 11, 2016 at 10:28 AM, Brett Cannon wrote: > >> >> >> On Wed, 11 May 2016 at 09:47 Guido van Rossum wrote: >> >>> If the authors are happy I'll accept it right away. >>> >&

Re: [Python-Dev] Slow downloads from python.org

On Wed, 11 May 2016 at 10:56 Dima Tisnek wrote: > Sorry, this is probably wrong place to ask, but is it only me? > I can't get more than 40KB/s downloading from python.org It's just you or the problem has passed; just downloaded much faster than 40KB/s. _

Re: [Python-Dev] file system path protocol PEP

ng a file system path protocol > Version: $Revision$ > Last-Modified: $Date$ > Author: Brett Cannon > Status: Draft > Type: Standards Track > Content-Type: text/x-rst > Created: 11-May-2016 > Post-History: 11-May-2016 > > > Abstract > > > This PEP proposes

Re: [Python-Dev] file system path protocol PEP

On Wed, 11 May 2016 at 14:29 Nikolaus Rath wrote: > On May 11 2016, Brett Cannon wrote: > > This PEP proposes a protocol for classes which represent a file system > > path to be able to provide a ``str`` or ``bytes`` representation. > [...] > > As I said before, to me

Re: [Python-Dev] file system path protocol PEP

On Wed, 11 May 2016 at 13:45 Serhiy Storchaka wrote: > On 11.05.16 19:43, Brett Cannon wrote: > > os.path > > ''''''' > > > > The various path-manipulation functions of ``os.path`` [#os-path]_ > > will be updated to accept pa

Re: [Python-Dev] file system path protocol PEP

On Wed, 11 May 2016 at 16:08 Koos Zevenhoven wrote: > On Thu, May 12, 2016 at 1:13 AM, Brett Cannon wrote: > > > > > > On Wed, 11 May 2016 at 13:45 Serhiy Storchaka > wrote: > >> > >> On 11.05.16 19:43, Brett Cannon wrote: > >> >

Re: [Python-Dev] file system path protocol PEP

On Wed, 11 May 2016 at 15:13 Brett Cannon wrote: > On Wed, 11 May 2016 at 13:45 Serhiy Storchaka wrote: > >> On 11.05.16 19:43, Brett Cannon wrote: >> > os.path >> > ''''''' >> > >> > The various path-manipulati

<    1   2   3   4   5   6   7   8   9   10   >