Re: [Python-Dev] obmalloc mmap/munmap thrashing

[Alexander Walters]

...is that a typo for 2.7.11?

On 4/21/2016 17:44, Neil Schemenauer wrote:

I was running Python 2.4.11 under strace and I noticed some odd
looking system calls:

mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f9848681000
munmap(0x7f9848681000, 262144)  = 0
mmap(NULL, 262144, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f9848681000
munmap(0x7f9848681000, 262144)  = 0
[... repeated a number of times ...]

Looking at obmalloc.c, there doesn't seem to be any high/low
watermark (hysteresis) associated with unallocating arenas.  Is that
true?  If so, does it seem prudent to implement something to avoid
this behavior?  It seems potentially expensive if you program is
running just at the threshold of needing another arena.
___
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/tritium-list%40sdamon.com


___
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

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

[Alexander Walters]

On 4/13/2016 13:49, Ethan Furman wrote:
Number 3: it allows bytes, but only when told it's okay to do so. 
Having code get a bytes object when one is not expected is not a 
headache we need to inflict on anyone. 


This is an artifact of the other needless restrictions I said I wouldn't 
rant about.  I think it is in the best interest not to perpetuate those 
needless restrictions.

___
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

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

[Alexander Walters]

On 4/13/2016 13:10, Brett Cannon wrote:
https://gist.github.com/brettcannon/b3719f54715787d54a206bc011869aa1 has 
the four potential approaches implemented (although it doesn't follow 
the "separate functions" approach some are proposing and instead goes 
with the allow_bytes approach I originally proposed). 


Number 4 is my personal favorite - it has a simple control flow path and 
is the least needlessly restrictive.


(I could rant about needless restrictions, but I am about a decade late 
for that, so I wont bother.)

___
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

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

[Alexander Walters]

On 4/12/2016 12:14, Sven R. Kunze wrote:
I cannot remember us using another datetime library. So, I don't value 
this "advantage" as much as you do.


They exist, and there are many cases where you would use a datetime 
library other than datetime for various reasons (integration in third 
party systems is only one reason).  But this is just a tangent.


In fact the situation with pathlib is similar to datetime - before the 
inclusion of datetime in the stdlib, there were several datetime 
libraries available.  Before pathlib, there were several path object 
libraries.  Only now, the third party options offer a great deal of 
competition over the stdlib option, thus these many hundreds, if not 
thousands, of emails on the subject.

___
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

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

[Alexander Walters]

This stance was probably already argued in the threads in question. This 
thread is more of a health-check.  As an observer, it did not look like 
any headway was being made, and I suggested the solimaic solution.  It 
has been pointed out to me that headway IS being made and they are close 
to a solution.  I think this thread can safely be sunset.


On 4/11/2016 17:04, Sven R. Kunze wrote:

On 11.04.2016 22:55, Alexander Walters wrote:
Every conceivable way to fix pathlib have already been argued. Are 
any of them worth doing?  Can we get consensus enough to implement 
one of them?  If not, we should consider either dropping the matter 
or dropping the module.


Right now, I don't see pathlib removed. Why? Because using strings 
alone has its caveats (we all know that). So, I cannot imagine an 
alternative concept to pathlib right now. We might call it 
differently, but the concept stays unchanged.


MAYBE, if there's an alternative concept, I could be convinced to 
support dropping the module.


Best,
Sven

PS: The only way out that I can imagine is to fix pathlib. I am not in 
favor of fixing functions of "os" and "os.path" to except "path" 
objects; which does the majority here discuss now with the new 
__fspath__ protocol. But shaping what we have is definitely worth it.



___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

[Alexander Walters]

That is great news.  I just couldn't see it myself in the threads

On 4/11/2016 16:51, Ethan Furman wrote:

If there is headway being made, I do not see it.


It's being made, and I dare say we are close to the end. 


___
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

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

[Alexander Walters]

If i had my druthers, this thread would be kept to either:

"Shut up alex, we are really close to figuring this out"

or

"Ok, maybe you have a point."

Every conceivable way to fix pathlib have already been argued.  Are any 
of them worth doing?  Can we get consensus enough to implement one of 
them?  If not, we should consider either dropping the matter or dropping 
the module.



On 4/11/2016 16:48, Sven R. Kunze wrote:

On 11.04.2016 22:33, Alexander Walters wrote:

If there is headway being made, I do not see it.


Funny that you brought it up. I was about posting something myself. I 
cannot agree completely. But starting with a comment from Paul, I 
realized that pathlib is something different than a string. After 
doing the research and our issues with pathlib, I found:



- pathlib just needs to be improved (see my 5 points)
- os[.path] should not tinkered with


I know that all of those discussions of a new protocol (path->str, 
__fspath__ etc. etc.) might be rendered worthless by these two 
statements. But that's my conclusion.


"os" and "os.path" are just lower level. "pathlib" is a high-level, 
convenience library. When using it, I don't want to use "os" or 
"os.path" anymore. If I still do, "pathlib" needs improving. *Not "os" 
nor "os.path"*.



Best,
Sven


___
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/tritium-list%40sdamon.com


___
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

[Python-Dev] Maybe, just maybe, pathlib doesn't belong.

[Alexander Walters]

In reviewing the ongoing arguments about how to make pathlib better, 
there have been circular arguments about if it is even broken, if it 
should support bytes, if there should be a path protocol that all 
functions that touch the filesystem should use, if that protocol should 
support bytes, how that protocol should be open or closed to allow third 
party modules to act as paths, etc., etc.


If there is headway being made, I do not see it.

I don't think we can come to an agreement that will make anyone happy, 
or have any effect on the adoption of the pathlib module in the standard 
library.  Maybe, just maybe, since there is an ecosystem of third party 
modules already doing this job (and arguably doing it much better than 
pathlib, and for more supported versions of python than any future 
version of pathlib will), it should be dropped from the standard library 
and left on pypi as a third party module.

___
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

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

[Alexander Walters]

On 4/5/2016 22:44, Nick Coghlan wrote:

Option 4: define a rich-object-to-text path serialisation convention,
as paths are not conceptually the same as arbitrary strings
Just as a nit to pick, it is perfectly acceptable for hypothetical path 
objects to raise when someone tries to shoehorn them into acting like 
arbitrary strings - open() will gladly halt and set fire if you try and 
pass the text of war and peace as an argument.


I think the naysayers would be satisfied with an object that... while 
not str or bytes or a derived class of either... acted like str when it 
had to.  Is that possible without deriving from str or bytes?

___
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

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

[Alexander Walters]

On 4/5/2016 18:55, Guido van Rossum wrote:

  My last/only comment in the discussion
was about there possibly being a dichotomy between people who use
Python for scripting and those who use it to write more substantial
programs (I'm trying not to judge one group more important than
another -- I'm just observing there seem to be these two groups). But
I didn't stick around long enough to watch for responses to this idea.

This was all but ignored.

The opinions mentioned in the thread, without throwing my opinion behind 
any of them were:


* pathlib should be improved (specifically by making it inherit from str)
* the stdlib should be made to deal with pathlib without changing pathlib
* pathlib is redundant to third party modules which work better
* the continued existence of pathlib was briefly discussed

You can insert the never-ending arguments for and against each of those 
points in your head - none of them were particularly convincing (in that 
i don't think anyone changed their position.)


the split between utility scripting and application development was not 
really discussed.

___
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

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

[Alexander Walters]

Can we even ask github to pull it down and reasonably expect them to 
comply?  Their entire model is built on everyone forking everyone else.


On 2/27/2016 06:25, Mathieu Dupuy wrote:

Ahah. Obtaining his electronic coordinates like email to gently ask
him to pull it down by himself (otherwise we open fire). Because
having Github suddenly destroying the repo, even though the man
probably forgot about its existence might be a bit rude from the
polite people python developers are.

2016-02-16 4:27 UTC+08:00, Oleg Broytman :

On Tue, Feb 16, 2016 at 09:16:56AM +1300, Greg Ewing
 wrote:

Mathieu Dupuy wrote:

A python representative (like Guido himself) should contact Github to
obtain coordinates of the owner...

...and then order a drone strike on him?

Yes, and then pry the repo from his cold dead fingers.

Well, I hope prying can be done without striking first. ;-)


--
Greg

Oleg.
--
  Oleg Broytmanhttp://phdru.name/p...@phdru.name
Programmers don't die, they just GOSUB without RETURN.
___
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/deronnax%40gmail.com


___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

[Alexander Walters]

Theoretically yes.  Practically, I think, but do not know for sure, it 
would have the same annoying issues as other SDK builds (of which, the 
most annoying is just different paths for the tools). Making that a 
supported build would require some of the same effort as supporting any 
other compiler though (a build bot configured to compile python this way).


I also think, but am not sure, that what you linked is in fact the 
leaner meaner toolchain that Steve was referring to.



On 2/27/2016 16:49, Chris Krycho wrote:


Outsider/observer here; but is it not possible to build Python using 
the VS *toolchain* (compiler, linker, etc.) outside of VS itself—i.e. 
using MSBuild[1] and so on? That would remove the need for the full VS 
install, and is *much* smaller (~800MB after installation, rather than 
9GB). A lean and mean VS will be a great improvement regardless, but 
it seems like that would be a good intermediate solution if it’s possible.


[1]: https://www.microsoft.com/en-us/download/details.aspx?id=49983

– Chris

On February 27, 2016 at 4:36:54 PM, Alexander Walters 
(tritium-l...@sdamon.com <mailto:tritium-l...@sdamon.com>) wrote:


The 9 gig initial download is not the only problem. Visual studio is 
very bandwidth hungry in day to day operations (between polling 
websites and vcs remotes, near constant updating, integration with 
the VS web service, etc.).  You can of course shut all of that off, 
but it's a pain.  It's my understanding from Steve's post that a 
leaner, meaner edition of VS is in the works, so waiting for that 
might just be an overall better solution.


On 2/27/2016 16:27, Franklin? Lee wrote:


For this particular case, is there someone generous enough (or, can 
someone apply for a PSF grant) to ship Mathieu a DVD/two/flash drive?


On Feb 26, 2016 12:18 PM, "Mathieu Dupuy" <deron...@gmail.com 
<mailto:deron...@gmail.com>> wrote:


Hi.
I am currently working on adding some functionality on a standard
library module (http://bugs.python.org/issue15873). The Python part
went fine, but now I have to do the C counterpart, and I have
ran into
in several problems, which, stacked up, are a huge obstacle to
easily
contribute further. Currently, despite I could work, I can't go
further
on my patch.

I am currently working in very limited network, CPU and time
ressources* which are quite uncommon in the western world, but are
much less in the rest of the world. I have a 2GB/month mobile data
plan and a 100KB/s speed. For the C part of my patch, I should
download Visual Studio. The Express Edition 2015 is roughly 9GB. I
can't afford that.

I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and
Fedora 23). Shortly, I couldn't get something working quickly and
simply (quickly = less than 2 hours, downloading time NOT included,
which is anyway way too already much). What went wrong and why
it went
wrong could be a whole new thread and is outside of the scope of
this
message.
Let me precise this : at my work I use many virtualbox instances
automatically fired and run in parallel to test new deployments and
run unittests. I like this tool,
but despite its simple look, it (most of the time) can not be used
simply by a profane. The concepts it requires you to understand are
not intuitive at first sight and there is *always* a thing that go
wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox
shipped for a moment a broken version of mount.vboxsf, preventing
sharing folder to mount. Despite it's fixed, the broken releases
spread everywhere and you may encounter them a lot in various Ubuntu
and Virtualbox version. I downloaded the last versions of both and I
am yet infected. https://www.virtualbox.org/ticket/12879). I
could do
whole new thread on why you can't ask newcomers to use Virtualbox
(currently, at least).

I ran into is a whole patch set to make CPython compile on MinGW
(https://bugs.python.org/issue3871#msg199695). But it is not denying
it's very experimental, and I know I would again spent useless hours
trying to get it work rather than joyfully improving Python, and
that's exactly what I do not want to happen.

Getting ready to contribute to CPython pure python modules from an
standard, average mr-everyone Windows PC for a beginner-to-medium
contributor only require few megabytes of internet and few
minutes of his
time: getting a tarball of CPython sources (or cloning the
github CPython
mirror)**, a basic text editor and msys-git. The step further,
if doing
some -even basic- C code is required, implies downloading 9GB of
Visual
Studio and countless hours for it to be ready to use.
I think downloading the whole Visual Studio suite is a huge
stopper to
contribute further for an average medium-or-bel

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

[Alexander Walters]

The 9 gig initial download is not the only problem.  Visual studio is 
very bandwidth hungry in day to day operations (between polling websites 
and vcs remotes, near constant updating, integration with the VS web 
service, etc.).  You can of course shut all of that off, but it's a 
pain.  It's my understanding from Steve's post that a leaner, meaner 
edition of VS is in the works, so waiting for that might just be an 
overall better solution.


On 2/27/2016 16:27, Franklin? Lee wrote:


For this particular case, is there someone generous enough (or, can 
someone apply for a PSF grant) to ship Mathieu a DVD/two/flash drive?


On Feb 26, 2016 12:18 PM, "Mathieu Dupuy" > wrote:


Hi.
I am currently working on adding some functionality on a standard
library module (http://bugs.python.org/issue15873). The Python part
went fine, but now I have to do the C counterpart, and I have ran into
in several problems, which, stacked up, are a huge obstacle to easily
contribute further. Currently, despite I could work, I can't go
further
on my patch.

I am currently working in very limited network, CPU and time
ressources* which are quite uncommon in the western world, but are
much less in the rest of the world. I have a 2GB/month mobile data
plan and a 100KB/s speed. For the C part of my patch, I should
download Visual Studio. The Express Edition 2015 is roughly 9GB. I
can't afford that.

I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and
Fedora 23). Shortly, I couldn't get something working quickly and
simply (quickly = less than 2 hours, downloading time NOT included,
which is anyway way too already much). What went wrong and why it went
wrong could be a whole new thread and is outside of the scope of this
message.
Let me precise this : at my work I use many virtualbox instances
automatically fired and run in parallel to test new deployments and
run unittests. I like this tool,
but despite its simple look, it (most of the time) can not be used
simply by a profane. The concepts it requires you to understand are
not intuitive at first sight and there is *always* a thing that go
wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox
shipped for a moment a broken version of mount.vboxsf, preventing
sharing folder to mount. Despite it's fixed, the broken releases
spread everywhere and you may encounter them a lot in various Ubuntu
and Virtualbox version. I downloaded the last versions of both and I
am yet infected. https://www.virtualbox.org/ticket/12879). I could do
whole new thread on why you can't ask newcomers to use Virtualbox
(currently, at least).

I ran into is a whole patch set to make CPython compile on MinGW
(https://bugs.python.org/issue3871#msg199695). But it is not denying
it's very experimental, and I know I would again spent useless hours
trying to get it work rather than joyfully improving Python, and
that's exactly what I do not want to happen.

Getting ready to contribute to CPython pure python modules from an
standard, average mr-everyone Windows PC for a beginner-to-medium
contributor only require few megabytes of internet and few minutes
of his
time: getting a tarball of CPython sources (or cloning the github
CPython
mirror)**, a basic text editor and msys-git. The step further, if
doing
some -even basic- C code is required, implies downloading 9GB of
Visual
Studio and countless hours for it to be ready to use.
I think downloading the whole Visual Studio suite is a huge stopper to
contribute further for an average medium-or-below-contributor.

I think (and I must not be the only one since CPython is to be moved
to github), that barriers to contribute to CPython should be set to
the lowest.
Of course my situation is a bit special but I think it represents
daily struggle of a *lot* of non-western programmer (at least for
limited internet)(even here in Australia, landline limited internet
connections are very common).
It's not a big deal if the MinGW result build is twenty time slower or
if some of the most advanced modules can't be build. But everyone
programmer should be able to easily make some C hacks and get them to
work.

Hoping you'll be receptive to my pleas,
Cheers


* I am currently picking fruits in the regional Australia. I live
in a van
and have internet through with smartphone through an EDGE
connection. I can
plug the laptop in the farm but not in the van.
** No fresh programmer use mercurial unless he has a gun pointed
on his
head.
___
Python-Dev mailing list
Python-Dev@python.org 
https://mail.python.org/mailman/listinfo/python-dev

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

[Alexander Walters]

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.


On 2/26/2016 13:14, Brian Curtin wrote:

The attitude in these responses is counter productive and not really
how it works on this list.

On Fri, Feb 26, 2016 at 1:10 PM, Alexander Walters
<tritium-l...@sdamon.com> wrote:

Ok, fine.  Bring a windows build bot online.  And also take on the support
burden of guiding people to which version of which compiler you use for each
of the currently supported python versions.  And go ahead and write the pep
to change how wheel distributions work (which will effectively kill them, so
yeah, good side benefit there.)

Want to kill python on windows for anything that needs a c extension?  go
ahead, release one version of python with 2 ABIs.

What do I know.


On 2/26/2016 13:05, Dan Stromberg wrote:

But what do you really think?

IMO, windows builds probably should do both visual studio and mingw.
That is, there probably should be two builds on windows, since there's
no clear consensus about which to use.

I certainly prefer mingw over visual studio - and I have adequate
bandwidth for either.


On Fri, Feb 26, 2016 at 9:55 AM, Alexander Walters
<tritium-l...@sdamon.com> wrote:

No.

Visual Studio is a solid compiler suit, mingw is a jenky mess, especially
when you try and move to 64bit (where I don't think there is one true
version of mingw).  I'm sorry that Visual Studio makes it very hard for
you
to contribute, but changing THE compiler of the distribution from the
platform compiler, especially when we FINALLY got a stable abi with it,
is
going to be a non starter.

Compiling on MinGW for your own edification is fine, but that's not the
build platform for windows python, nor should it be. Contributions are,
and
should continue to be, tested against Visual Studio.


On 2/26/2016 05:12, Mathieu Dupuy wrote:

Hi.
I am currently working on adding some functionality on a standard
library module (http://bugs.python.org/issue15873). The Python part
went fine, but now I have to do the C counterpart, and I have ran into
in several problems, which, stacked up, are a huge obstacle to easily
contribute further. Currently, despite I could work, I can't go
further
on my patch.

I am currently working in very limited network, CPU and time
ressources* which are quite uncommon in the western world, but are
much less in the rest of the world. I have a 2GB/month mobile data
plan and a 100KB/s speed. For the C part of my patch, I should
download Visual Studio. The Express Edition 2015 is roughly 9GB. I
can't afford that.

I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and
Fedora 23). Shortly, I couldn't get something working quickly and
simply (quickly = less than 2 hours, downloading time NOT included,
which is anyway way too already much). What went wrong and why it went
wrong could be a whole new thread and is outside of the scope of this
message.
Let me precise this : at my work I use many virtualbox instances
automatically fired and run in parallel to test new deployments and
run unittests. I like this tool,
but despite its simple look, it (most of the time) can not be used
simply by a profane. The concepts it requires you to understand are
not intuitive at first sight and there is *always* a thing that go
wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox
shipped for a moment a broken version of mount.vboxsf, preventing
sharing folder to mount. Despite it's fixed, the broken releases
spread everywhere and you may encounter them a lot in various Ubuntu
and Virtualbox version. I downloaded the last versions of both and I
am yet infected. https://www.virtualbox.org/ticket/12879). I could do
whole new thread on why you can't ask newcomers to use Virtualbox
(currently, at least).

I ran into is a whole patch set to make CPython compile on MinGW
(https://bugs.python.org/issue3871#msg199695). But it is not denying
it's very experimental, and I know I would again spent useless hours
trying to get it work rather than joyfully improving Python, and
that's exactly what I do not want to happen.

Getting ready to contribute to CPython pure python modules from an
standard, average mr-everyone Windows PC for a beginner-to-medium
contributor only require few megabytes of internet and few minutes of
his
time: getting a tarball of CPython sources (or cloning the github
CPython
mirror)**, a basic text editor and msys-git. The step further, if doing
some -even basic- C code is required, implies downloading 9GB of Visual
Studio and countless hours for it to be ready to use.
I think downloading the whole Visual Studio suite is a huge stopper to
contribute further for an average medium-or-below-contributor.

I think (and I must not be the only one since CPython is to be moved
to github), that barriers to contribute to CPython should be set to
the lowest.
Of course my situation is a bit special but I think it represents
da

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

[Alexander Walters]

Ok, fine.  Bring a windows build bot online.  And also take on the 
support burden of guiding people to which version of which compiler you 
use for each of the currently supported python versions.  And go ahead 
and write the pep to change how wheel distributions work (which will 
effectively kill them, so yeah, good side benefit there.)


Want to kill python on windows for anything that needs a c extension?  
go ahead, release one version of python with 2 ABIs.


What do I know.

On 2/26/2016 13:05, Dan Stromberg wrote:

But what do you really think?

IMO, windows builds probably should do both visual studio and mingw.
That is, there probably should be two builds on windows, since there's
no clear consensus about which to use.

I certainly prefer mingw over visual studio - and I have adequate
bandwidth for either.


On Fri, Feb 26, 2016 at 9:55 AM, Alexander Walters
<tritium-l...@sdamon.com> wrote:

No.

Visual Studio is a solid compiler suit, mingw is a jenky mess, especially
when you try and move to 64bit (where I don't think there is one true
version of mingw).  I'm sorry that Visual Studio makes it very hard for you
to contribute, but changing THE compiler of the distribution from the
platform compiler, especially when we FINALLY got a stable abi with it, is
going to be a non starter.

Compiling on MinGW for your own edification is fine, but that's not the
build platform for windows python, nor should it be. Contributions are, and
should continue to be, tested against Visual Studio.


On 2/26/2016 05:12, Mathieu Dupuy wrote:

Hi.
I am currently working on adding some functionality on a standard
library module (http://bugs.python.org/issue15873). The Python part
went fine, but now I have to do the C counterpart, and I have ran into
in several problems, which, stacked up, are a huge obstacle to easily
contribute further. Currently, despite I could work, I can't go
further
on my patch.

I am currently working in very limited network, CPU and time
ressources* which are quite uncommon in the western world, but are
much less in the rest of the world. I have a 2GB/month mobile data
plan and a 100KB/s speed. For the C part of my patch, I should
download Visual Studio. The Express Edition 2015 is roughly 9GB. I
can't afford that.

I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and
Fedora 23). Shortly, I couldn't get something working quickly and
simply (quickly = less than 2 hours, downloading time NOT included,
which is anyway way too already much). What went wrong and why it went
wrong could be a whole new thread and is outside of the scope of this
message.
Let me precise this : at my work I use many virtualbox instances
automatically fired and run in parallel to test new deployments and
run unittests. I like this tool,
but despite its simple look, it (most of the time) can not be used
simply by a profane. The concepts it requires you to understand are
not intuitive at first sight and there is *always* a thing that go
wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox
shipped for a moment a broken version of mount.vboxsf, preventing
sharing folder to mount. Despite it's fixed, the broken releases
spread everywhere and you may encounter them a lot in various Ubuntu
and Virtualbox version. I downloaded the last versions of both and I
am yet infected. https://www.virtualbox.org/ticket/12879). I could do
whole new thread on why you can't ask newcomers to use Virtualbox
(currently, at least).

I ran into is a whole patch set to make CPython compile on MinGW
(https://bugs.python.org/issue3871#msg199695). But it is not denying
it's very experimental, and I know I would again spent useless hours
trying to get it work rather than joyfully improving Python, and
that's exactly what I do not want to happen.

Getting ready to contribute to CPython pure python modules from an
standard, average mr-everyone Windows PC for a beginner-to-medium
contributor only require few megabytes of internet and few minutes of his
time: getting a tarball of CPython sources (or cloning the github CPython
mirror)**, a basic text editor and msys-git. The step further, if doing
some -even basic- C code is required, implies downloading 9GB of Visual
Studio and countless hours for it to be ready to use.
I think downloading the whole Visual Studio suite is a huge stopper to
contribute further for an average medium-or-below-contributor.

I think (and I must not be the only one since CPython is to be moved
to github), that barriers to contribute to CPython should be set to
the lowest.
Of course my situation is a bit special but I think it represents
daily struggle of a *lot* of non-western programmer (at least for
limited internet)(even here in Australia, landline limited internet
connections are very common).
It's not a big deal if the MinGW result build is twenty time slower or
if some of the most advanced modules can't be build. But everyone
programmer should be able to easily make some C hacks and ge

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW

[Alexander Walters]

No.

Visual Studio is a solid compiler suit, mingw is a jenky mess, 
especially when you try and move to 64bit (where I don't think there is 
one true version of mingw).  I'm sorry that Visual Studio makes it very 
hard for you to contribute, but changing THE compiler of the 
distribution from the platform compiler, especially when we FINALLY got 
a stable abi with it, is going to be a non starter.


Compiling on MinGW for your own edification is fine, but that's not the 
build platform for windows python, nor should it be. Contributions are, 
and should continue to be, tested against Visual Studio.


On 2/26/2016 05:12, Mathieu Dupuy wrote:

Hi.
I am currently working on adding some functionality on a standard
library module (http://bugs.python.org/issue15873). The Python part
went fine, but now I have to do the C counterpart, and I have ran into
in several problems, which, stacked up, are a huge obstacle to easily
contribute further. Currently, despite I could work, I can't go
further
on my patch.

I am currently working in very limited network, CPU and time
ressources* which are quite uncommon in the western world, but are
much less in the rest of the world. I have a 2GB/month mobile data
plan and a 100KB/s speed. For the C part of my patch, I should
download Visual Studio. The Express Edition 2015 is roughly 9GB. I
can't afford that.

I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and
Fedora 23). Shortly, I couldn't get something working quickly and
simply (quickly = less than 2 hours, downloading time NOT included,
which is anyway way too already much). What went wrong and why it went
wrong could be a whole new thread and is outside of the scope of this
message.
Let me precise this : at my work I use many virtualbox instances
automatically fired and run in parallel to test new deployments and
run unittests. I like this tool,
but despite its simple look, it (most of the time) can not be used
simply by a profane. The concepts it requires you to understand are
not intuitive at first sight and there is *always* a thing that go
wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox
shipped for a moment a broken version of mount.vboxsf, preventing
sharing folder to mount. Despite it's fixed, the broken releases
spread everywhere and you may encounter them a lot in various Ubuntu
and Virtualbox version. I downloaded the last versions of both and I
am yet infected. https://www.virtualbox.org/ticket/12879). I could do
whole new thread on why you can't ask newcomers to use Virtualbox
(currently, at least).

I ran into is a whole patch set to make CPython compile on MinGW
(https://bugs.python.org/issue3871#msg199695). But it is not denying
it's very experimental, and I know I would again spent useless hours
trying to get it work rather than joyfully improving Python, and
that's exactly what I do not want to happen.

Getting ready to contribute to CPython pure python modules from an
standard, average mr-everyone Windows PC for a beginner-to-medium
contributor only require few megabytes of internet and few minutes of his
time: getting a tarball of CPython sources (or cloning the github CPython
mirror)**, a basic text editor and msys-git. The step further, if doing
some -even basic- C code is required, implies downloading 9GB of Visual
Studio and countless hours for it to be ready to use.
I think downloading the whole Visual Studio suite is a huge stopper to
contribute further for an average medium-or-below-contributor.

I think (and I must not be the only one since CPython is to be moved
to github), that barriers to contribute to CPython should be set to
the lowest.
Of course my situation is a bit special but I think it represents
daily struggle of a *lot* of non-western programmer (at least for
limited internet)(even here in Australia, landline limited internet
connections are very common).
It's not a big deal if the MinGW result build is twenty time slower or
if some of the most advanced modules can't be build. But everyone
programmer should be able to easily make some C hacks and get them to
work.

Hoping you'll be receptive to my pleas,
Cheers


* I am currently picking fruits in the regional Australia. I live in a van
and have internet through with smartphone through an EDGE connection. I can
plug the laptop in the farm but not in the van.
** No fresh programmer use mercurial unless he has a gun pointed on his
head.
___
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/tritium-list%40sdamon.com


___
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

[Python-Dev] Thank you.

[Alexander Walters]

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 of you...


Thank you.

Your work on Python has made a notable difference in how happy my life is.
___
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

Re: [Python-Dev] HackIllinois 2016 + Python

[Alexander Walters]

Hello.  You might want to post this in the psf-community list too. There 
are a lot of open source developers in the community they are not 
working directly on CPython (what this list is about).


On 2/8/2016 12:19, Kevin Hong wrote:

Hi all!

My name is Kevin and I am a staff member of HackIllinois, a 36-hour 
hackathon at the University of Illinois Urbana-Champaign where 
students from across the nation come to build some of the most 
innovative hardware and software projects. For highlights from last 
year’s event, check outgo.hackillinois.org/video 
.


From February 19-21st 2016, HackIllinois returns and we are 
introducing a new initiative called OpenSource@HackIllinois to promote 
Open Source development during the event. This program is designed to 
provide students with the opportunity to meet and collaborate with 
experienced developers, like you all, who serve as a guide and mentor 
into the open source world. Over the course of the event, you and your 
group of hackers will build features for an open source project of 
your choosing. Please see http://www.hackillinois.org/opensource for 
more details!


If you or any other open source developers you work with are 
interested in learning more about OpenSource@HackIllinois, feel free 
to email me at kevin.h...@hackillinois.org 
. I look forward to speaking with 
you soon!


Best Regards,

Kevin Hong




___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] Windows: Remove support of bytes filenames in the os module?

[Alexander Walters]

On 2/8/2016 12:02, Brett Cannon wrote:



If Unicode string don't work in Python 2 then what is Python 2/3 to do 
as a cross-platform solution if we completely remove bytes support in 
Python 3? Wouldn't that mean there is no common type between Python 2 
& 3 that one can use which will work with the os module except native 
strings (which are difficult to get right)?


The only solution then would be to do `if not PY3: arg = 
arg.encode(...);; os.SOMEFUNC(arg)`, pardon my psudocode.  Its annoying, 
but at least its not a language syntax change which means it isn't 
intractable, just an annoying roadblock.  If I had my druthers it would 
be put off until after 2.x is well and truly dead.


___
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

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Alexander Walters]

What incantation do you need to do to make that behavior apparent?

tritium@gesa:~$ python3.5 -W all
Python 3.5.1 (default, Dec 18 2015, 02:15:10)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
Jedi is not installed, falling back to readline
>>> assert True
>>>


On 2/8/2016 16:23, Victor Stinner wrote:



Le 8 févr. 2016 9:10 PM, "Alexander Walters" <tritium-l...@sdamon.com 
<mailto:tritium-l...@sdamon.com>> a écrit :

>
> I am not keen on a SyntaxWarning.  Either something is python 
syntax, or it is not.


Oh I forgot to mention that Python already emits SyntaxWarning, on 
"assert True" for example.


Victor



___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Alexander Walters]

On 2/8/2016 16:37, John Mark Vandenberg wrote:
fwiw, pyflakes doesnt detect this. I've created a bug for that 
https://bugs.launchpad.net/pyflakes/+bug/1543246 


Flake8 does, so it might be in the ... poorly named ... pep8 checker.

___
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

Re: [Python-Dev] Issue #26204: compiler now emits a SyntaxWarning on constant statement

[Alexander Walters]

I am not keen on a SyntaxWarning.  Either something is python syntax, or 
it is not.  This warning catches something linters have been catching 
for ages.  I really don't see the value in adding this, and can see it 
causing more confusion than it solves.  In the #python irc channel, we 
see quite a few newbie mistakes, but declaring a constant that isn't 
used is rarely if ever one of them.


On 2/8/2016 12:44, Victor Stinner wrote:

Hi,

I changed the Python compiler to ignore any kind "constant
expressions", whereas it only ignored strings and integers before:
http://bugs.python.org/issue26204

The compiler now also emits a SyntaxWarning on such case. IMHO the
warning can help to detect bugs for developers who just learnt Python.

The warning is *not* emited for strings, since triple quoted strings
are a common syntax for multiline comments.

The warning is *not* emited neither for ellispis (...) since "f():
..." is a legit syntax for abstract function.

Are you ok with the new warning?


New behaviour:

haypo@smithers$ ./python
Python 3.6.0a0 (default:759a975e1230, Feb  8 2016, 18:21:23)

def f():

...  False
...
:2: SyntaxWarning: ignore constant statement


import dis; dis.dis(f)

   2   0 LOAD_CONST   0 (None)
   3 RETURN_VALUE


Old behaviour:

haypo@smithers$ python3
Python 3.4.3 (default, Jun 29 2015, 12:16:01)

def f():

...  False
...

import dis; dis.dis(f)

   2   0 LOAD_CONST   1 (False)
   3 POP_TOP
   4 LOAD_CONST   0 (None)
   7 RETURN_VALUE



Before strings and numbers were already ignored. Example:

haypo@smithers$ python3
Python 3.4.3 (default, Jun 29 2015, 12:16:01)


def f():

...  123
...

import dis; dis.dis(f)

   2   0 LOAD_CONST   0 (None)
   3 RETURN_VALUE


Victor
___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] More optimisation ideas

[Alexander Walters]

On 2/5/2016 12:27, Emile van Sebille wrote:

On 2/1/2016 9:20 AM, Ethan Furman wrote:

On 02/01/2016 08:40 AM, R. David Murray wrote:



On the other hand, if the distros go the way Nick has (I think) been
advocating, and have a separate 'system python for system scripts' that
is independent of the one installed for user use, having the 
system-only
python be frozen and sourceless would actually make sense on a 
couple of

levels.


Agreed.


Except for that nasty licensing issue requiring source code.

Emile
Licensing requires, in the GPL at least, that the *modified* sources be 
made *available*, not that they be shipped with the product. Looking at 
the Python license, and what tools already do, there is zero need to 
ship the source to stay compliant.


___
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

Re: [Python-Dev] Python environment registration in the Windows Registry

[Alexander Walters]

I am well aware of this.  In the SO question I referenced, being the 
first google hit related this this... that is the answer *I* gave. It 
only works, in my experience, 60% of the time, and not with two biggie 
packages (pywin32, for which you have to go to third parties to get the 
wheel, which do not include all of pywin32, and wxpython) and perhaps more.


On 2/3/2016 14:32, Matthew Einhorn wrote:
On Wed, Feb 3, 2016 at 3:15 AM, Alexander Walters 
<tritium-l...@sdamon.com <mailto:tritium-l...@sdamon.com>> wrote:


...just when I thought I have solved the registry headaches I have
been dealing with...

I am not saying this proposal will make the registry situation
worse, but it may break my solution to the headaches Python's
registry use causes with some non-standard module installers (and
even the standard distutils exe installers, but that is being
mitigated). In the wild exist modules with their own EXE or MSI
installers that check the registry for 'the system python'.  No
matter how hard you hit them, they will only install to *that one
python*. 



If I remember correctly, you can use `wheel convert filename.exe` on 
those installers which create a wheel that you can install. I think 
that's what I used to do with pywin32 before pypiwin32 came along.


I just tested it and it still works on the pywin32 exe.



___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] Python environment registration in the Windows Registry

[Alexander Walters]

...just when I thought I have solved the registry headaches I have been 
dealing with...


I am not saying this proposal will make the registry situation worse, 
but it may break my solution to the headaches Python's registry use 
causes with some non-standard module installers (and even the standard 
distutils exe installers, but that is being mitigated).  In the wild 
exist modules with their own EXE or MSI installers that check the 
registry for 'the system python'.  No matter how hard you hit them, they 
will only install to *that one python*.  You can imagine the sadist that 
builds such an installer would not be receptive to the concept of 
wheels.  So in order to force those modules to install to the python YOU 
want, dammit, you have to edit the registry.  I have (contributed to) a 
script that just sets whatever python it was last run with to the one 
true system python.  Works with virtualenvs too.This is not a terribly 
obscure script either, by the way.  It is in the first reply to the 
google search for "how to install exes in a virtualenv".


So here I am in a situation where some pythons use another registry 
entry.  I have no idea if this makes my life as a user harder. What does 
this kind of meddling do against tools trying to autodetect python, and 
finding an ever changing value?  Are we trying to guarantee that the 
keys used by the python.org installers or only ever actually used by 
standard CPython?


I know for PTVS manually adding a python environment to visual studio is 
trivial - you fill in three locations, and its done.  Just today I added 
a python environment to my system that was not autodetected.  It took 
under a minute and almost no effort to add it... so for that tool this 
adds very little benefit.  I do not know about other tools.


On a very personal note (like the rest of this wasn't my personal issues 
with possibly making my life slightly more difficult), I would much 
rather see python stop touching the registry all together - but I have 
no strong argument for that.


On 2/3/2016 00:15, Steve Dower wrote:
I was throwing around some ideas with colleagues about how we detect 
Python installations on Windows from within Visual Studio, and it came 
up that there are many Python distros that install into different 
locations but write the same registry entries. (I knew about this, of 
course, but this time I decided to do something.)


Apart from not being detected properly by all IDEs/tools/installers, 
non-standard distros that register themselves in the official keys may 
also mess with the default sys.path values. For example, at one point 
(possibly still true) if you installed both Canopy and Anaconda, you 
would break the first one because they tried to load the other's stdlib.


Other implementations have different structures or do not register 
themselves at all, which also makes it more complicated for tools to 
discover them.


So here is a rough proposal to standardise the registry keys that can 
be set on Windows in a way that (a) lets other installers besides the 
official ones have equal footing, (b) provides consistent search and 
resolution semantics for tools, and (c) includes slightly more rich 
metadata (such as display names and URLs). Presented in PEP-like form 
here, but if feedback suggests just putting it in the docs I'm okay 
with that too. It is fully backwards compatible with official releases 
of Python (at least back to 2.5, possibly further) and does not 
require modifications to Python or the official installer - it is 
purely codifying a superset of what we already do.


Any and all feedback welcomed, especially from the owners of other 
distros, Python implementations or tools on the list.


Cheers,
Steve

-

PEP: ???
Title: Python environment registration in the Windows Registry
Version: $Revision$
Last-Modified: $Date$
Author: Steve Dower 
Status: Draft
Type: ???
Content-Type: text/x-rst
Created: 02-Feb-2016


Abstract


When installed on Windows, the official Python installer creates a 
registry key for discovery and detection by other applications. 
Unofficial installers, such as those used by distributions, typically 
create identical keys for the same purpose. However, these may 
conflict with the official installer or other distributions.


This PEP defines a schema for the Python registry key to allow 
unofficial installers to separately register their installation, and 
to allow applications to detect and correctly display all Python 
environments on a user's machine. No implementation changes to Python 
are proposed with this PEP.


The schema matches the registry values that have been used by the 
official installer since at least Python 2.5, and the resolution 
behaviour matches the behaviour of the official Python releases.


Specification
=

We consider there to be a single collection of Python environments on 
a machine, where the collection may be different for each 

Re: [Python-Dev] Python environment registration in the Windows Registry

[Alexander Walters]

On 2/3/2016 11:17, Steve Dower wrote:

I know for PTVS manually adding a python environment to visual studio is
trivial - you fill in three locations, and its done.  Just today I added
a python environment to my system that was not autodetected.  It took
under a minute and almost no effort to add it... so for that tool this
adds very little benefit.  I do not know about other tools.


I'm also a PTVS maintainer, so I know how much magic is going on 
behind those three locations :) But I don't think people should need 
to do that by hand at all.


For example, the path to an Anaconda installation is buried deep 
inside AppData (as is Python 3.5+ now), and varies based on your 
username. Canopy does the same, and once you've found it there are (or 
were?) at least three copies of python.exe to choose from (we worked 
with Enthought to make this Just Work for PTVS users).
Uh its C:\Anaconda[2]\ for anyone running the installer with the 
privileges to edit the registry... (It wont ask to elevate unless you 
install for all users, and that's where all users will install).  So on 
that point alone, this saves nothing substantive really.  (I will go off 
on python35 installing in insane locations some other time.)

___
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

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Alexander Walters]

