Re: [Python-Dev] My first post here ~ do you need more Python core developers on Windows?

Thank you for the warm welcome and the links. I will definitely check them out. Burkhard On Mon, Apr 18, 2016 at 1:16 AM, Victor Stinner wrote: > 2016-04-18 7:23 GMT+02:00 Burkhard Meier : > > My name is Burkhard Meier and I wrote the "Python GUI Programming > Cookbook" > > published by Packt.

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

On Apr 18, 2016 3:19 PM, "Ethan Furman" wrote: > > On 04/18/2016 12:54 PM, Wes Turner wrote: > >> Don't we *have* to always support bytes because other programs can >> create filenames containing bytes? > > > Yes, but not every function has to support bytes. Because there's no function overloadin

Re: [Python-Dev] [Python-ideas] pep 7 line break suggestion differs from pep 8

[ideas to bcc] I'm not as excited about this as I am about the PEP 8 change. PEP 8 affects most Python programmers. But PEP 7 is really just for CPython and its extensions, and I don't think it has found anything like as widespread a following as PEP 8. I worry that if we change this in PEP 7 w

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

On 04/18/2016 12:26 PM, Stephen J. Turnbull wrote: I haven't looked at Antipathy, but I would guess from Ethan's promotion of bytes paths and concern with efficiency that "bytes antipaths" do *not* "go through" str to get to bytes, they already are bytes (in the sense of class inheritance). Co

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

On 04/18/2016 02:58 PM, Koos Zevenhoven wrote: It's a matter of documentation whether it "supports" bytes or not. In fact, that function (assuming the name os.fspath) could now even be documented to support this: patharg = os.fspath(patharg, output_types = (str, pathlib.PurePath)) # :-)

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

On Mon, Apr 18, 2016 at 5:03 PM, Ethan Furman wrote: > On 04/18/2016 12:41 AM, Nick Coghlan wrote: > >> Given the variant you [Koos] suggested, what if we defined the API >> semantics >> like this: >> >> # Offer the simplest possible API as the public vesion >> def fspath(pathlike) -> st

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 of a character string using bytes. > It's us

Re: [Python-Dev] [Python-ideas] pep 7 line break suggestion differs from pep 8

On Tue, Apr 19, 2016 at 5:33 AM, Joseph Jevnik wrote: > I saw that there was recently a change to pep 8 to suggest adding a line > break before a binary operator. Pep 7 suggests the opposite: > >> When you break a long expression at a binary operator, the operator goes >> at the end of the previou

Re: [Python-Dev] [Question][Asyncio] Process + Threads + asyncio... has sense?

Oks. Thank you very much. --- *Daniel García (cr0hn)* Security researcher and ethical hacker *Personal site*: http://cr0hn.com *Linkedin*: https://www.linkedin.com/in/garciagarciadaniel *Company*: http://abirtone.com *Twitter*: @ggdaniel El día 18 de abril de 2016

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

On 04/18/2016 12:54 PM, Wes Turner wrote: Don't we *have* to always support bytes because other programs can create filenames containing bytes? Yes, but not every function has to support bytes. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@pyth

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

On Apr 18, 2016 2:50 PM, "Ethan Furman" wrote: > > On 04/18/2016 12:25 PM, Stephen J. Turnbull wrote: > >> Koos Zevenhoven writes: > > >>> After all, we want something that's *almost* exclusively str. >> >> >> But we don't want that, AFAICT. Some clearly want this API to be >> unbiased against by

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

On 04/18/2016 12:25 PM, Stephen J. Turnbull wrote: Koos Zevenhoven writes: After all, we want something that's *almost* exclusively str. But we don't want that, AFAICT. Some clearly want this API to be unbiased against bytes in the same way the os APIs are unbiased[2], because that's what w

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

On Mon, Apr 18, 2016, at 15:26, Stephen J. Turnbull wrote: > in > particular it is not true for DirEntry (which is a "enhanced > degenerate" path containing only one path segment but also other > useful information abot the filesystem object addressed) DirEntry contains multiple path segments -

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

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 of a character string using bytes. It's using "encoding" generically for "representation" that makes your head h

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

I don't disagree with the basic analysis, but there are a number of issues with motivational statements. Koos Zevenhoven writes: > (B) "str-based only" > *Accept*: str, provided via __fspath__ as well as plain str. > *Return*: str. > *Audience*: relatively low-level code that works exclusivel

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] [Question][Asyncio] Process + Threads + asyncio... has sense?

A better place for this question would be the tulip Google group: https://groups.google.com/forum/#!forum/python-tulip On Mon, Apr 18, 2016 at 3:05 AM, cr0hn wrote: > Hi all, > > It's the first time I write in this list. Sorry if it's not the best place > for this question. > > After I read the

[Python-Dev] [Question][Asyncio] Process + Threads + asyncio... has sense?

Hi all, It's the first time I write in this list. Sorry if it's not the best place for this question. After I read the Asyncio's documentation, PEPs, Guido/Jesse/David Beazley articles/talks, etc, I developed a PoC library that mixes: Process + Threads + Asyncio Tasks, doing an scheme like this d

Re: [Python-Dev] Updated PEP 509

On 18 April 2016 at 12:46, Jim J. Jewett wrote: >> >> * I removed the dict[key]=value; dict[key]=value. It's really a >> micro-optimization. I also fear that Raymond will complain because it >> adds an if in the hot code of dict, and the dict type is very >> important for Python performance. > > T

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

On 04/18/2016 12:41 AM, Nick Coghlan wrote: Given the variant you [Koos] suggested, what if we defined the API semantics like this: # Offer the simplest possible API as the public vesion def fspath(pathlike) -> str: return os._raw_fspath(pathlike) # Expose the complexit

Re: [Python-Dev] Updated PEP 509

On Sat, Apr 16, 2016 at 5:01 PM, Victor Stinner wrote: > * I mentionned that version++ must be atomic, and that in the case of > CPython, it's done by the GIL Better; if those methods *already* hold the GIL, it is worth saying "already", to indicate that the change is not expensive. > * I remove

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

On Fri, Apr 15, 2016 at 7:31 PM, Victor Stinner wrote: > .2016-04-15 23:45 GMT+02:00 Jim J. Jewett : ... >> I just worry that you may end up closing off even better optimizations >> later, if you make too many promises about exactly how you will do >> which ones. >> Today, dict only cares about =

Re: [Python-Dev] My first post here ~ do you need more Python core developers on Windows?

2016-04-18 7:23 GMT+02:00 Burkhard Meier : > My name is Burkhard Meier and I wrote the "Python GUI Programming Cookbook" > published by Packt. > > It is available on Amazon and PacktPub.com. Welcome! > Maybe I can become more involved in the Python community as a Python > developer on Windows .

Re: [Python-Dev] My first post here ~ do you need more Python core developers on Windows?

On 18 April 2016 at 15:23, Burkhard Meier wrote: > Maybe I can become more involved in the Python community as a Python > developer on Windows . > Welcome! We definitely still have a marked skew towards Linux and *nix programmers in general relative to the global software development population,

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

On 18 April 2016 at 07:05, Koos Zevenhoven wrote: > On Sun, Apr 17, 2016 at 9:14 PM, Ethan Furman wrote: > > On 04/17/2016 06:58 AM, Koos Zevenhoven wrote: > > > >> So, as a summary: With a str+bytes-polymorphic __fspath__, with the > >> above argumentation and the rough implementation of os.fsp