...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) =
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
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
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
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
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
ugh 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
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
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
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
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
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 do
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
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
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
<tritiu
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
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
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
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
led, 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.
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
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
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
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 head
...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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
50 matches
Mail list logo