On 1/18/2016 23:27, Greg Ewing wrote:

Brett Cannon wrote:

For me, I don't see how::

  if (x != 10)
return NULL;
  do_some_more();

is any clearer or more readable than::

  if (x != 10) {
return NULL;
  }
  do_some_more();


Maybe not for that piece of code on its own, but the version
with braces takes up one more line. Put a few of those together,
and you can't fit as much code on the screen. If it makes the
difference between being able to see e.g. the whole of a loop
at once vs. having to scroll up and down, it could make the
code as a whole harder to read.

When someone trying to make this argument in #python for Python code... 
the response is newlines are free.  Almost this entire thread has me 
confused - the arguments against are kind of hypocritical; You are 
developing a language with a built in design ethic, and ignoring those 
ethics while building the implementation itself.


Newlines are free, use them

Explicit > Implicit - Explicitly scope everything.

I am not a core developer, but I just kind of feel its hypocritical to 
oppose always using brackets for the development of *python*

___
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

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Alexander Walters]

On 1/19/2016 02:21, Larry Hastings wrote:


On 01/18/2016 08:40 PM, Alexander Walters wrote:
I am not a core developer, but I just kind of feel its hypocritical 
to oppose always using brackets for the development of *python*


CPython isn't written in Python, it's written in C.  So we use C 
idioms, which naturally are different from Python idioms.




Yes, and always using brackets is an accepted C idiom (one of two, the 
other being only use brackets when you must).  Always using them is  
more in line with the spirit of python.



//arry/


___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Alexander Walters]

On 1/19/2016 00:09, Greg Ewing wrote:

Alexander Walters wrote:
When someone trying to make this argument in #python for Python 
code... the response is newlines are free.


Well, I disagree. I very rarely put blank lines in a function
in any language, because it makes it hard to scan the code
visually and pick out the beginnings of functions. So while
they may help readability locally, they hurt it globally.

I find the opposite to be true when I work in C


If I find myself needing to put blank lines in a function in
order to make it readable, I take it as a sign that the
function ought to be split up into smaller functions.

 Well, maybe I should change my position based on this.  Any excuse 
to break code out into more functions... is usually the right idea.

___
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

Re: [Python-Dev] Update PEP 7 to require curly braces in C

[Alexander Walters]

On 1/19/2016 01:04, Glenn Linderman wrote:

On 1/18/2016 9:16 PM, Greg Ewing wrote:

Alexander Walters wrote:
I am not a core developer, but I just kind of feel its hypocritical 
to oppose always using brackets for the development of *python*


If we were being *really* pythonic, we would write all
the C code without any braces at all, and feed it through
a filter that adds them based on indentation. End of
argument. :-)



No argument, an extension:  If we were being *really* pythonic, we 
would re-implement CPython in Python, with a Python-to-C option 
(Cython?), and then we wouldn't need to worry about using braces for 
block delimiters.

So what I can take away from this is pypy is the pythonic python.

___
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

Re: [Python-Dev] Building with VS2015

[Alexander Walters]

This is a mailing list for the development of python itself, not support 
for building it.  That said...


3.4 uses visual studio 2010, for starters.  3.5 uses 2015.

It also looks like you have a lot of missing dependencies.

On 1/12/2016 21:55, Eddy Quicksall wrote:


I downloaded https://www.python.org/ftp/python/3.4.4/Python-3.4.4.tgz.

After reading Python-3.4.4\PCbuild\readme.txt I opened pcbuild.sln and 
selected release/winn32 then tried a build all (F7). But that give 
lots of errors and missing .h files (mostly sqlite3.h).


Does anyone know what I may be doing wrong or have misunderstood?

Here is the output:

1>-- Build started: Project: make_versioninfo, Configuration: 
Release Win32 --


2>-- Build started: Project: kill_python, Configuration: Release 
Win32 --


3>-- Skipped Build: Project: bdist_wininst, Configuration: Release 
Win32 --


3>Project not selected to build for this solution configuration

4>-- Build started: Project: python3dll, Configuration: Release 
Win32 --


5>-- Build started: Project: xxlimited, Configuration: Release 
Win32 --


1> make_versioninfo.c

5> xxlimited.c

2> kill_python.c

4>

4> Microsoft (R) Program Maintenance Utility Version 14.00.23026.0

4> Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4>lib /def:python34stub.def 
/out:W:\Python-3.4.4\PCbuild\python34stub.lib /MACHINE:x86


5>LINK : fatal error LNK1104: cannot open file 'python3.lib'

4> Microsoft (R) Library Manager Version 14.00.23026.0

4> Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4> Creating library W:\Python-3.4.4\PCbuild\python34stub.lib and 
object W:\Python-3.4.4\PCbuild\python34stub.exp


4>cl /LD /FeW:\Python-3.4.4\PCbuild\python3.dll python3dll.c 
python3.def W:\Python-3.4.4\PCbuild\python34stub.lib


4> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86

4> Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4> python3dll.c

1> make_versioninfo.vcxproj -> 
W:\Python-3.4.4\PCbuild\make_versioninfo.exe


2> Generating code

2> All 5 functions were compiled because no usable IPDB/IOBJ from 
previous compilation was found.


2> Finished generating code

4> Microsoft (R) Incremental Linker Version 14.00.23026.0

4> Copyright (C) Microsoft Corporation.  All rights reserved.

4>

4> /dll

4> /implib:W:\Python-3.4.4\PCbuild\python3.lib

4> /out:W:\Python-3.4.4\PCbuild\python3.dll

4> /def:python3.def

4> python3dll.obj

4> W:\Python-3.4.4\PCbuild\python34stub.lib

4> Creating library W:\Python-3.4.4\PCbuild\python3.lib and object 
W:\Python-3.4.4\PCbuild\python3.exp


6>-- Build started: Project: pylauncher, Configuration: Release 
Win32 --


7>-- Build started: Project: pywlauncher, Configuration: Release 
Win32 --


7> launcher.c

6> launcher.c

2> kill_python.vcxproj -> W:\Python-3.4.4\PCbuild\kill_python.exe

8>-- Build started: Project: pythoncore, Configuration: Release 
Win32 --


9>-- Build started: Project: sqlite3, Configuration: Release Win32 
--


9> sqlite3.c

9>c1 : fatal error C1083: Cannot open source file: 
'..\externals\sqlite-3.8.11.0\sqlite3.c': No such file or directory


7> Generating code

7> All 41 functions were compiled because no usable IPDB/IOBJ from 
previous compilation was found.


7> Finished generating code

8> _bisectmodule.c

8> _codecsmodule.c

6> Generating code

6> All 41 functions were compiled because no usable IPDB/IOBJ from 
previous compilation was found.


6> Finished generating code

8> _collectionsmodule.c

7> pywlauncher.vcxproj -> W:\Python-3.4.4\PCbuild\pyw.exe

8> _csv.c

6> pylauncher.vcxproj -> W:\Python-3.4.4\PCbuild\py.exe

8> _functoolsmodule.c

8> _heapqmodule.c

8> _json.c

8> _localemodule.c

8> _lsprof.c

8> _math.c

8> _pickle.c

8> _randommodule.c

8> _sre.c

8> _stat.c

8> _struct.c

8> _weakref.c

8> arraymodule.c

8> atexitmodule.c

8> audioop.c

8> binascii.c

8> Generating Code...

8> Compiling...

8> cmathmodule.c

8> _datetimemodule.c

8>..\Modules\_datetimemodule.c(4843): error C2065: 'daylight': 
undeclared identifier


8>..\Modules\_datetimemodule.c(4844): error C2065: 'tzname': 
undeclared identifier


8>..\Modules\_datetimemodule.c(4844): error C2109: subscript requires 
array or pointer type


8>..\Modules\_datetimemodule.c(4846): error C2065: 'tzname': 
undeclared identifier


8>..\Modules\_datetimemodule.c(4846): error C2109: subscript requires 
array or pointer type


8> errnomodule.c

8> faulthandler.c

8> gcmodule.c

8> hashtable.c

8> itertoolsmodule.c

8> main.c

8>..\Modules\main.c(521): error C2198: 'wcstok': too few arguments for 
call


8>..\Modules\main.c(523): error C2198: 'wcstok': too few arguments for 
call


8> mathmodule.c

8> md5module.c

8> mmapmodule.c

8> _opcode.c

8> _operator.c

8> parsermodule.c

8> posixmodule.c

8> rotatingtree.c

8> sha1module.c

8> sha256module.c

8> sha512module.c

8> signalmodule.c

8> Generating Code...

8> Compiling...

8> 

[Python-Dev] collections.Counter __add__ implementation quirk

[Alexander Walters]

collections.Counter.__add__ as a bit of a quirk.

Counters allow for negative numbers.  You can subtract from a counter 
into the negative no problem.  However, if you have a counter with a 
negative value and add it to another counter, and if that value, after 
addition, would still be negative... that value is not included in the 
resulting Counter object.  This is kind of weird, to the point of 
thinking I had a bug in other code for several hours until I went and 
checked how Counters are implemented.


Is there any particular reason counters drop negative values when you 
add them together?  I definitely expected them to act like ints do when 
you add negatives, and had to subclass it to get what I think is the 
obvious behavior.

___
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

Re: [Python-Dev] Should PEP 498 specify if rf'...' is valid?

[Alexander Walters]

Have you ever used a command line application that --accepted --Boolean 
--flags?   Have you ever found one that required the flags to be in 
order?  You remember how much you hated that application for being so 
arbitrary about the input?


That is exactly how I feel about the order mattering for string prefixes 
in 2.7.  3.x got rid of that, and that is one of the few undeniably good 
choices made in python 3.


for the love of all that is holy, don't un-fix that.



On 10/27/2015 14:39, Sven R. Kunze wrote:

On 26.10.2015 20:54, Ethan Furman wrote:
You misunderstand -- the order of string prefixes does *not* matter, 
so forcing us to use one is silly.


I don't think so.

It's better to have less possibilities in the beginning. So later on, 
we can easily relax the restrictions without breaking compatibility.


Best,
Sven
___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

This may seam like a simplistic solution to i18n, but why not just add a 
method to string objects (assuming we implement f-strings) that just 
returns the original, unprocessed string.  If the string was not an 
f-string, it just returns self.  The gettext module can be modified, I 
think trivially, to use the method instead of the string directly.


Is this a horrible idea?

- Alex W.
___
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

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

On 8/11/2015 11:16, Eric V. Smith wrote:

On 08/11/2015 11:09 AM, Alexander Walters wrote:

This may seam like a simplistic solution to i18n, but why not just add a
method to string objects (assuming we implement f-strings) that just
returns the original, unprocessed string.  If the string was not an
f-string, it just returns self.  The gettext module can be modified, I
think trivially, to use the method instead of the string directly.

You need the original string, in order to figure out what it translates
to. You need the values to replace into that string, evaluated at
runtime, in the context of where the string appears. And you need to
know where in the original (or translated) string to put them.

The problem is that there's no way to evaluate the values and, before
they're substituted in to the string, use a different template string
with obvious substitution points. This is what PEP 501 is trying to do.

Eric.
I don't understand some of that.  We already trust translators with 
_('foo {bar}').format(bar=bar) to not mess up the {bar} in the string, 
so the that wont change.  Is the issue handing the string back to python 
to be formatted?  Could gettext not make the same AST as an f-string 
would, and hand that back to python?  If you add a method to strings 
that returns the un-f-string-processed version of the string, doesn't 
that make all these problems solvable without pep-501?

___
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

Re: [Python-Dev] PEP needed for http://bugs.python.org/issue9232 ?

[Alexander Walters]

As a user who has banged my head against this more than once, its not a 
feature, its a bug, it does not need a pep (Guido said as much), just 
fix it.


On 8/11/2015 11:31, Chris Barker - NOAA Federal wrote:

there's been enough debate that I suspect we need a

PEP.


I think we might just need another round of discussion here.

Please no :-)

Looking back at the previous discussion, it looked like it's all been
said, and there was almost unanimous approval (with some key mild
disapproval) for the idea, so what we need now is a pronouncement.

If it's unclear whether consensus was close, then folks that are
strongly against should speak up now. If there is a flurry of those,
then a PEP is in order. But another big long unstructured discussion
won't be useful.

-Chris





I'm +1 myself.  Granted there haven't been many times I've wanted it
(functions with enough arguments to want to make it easy to add and
remove elements are a bit of a code smell), but I have wanted it (and
even used the form that is accepted) several times.  On the other hand,
the number of times when the detection of a trailing comma has revealed
a missing argument to me (Raymond's objection) has been...well, I'm
pretty sure it is zero.  Especially since it only happens *sometimes*.
Since backward compatibility says we shouldn't disallow it where it is
currently allowed, the only logical thing to do, IMO, is consistently
allow it.

(If you wanted to fix an 'oops' trailing comma syntax issue, I'd vote for
disallowing trailing commas outside of ().  The number of times I've
ended up with an unintentional tuple after converting a dictionary to a
series of assignments outnumbers both of the above :)  Note, I am *not*
suggesting doing this!)

--David
___
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/chris.barker%40noaa.gov

___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

On 8/11/2015 11:28, Wes Turner wrote:



On Aug 11, 2015 10:19 AM, Wes Turner wes.tur...@gmail.com 
mailto:wes.tur...@gmail.com wrote:


- [ ] review all string interpolation (for injection)
  * [ ] review every '%'
  * [ ] review every .format()
  * [ ] review every f-string (AND LOCALS AND GLOBALS)
  * every os.system, os.exec*, subprocess.Popen
  * every unclosed tag
  * every unescaped control character

This would create work we don't need.

Solution: __str_shell_ escapes, adds slashes, and quotes. __str__SQL__ 
refs a global list of reserved words.



I don't understand why % and .format got interjected into this.

If you are mentioning them as 'get the unprocessed version of any string 
formatting', that is a bad idea, and not needed, since you already have 
an unprocessed string object.  Assuming the method were named 
hypothetical:


 'foo bar'.hypothetical()  # returns 'foo bar'
 '{0} bar'.format('foo').hypothetical()  # returns 'foo bar'
 ('%s bar' % ('foo',)).hypothetical() # returns 'foo bar'
 f'{foo} bar'.hypothetical() # returns '{foo} bar', prime for 
translation.


could gettext not be modified to create the same AST as f'{foo} bar' 
when it is translated to '{foo} le bar.' and inject it back into the 
runtime?
___
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

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

On 8/10/2015 01:29, Sven R. Kunze wrote:
The best solution would be without prefix and '{var}' only syntax. 
Not sure if that is possible at all; I cannot remember using '{...}' 
anywhere else than for formatting.


My JSON string literal 'test fixtures' weep at that idea.

___
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

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

Please do not change the meaning of the vestigial U''.  It was re-added 
to the language to fix a problem, rebinding it to another meaning 
introduces new problems.  We have plenty of other letters in the 
alphabet to use.


On 8/8/2015 05:34, Nick Coghlan wrote:

On 8 August 2015 at 11:39, Eric V. Smith e...@trueblade.com wrote:

Following a long discussion on python-ideas, I've posted my draft of
PEP-498. It describes the f-string approach that was the subject of
the Briefer string format thread. I'm open to a better title than
Literal String Formatting.

Thanks you for your work on this - it's a very cool concept!

I've also now written and posted an initial draft of PEP 500, based
directly on PEP 498, which formalises the __interpolate__ builtin
idea I raised in those threads, along with a PEP 292 based syntax
proposal that aims to be as simple as possible for the simple case of
interpolating existing variables, while still allowing the use of
braces to permit embedding of arbitrary expressions and formatting
directives.

it turned out this approach provided an unanticipated benefit that I
only discovered while writing the PEP: by defining a separate
__interpolateb__ builtin, it's straightforward to define binary
interpolation in terms of bytes.__mod__, while still defining text
interpolation in terms of str.format.

The previously-redundant-in-python-3 'u' prefix also finds new life as
a way of always requesting the default string interpolation, even if
__interpolate__ has been overridden in the current namespace to mean
something else (like il8n string translation).

Cheers,
Nick.



___
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

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

... Its adding meaning to something that was intentionally meaningless.  
Not using u'' has the obvious, immediate benefit of not caring what u'' 
means in python 3, so one can continue to write polyglot code.  Since 
you are adding new semantics to python 3, use a different letter so that 
it just breaks in python 2, instead of having different meanings between 
versions.


Python 2 is still the dominant python.

On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters tritium-l...@sdamon.com wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

Wait a second, the pep itself does not use the vestigial u''... it uses 
i''.  where did u'' come from?


On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters tritium-l...@sdamon.com wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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

Re: [Python-Dev] PEP-498: Literal String Formatting

[Alexander Walters]

As written in the pep, where i'' means 'I have the __interpolate__' 
method, and iu'' means 'i have the __interpolateu__' method (or that 
translators should call these methods), is fine, as the meaning of u ('I 
am unicode, yeah you already knew that') isn't changed.


On 8/8/2015 11:07, Nick Coghlan wrote:

On 9 August 2015 at 00:05, Alexander Walters tritium-l...@sdamon.com wrote:

Please do not change the meaning of the vestigial U''.  It was re-added to
the language to fix a problem, rebinding it to another meaning introduces
new problems.  We have plenty of other letters in the alphabet to use.

It's actually being used in the same sense we already use it - I'm
just adding a new compile time use case where the distinction matters
again, which we haven't previously had in Python 3. (The usage in this
PEP is fairly closely analogous to WSGI's distinction between native
strings, text strings and binary strings, which matters for hybrid
Python 2/3 code, but not for pure Python 3 code)

It would certainly be *possible* to use a different character for that
aspect of the PEP, but it would be additional work without any obvious
gain.

Cheers,
Nick.

P.S. I hop on the plane for the US in a few hours, so I'll be aiming
to be bad at responding to emails until the 17th or so. We'll see how
well I stick to that plan :)



___
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

Re: [Python-Dev] Computed Goto dispatch for Python 2

[Alexander Walters]

A better course of action would be to deprecate the non-portable 
version.  Other than setting the PATH envvar, why do we need to continue 
even touching the system on install?  It is highly annoying for those of 
us that maintain several installs of python on a single windows system, 
and it really should stop.


The only use I can think of for ever touching the registry in the first 
place is to tell distutils installers where python is.  I can tell you 
right now, that design choice is a bug.  There are some mighty hacks you 
have to go through to correct that behavior when you happen to be using 
a virtualenv.


(We are calling it 'embedable', but the rest of the world would call it 
'portable', as in, runable from a usb stick)


On 5/31/2015 06:47, Paul Moore wrote:

On 31 May 2015 at 11:41, Paul Moore p.f.mo...@gmail.com wrote:

On 31 May 2015 at 10:14, Xavier Combelle xavier.combe...@gmail.com wrote:

+1. The new embeddable Python distribution for Windows is a great step
forward for this. It's not single-file, but it's easy to produce a
single-directory self-contained application with it. I don't know if
there's anything equivalent for Linux/OSX - maybe it's something we
should look at for them as well (although the whole static binaries
concept seems to be fairly frowned on in the Unix world, from what
I've seen).


Just curious What is the new embeddable Python distribution for Windows ?

Python 3.5 ships a zipfile which contains a self-contained Python
installation, intended for embedding. The idea is that you unzip it
into your application directory, and use it from within your
application (either via the embedding API, or using the included
python.exe/pythonw.exe). It doesn't use the registry, or any global
resources, so it's independent of any installed python that might be
present.

By the way, IMO the new embeddable distribution is a pretty big deal
on Windows. To make sure that it doesn't end up unnoticed, can I
suggest we include a prominent What's New entry for it, and a
section in Python Setup and Usage under Using Python on Windows
for it?

I'd hate to find that 3 or 4 versions from now, we're still trying to
remind people that they can use the embeddable distribution, in the
same way that executable zipfiles ended up an almost unknown feature
for ages.

Paul
___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Alexander Walters]

Who said anything about funding?  this is a thread about the patch Intel 
offered (and had committed).


And that's the point.  This is the thread about THAT patch.  Why are we 
hijacking this topic for an environmental debate?  If it is a legitimate 
topic (which it might be), discuss it in its own right. Otherwise it 
sounds like guilt-tripping and greenwashing.


This patch will do little to nothing statistically significant for the 
environment.  Bringing that up is ideology and politics.


On 5/30/2015 04:55, Nick Coghlan wrote:

On 30 May 2015 10:46, Alexander Walters tritium-l...@sdamon.com wrote:

Python is a giant cache-miss generator.  A little performance boost on the 
opt-code dispatch isn't going to change that much.  If we really do care about 
improving python to do less environmental damage, then that is a discussion we 
should be having on it's own merits.  It was really out of place, even in this 
tangenty thread.

I think the way core development gets funded is entirely on topic for
the main core development mailing list, we just historically haven't
discussed it openly, even though some of us have been advocating for
various improvements to arrangements behind the scenes. I personally
consider becoming more transparent about how we go about that process
to be a good thing.

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 Python 2, rather than
restricting their contributions to Python 3.

The key is that the reason for not backporting performance
enhancements *differs* from the reasons for not backporting new
features. Rolling out new features has a broad ripple effect on the
Python ecosystem as books, training material, etc, all need to be
updated, and projects need to decide how to communicate their version
dependencies appropriately if they decide to depend on one of the
backported features. We pushed that kind of Python 2 change out to
PyPI years ago, and aside from truly exceptional cases like the
network security enhancements in PEPs 466  476 and the decision to
bundle pip to make it easier to access PyPI, it isn't open for
reconsideration as a general principle.

Performance improvements, by contrast, historically haven't been
backported solely due to the stability and maintainability
implications for CPython itself - they don't have a change management
ripple effect the way new language and standard library level features
do. That lack of negative ripple effects that cause work for other
people is why the proposal to contribute paid development time makes
such a big difference to the acceptability of Python 2.7 performance
patches, as it should be a pure gain for current Python 2.7 users, and
the paid development contributions should address the maintainability
concerns on the core development side (particularly since Intel are
*paying* for their coaching in core contribution practices and
politics, rather than expecting to receive that coaching from
community volunteers for free).

Backporting the computed goto patch is an easy place for them to
start, since the change is already well tested in the Python 3 branch,
but we don't expect this to be the end of the line for CPython 2 (or
3) performance enhancements.

However, we also shouldn't downplay the significance of this as a
notable policy change for the Python 2.7 maintenance branch, which
means it is useful to offer folks as many reasons as we can to help
them come to terms with the idea that Python 2 performance still
matters, and that it is only the limitations on our development and
support capacity that prevented us from further improving it
previously.

The commercially pragmatic reason is because Python 2 is where the
largest current installed base is today, so applying some of the
increased development capacity arising from sponsored contributions to
Python 2.7 performance improvements is a good way to demonstrate to
Python 2 developers that we still care about them *as Python 2 users*,
rather than only being interested in them as potential future Python 3
users. This is the rationale that's likely to get our paid
contributors (both current and future) on board with the idea, but it
isn't necessarily going to be compelling to folks that are here as
volunteers.

The first What's in it for the volunteers? reason is the one I
raised: giving the nod to an increased corporate developer presence in
Python 2 maintenance should eventually let volunteers stop worrying
about even Python 2.7 bug fix changes with a clear conscience,
confident that as volunteer efforts drop away redistributors and other
folks with an institutional interest will pick up the slack with paid
development time. Do the fun stuff for free, figure out a way to get
paid for the boring-but-necessary stuff (or leave those tasks to
someone else that's getting paid

Re: [Python-Dev] 2.7 is here until 2020, please don't call it a waste.

[Alexander Walters]

Python is a giant cache-miss generator.  A little performance boost on 
the opt-code dispatch isn't going to change that much.  If we really do 
care about improving python to do less environmental damage, then that 
is a discussion we should be having on it's own merits.  It was really 
out of place, even in this tangenty thread.


On 5/29/2015 20:34, Nick Coghlan wrote:



On 30 May 2015 09:57, Antoine Pitrou solip...@pitrou.net 
mailto:solip...@pitrou.net wrote:


 On Sat, 30 May 2015 01:49:10 +0200
 Christian Heimes christ...@python.org 
mailto:christ...@python.org wrote:

  For performance patches we have to consider our responsibility for the
  environment. Every improvement means more speed and less power
  consumption. Python runs of hundreds of thousands of machines in the
  cloud. Python 2.7 will be used for at least half a decade, probably
  longer. Servers can be replaced with faster machines later and less
  fossil fuel must be burned to produce power.

 Please keep your ideology out of this.

I'm a qualified engineer (in computer systems engineering), so caring 
about environmental sustainability is part of my professional ethical 
standards, not just a matter of personal preference: 
http://www.wfeo.org/ethics/


Given the power draw of large data centres, the environmental impact 
of performance improvements to the Python 2 series is a point well 
worth considering.


Cheers,
Nick.


 Regards

 Antoine.


 ___
 Python-Dev mailing list
 Python-Dev@python.org mailto:Python-Dev@python.org
 https://mail.python.org/mailman/listinfo/python-dev
 Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com




___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

[Alexander Walters]

Out of curiosity, how much of a breaking change would making unary 
operators stack arbitrarily be?



On 4/30/2015 23:57, Nathaniel Smith wrote:


On Apr 30, 2015 8:40 PM, Guido van Rossum gu...@python.org 
mailto:gu...@python.org wrote:


 On Thu, Apr 30, 2015 at 8:30 PM, Nathaniel Smith n...@pobox.com 
mailto:n...@pobox.com wrote:


 The actual effect of making await a different precedence is to 
resolve the ambiguity in


   await x ** 2

 If await acted like -, then this would be
   await (x ** 2)
 But with the proposed grammar, it's instead
   (await x) ** 2
 Which is probably correct, and produces the IMHO rather nice 
invariant that await binds more tightly than arithmetic in general 
(instead of having to say that it binds more tightly than arithmetic 
*except* in this one corner case...)


 Correct.

 AFAICT these and the ** case are the only expressions where there's 
any difference between Yury's proposed grammar and your proposal of 
treating await like unary minus. But then given the limitations of 
Python's parser plus the desire to disambiguate the expression above 
in the given way, it becomes an arguably regrettable, yet inevitable, 
consequence that


   await -fut
   await +fut
   await ~fut
 become parse errors.

  Why is that regrettable? Do you have a plan for overloading one of 
those on Futures? I personally consider it a feature that you can't do 
that. :-)


I didn't say it was regrettable, I said it was arguably regrettable. 
For proof, see the last week of python-dev ;-).


(I guess all else being equal it would be nice if unary operators 
could stack arbitrarily, since that really is the more natural parse 
rule IMO and also if things had worked that way then I would have 
spent this thread less confused. But this is a pure argument from 
elegance. In practice there's obviously no good reason to write await 
-fut or -not x, so meh, whatever.)


-n



___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] Unicode literals in Python 2.7

[Alexander Walters]

does this not work for you?

from __future__ import unicode_literals


On 4/28/2015 16:20, Adam Bartoš wrote:

Hello,

is it possible to somehow tell Python 2.7 to compile a code entered in 
the interactive session with the flag PyCF_SOURCE_IS_UTF8 set? I'm 
considering adding support for Python 2 in my package 
(https://github.com/Drekin/win-unicode-console) and I have run into 
the fact that when uα is entered in the interactive session, it 
results in u\xce\xb1 rather than u\u03b1. As this seems to be a 
highly specialized question, I'm asking it here.


Regards, Drekin


___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] Type hints -- a mediocre programmer's reaction

[Alexander Walters]

So.  This is how you try and get me to care about Python 3.  Can't speak 
for others, but this does the opposite for me.  This makes me ecstatic 
that Python 2 has a nearly-frozen api.

___
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

Re: [Python-Dev] Keyword-only parameters

[Alexander Walters]

Lacking anything anyone else says... the use case for keyword only 
arguments (where they actually make the code better rather than simply 
being different) is rather limited.



On 4/14/2015 13:40, Eric V. Smith wrote:

I'm working on adding a numeric_owner parameter to some tarfile methods
(http://bugs.python.org/issue23193),

In a review, Berker suggested making the parameter keyword-only. I agree
that you'd likely never want to pass just True, but that
numeric_owner=True would be a better usage.

But, I don't see a lot of keyword-only parameters being added to stdlib
code. Is there some position we've taken on this? Barring someone saying
stdlib APIs shouldn't contain keyword-only params, I'm inclined to
make numeric_owner keyword-only.

Is there anything stopping me from making it keyword-only?

Thanks.
Eric.
___
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/tritium-list%40sdamon.com


___
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

Re: [Python-Dev] version of freshly built 2.7 python

[Alexander Walters]

Are you building from mercurial or a source tarball?


On 4/2/2015 21:29, Ethan Furman wrote:

I just built the latest version of Python 2.7 on my development machine -- or 
so I thought.  When I invoke it, I get:

   Python 2.7.6+ (2.7:1beb3e0507fa, Apr  2 2015, 17:57:53)

Why am I not seeing 2.7.9?

--
~Ethan~
___
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/tritium-list%40sdamon.com


___
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