On 2021-11-30 09:01, Steven D'Aprano wrote:
Heh. We could update PEP 8 to ban type annotations, then watch as the
people who over-zealously apply PEP 8 to everything AND over-zealously
insist on adding type annotations to everything have their heads
explode.
Captain Kirk would be proud:
ht
This is the point where the pricey support contract comes in. Would give
options to those who need it and provide some revenue.
Otherwise, the "there's no such thing as a free lunch," factor takes precedence.
-Mike
___
Python-Dev mailing list --
How about moving Python 2 notes into a section at the bottom?
-Mike
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message
On 2021-05-11 16:12, Guido van Rossum wrote:
On Tue, May 11, 2021 at 4:07 PM Gregory P. Smith There's a difference between tracebacks dumped as plain text (utf-8) by
traceback.print_exc() appearing on stderr or directed into log files and
what can be displayed within a terminal. It
On 5/11/21 1:57 AM, Baptiste Carvello wrote:
Le 11/05/2021 à 09:35, Steven D'Aprano a écrit :
On Mon, May 10, 2021 at 09:44:05PM -0400, Terry Reedy wrote:
The vanilla interpreter could be updated to recognize when it is running
on a similated 35-year-old terminal that implements ansi-vt100 co
On 2021-03-10 13:45, David Mertz wrote:
In contrast, the "master" used in version control directly borrows from
so-called "master/slave network architecture."
It was shown upthread that this isn't the case. Do you have more accurate
documentation to refute the claim?
- https://twitter.co
On 2021-02-24 21:08, Peter Wang wrote:
With binary extension modules, version conflicts lead to (at best) runtime
segfault and (at worst) subtle *data* bugs that return incorrect results. There
are also deeper concerns around security and reproducibility.
If your app has requirements, by al
On 2021-02-24 02:52, Stéfane Fermigier wrote:
I have currently 57 apps installed via pipx on my laptop, and the 57
environments take almost 1 GB already.
I never understood the fear around version conflicts. Perhaps it has to do with
the decline of sys-admin skills over the years? So, the
On Thu, 2021-02-11 at 23:24 -0500, Terry Reedy wrote:
> ... Releases are not just a push of a button.
On 2021-02-19 15:05, Stestagg wrote:
> > The thing that stood out from this conversation, for me, is: Releases
> > are too hard, and there’s a risk of not having enough volunteers as a
On 2020-11-09 10:44, Simon Cross wrote:
That's quite subjective. Personally I prefer a more complete tutorial
which explains many details so that I don't immediately run into
fundamentals I don't understand when I start using what I've learned.
K&R was very popular, so I don't think I'm alone i
On 2020-04-16 04:33, Rob Cliffe via Python-Dev wrote:
Here's another revolutionary thought: add a new operator and associated dunder
method (to object?)
whose meaning is *undefined*. Its default implementation would do *nothing*
useful (raise an error? return None?).
E.g. suppose the operato
Unless I've read something wrong, it looks like the final Python 2 release
(2.7.18) should approximate the math constant e:
>>> import math
>>> math.e
2.718281828459045
Aka:
Python as 𝑣 → 𝑒
Python ≈ 𝑒
Would be fun to note that in the announcement/docs somehow.
-Mike
___
On 2020-03-21 20:38, Guido van Rossum wrote:
It's not great, and I actually think that "stripprefix" and "stripsuffix" are
reasonable. (I found that in Go, everything we call "strip" is called "Trim",
and there are "TrimPrefix" and "TrimSuffix" functions that correspond to the PEP
616 function
On 2020-02-04 14:40, Paul Moore wrote:
>> The answer to that concern is to not break compatibility in the first place,
>> and/or revert it when the mistake is discovered. It happens.
>
> That sounds to me like an argument for stagnation. We already take
> backwards compatibility very seriously.
On 2020-02-04 12:10, Brett Cannon wrote:
Please be careful making that claim. Over my 16 years of helping manage this
project I can tell you that claim is not universally true no matter how small
and simple you think something is.
The answer to that concern is to not break compatibility in
On 2020-02-03 17:00, Brett Cannon wrote:
Until you're being asked to maintain all of that for a decade. We paid a major
price keeping Python 2 alive for over a decade. Now I'm not saying it wasn't
the right thing to do considering what we changed, but for the stuff we are
talking about removi
On 2020-02-04 04:16, Rhodri James wrote:
I think that just enables laziness. "We don't need to worry about the
deprecations, nothing is going to happen for years yet," is more or less what
happened with the Python2 to Python3 shift. People naturally enjoy adding shiny
new features to their p
On 2020-02-03 01:50, Petr Viktorin wrote:
When the changes are rolled out gradually across minor releases, those that
cause unforeseen trouble in real-world code can be identified in the
alphas/betas, and rethought/reverted if necessary.
To be clear, my suggestion was to maintain gradual de
On 2020-01-23 07:20, Victor Stinner wrote:
> Python 3.9 introduces many small incompatible changes which broke tons
There's a well-known and established way of signaling breaking changes in
software platforms—it is to increment the major version number.
Rather than debating the merits of bre
On 2019-12-03 18:41, Ned Batchelder wrote:
> Has anyone yet given a reason to remove it? It will change working code into
> broken code. Why do that?
I've heard a few complaints over the years about the number of combinations of
string prefixes being a problem and a high barrier to new ones bei
On 2018-07-07 06:09, Giampaolo Rodola' wrote:
I initially found myself disliking the idea as a whole but
https://github.com/python/cpython/pull/8122 made me (and others) reconsider it
quite a bit (see: https://twitter.com/grodola/status/1015251302350245888).
PR-8122 clearly shows an improvem
On 2018-07-04 00:25, Nathaniel Smith wrote:
The only cases that seem potentially valuable to me are the ones that
are literally the form 'if := ` and 'while :=
'. (I suspect these are the only cases that I would allow in
code that I maintain.) The PEP does briefly discuss the alternative
prop
On 2018-07-05 10:52, Ivan Pozdeev via Python-Dev wrote:
>
Perhaps, however I'm not advocating using "EXPR as NAME" with "with" as it
wouldn't be useful enough, only limited to if/while/comp.
-Mike
___
Python-Dev mailing list
Python-Dev@python.org
On 2018-07-05 04:28, Ivan Pozdeev via Python-Dev wrote:
This is as intended.
I wanted to show my summary and Chris' refuttal, with links to both original
posts. Because my letter is much shorter than the originals while carrying the
same message. Also to show that I've made the same mistake,
On 2018-07-04 17:22, Chris Angelico wrote:
- the "if expr as name:" syntax is able to handle only the tiniest
proportion of cases, because many MANY situations require a condition
after that. You can't write this, for instance:
if f(x) as spam < 0:
print(spam)
The original use cases did
On 2018-07-04 23:20, Steven D'Aprano wrote:
It simply isn't true that modern languages are moving away from
assignment expressions. Some are. Some aren't. Even those that don't
support assignment expressions in general usually support special syntax
to allow it in a few contexts.
The older po
Recently on Python-Dev:
On 2018-07-03 15:24, Chris Barker wrote:
> On Tue, Jul 3, 2018 at 2:51 PM, Chris Angelico On Wed, Jul 4, 2018 at 7:37 AM, Serhiy Storchaka
>
> > I believe most Python users are not
> > professional programmers -- they are sysadmins, scientists, hobbyists
>
On 2018-06-22 19:46, Steven D'Aprano wrote:
- the inexplicable (to me) decision to say "for x of array" instead of
"for x in array";
Believe JavaScript has for…in, but as usual in the language it is broken and
they needed a few more tries to get it right. for…of is the latest version and
Sorry all, wasn't specific enough.
By "modern" I mean the last decade perhaps. New languages that have had a
chance to look at the older generations and choose their best ideas, while
leaving behind the rest.
Personally I thought of Swift (Ryan mentioned), Kotlin, Rust, and perhaps Go,
thou
On 2018-04-25 19:36, Ryan Gonzalez wrote:
By now we've searched over the current proposal in excruciating detail.
However, there were two good questions in this message which I haven't seen
addressed yet:
- How are other modern languages solving this issue?
- How does this new constru
On 2018-04-24 21:05, Nathaniel Smith wrote:
On Tue, Apr 24, 2018 at 8:56 PM, Tim Peters wrote:
It would actually be quite convenient, and far less error-prone, to
add a binding construct inside a complicated expression for purposes
of running under a debugger. The alternative is typing the
On 2018-04-24 02:21, Victor Stinner wrote:
> I have been asked to express myself on the PEP 572. I'm not sure that
Thanks. Well written and I've had the same thoughts myself.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/
On 2018-04-24 12:59, Chris Angelico wrote:
Aside from the restriction to binding only to a simple name, and the
fact that they're also an expression with the same value, how are they
not the same as plain assignment? Any discrepancies should be
considered bugs.
Slightly different in that they
On 2018-04-23 14:19, Barry Warsaw wrote:
Me too. Plus we *already* have precedence for spelling name bindings in
similar constructs, such as import statements, with statements, and exceptions.
It seems like a natural and Pythonic approach to extend that same spelling to
binding expressions
On 2018-04-23 15:36, Guido van Rossum wrote:
- the semantics are subtly different from all other uses of 'as' in Python; I'd
like to reserve 'as' for "not a plain assignment"
It's conceptually similar to "import as", no? The keyword "as" is a fuzzy yet
intuitive concept already.
Also, thes
On 2018-04-22 14:33, Chris Angelico wrote:
with open(fn) as f:
with (open(fn) as f):
These two do the same thing, but only because a file object's
__enter__ returns self. So it's dangerous, because it WILL work... and
people will get into the habit of parenthesizing to permit a 'with'
statement
On 2018-04-22 12:37, Chris Angelico wrote:
> Kinda, except that that's not quite a match either. But mainly, the
> comparison with 'with' and 'except' is dangerously incompatible.
Hmm, looks very close conceptually, though mechanics are different.
Dangerous feels like an exaggeration however. I
On 2018-04-21 19:57, Chris Angelico wrote:
Thanks for being patient.
Looks like the crux of the issue is that "with … as" binds the result of the
enter function rather than the context-manager object, as it might first appear.
Therefore it's not compatible with how "as" is used for direct nam
Round 2 (Changed order, see below):
1. with open(fn) as f: # current behavior
2. with (open(fn) as f): # same
3. with closing(urlopen(url)) as dl: # current behavior
5. with (closing(urlopen(url)) as dl): # same
4. with closing(urlopen
On 2018-04-20 14:59, Jelle Zijlstra wrote:
> In other words, the with statement would continue to require an as clause
> outside of the parentheses. A double name binding doesn't seem very
useful
> however.
>
> The with statement does not require an as clause.
Sorry, more precisely
On 2018-04-20 12:43, Chris Angelico wrote:
> Except that that's now a feature of expressions, NOT of the loop
> construct. And then you're left with: why not permit this everywhere?
Sorry, I didn't understand. Didn't mean to imply it couldn't be used
everywhere.
> What would these mean?
My e
On 2018-04-19 23:52, Chris Angelico wrote:
And are limited to conditions that check the truthiness/falsiness of
the value you care about. So that works for re.match, but not for
anything that might return -1 (a lot of C APIs do that, so if you're
working with a thin wrapper, that might be all yo
On 2018-04-07 02:08, Steven D'Aprano wrote:
This isn't gopher, or something with serious unfixable security
vulnerabilities. It works. What more needs to be said?
Interesting, I'd forgotten about the module but this thread brought it from
dusty backup tape back into my brain. Part of the pro
I'm not sure, I found the "with f(x) as y" form previously mentioned the most
readable despite it being a new use case, while not needing new keywords.
-Mike
On 2018-02-23 22:07, David Mertz wrote:
FWIW, the nested loop over a single item is already in the language for 15 years
or something.
On 2018-01-31 17:34, Ned Deily wrote:
Please see "What’s New In Python 3.7" for more information.
Additional documentation for these features and for other changes
will be provided during the beta phase.
https://docs.python.org/3.7/whatsnew/3.7.html
I see that the new classmethod fromisoform
On 2017-12-22 12:15, Chris Barker wrote:
Would it be crazy to bring typing.Any into the builtin namespace?
@dataclass:
a: Any
b: Any = 34
c: int = 0
That reads pretty well to me
> And having Any available in the built in namespace may help in other cases
where
There is al
On 2017-12-19 02:53, Paul Moore wrote:
Also, the fact that no-one raised this issue during the whole time the
PEP was being discussed (at least as far as I recollect) and that
Guido (who of all of us should be most aware of what is and isn't
acceptable use of annotations in the stdlib) approved t
I've used Kivy with buildozer on Android and it generally works well, with a few
issues. Currently it uses the Crystax NDK for Python 3 support.
Does anyone know how this development will affect it?
-Mike
On 2017-12-15 10:06, Glenn Linderman wrote:
I see a variety of Python apps on Android,
Guess the argument for limiting what it accepts would be that every funky
variation will need to be supported until the endtimes, even those of little use
or utility.
On the other hand, it might be good to keep the two implementations the same for
consistency reasons.
Thanks either way,
-Mik
Yeah! I'm available for writing docs and testing it if needed.
Performance is not a big concern in this first version, unless you've already
written most of it. If it is a concern for others then the third-party modules
will still be available as well.
-Mike
On 2017-11-29 16:19, Paul G wr
Hi,
This thread isn't about the numerous third-party solutions that are a pip
command away. But rather getting a minimal return parser to handle
datetime.isoformat() into the std library.
It's been needed for years, and hopefully someone can squeeze it into 3.7 before
its too late. (It tak
This may have gotten bogged down again. Could we get the output of
datetime.isoformat() parsed at a minimum? Perfection is not required.
Looks like there is a patch or two and test cases on the bug.
-Mike
Could anyone put this five year-old bug about parsing iso8601 format date-times
on th
Hi,
Could anyone put this five year-old bug about parsing iso8601 format date-times
on the front burner?
http://bugs.python.org/issue15873
In the comments there's a lot of hand-wringing about different variations that
bogged it down, but right now I only need it to handle the output of
On 2017-10-11 23:05, Nick Coghlan wrote:
It's akin to "static method", "class method", and "instance method" for function
definitions (although the last one isn't a typical decorator, since it's the
default behaviour for functions placed inside a class).
Thanks, I'm still thinking of it as i
On 2017-10-12 00:36, Stéfane Fermigier wrote:
"An object that is not defined by its attributes, but rather by a thread of
continuity and its identity." (from
https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks)
Not sure I follow all this, but Python objects do have identities o
On 2017-10-11 19:56, Nick Coghlan wrote:
From my perspective, the main benefit of a compound name like "data class" is
that it emphasises a deliberate behavioural choice (adopted from attrs): data
classes are just regular classes, with some definition time logic to help define
data fields.
(Apologies for reviving a dead horse, but may not be around at the blessed
time.)
As potential names of this concept, I liked record and row, but agreed they were
a bit too specific and not quite exact. In my recent (unrelated) reading
however, I came across another term and think it might fi
On 2017-09-15 05:08, Michel Desmoulin wrote:
Because given how convenient it is, it will most probably becomes the
default way to write classes in Python. Not just for record.
Yes, would have been great if this was how the original object worked and the
current barebones object was a base(obj
On 2017-09-14 10:45, Stefan Krah wrote:
I'd expect something like a C struct or an ML record.
Struct is taken, and your second example is record.
from dataclass import dataclass
This is more intuitive, since the PEP example also has attached methods
like total_cost(). I don't think t
On 2017-09-12 21:05, Guido van Rossum wrote:
It's ironic that some people dislike "data classes" because these are regular
classes, not just for data, while others are proposing alternative names that
emphasize the data container aspect. So "data classes" splits the difference, by
referring to
On 2017-09-12 19:09, Nick Coghlan wrote:
On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
wrote:
This really does match well with the record concept in databases, and most
people are familiar with that.
No, most people aren't familiar with that - they only become familiar
with it *
On 2017-09-11 17:00, Barry Warsaw wrote:
I’ve used ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib.
Well, "the Pythons" were irreverent, were they not? ;)
-Mike
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
On 2017-09-11 05:26, Eric V. Smith wrote:
On 9/10/17 10:27 PM, Raymond Hettinger wrote:
I've typically used these type of objects as records. When in an irreverent
mood I've called them bags. The short name is helpful as they get used all over
the place. I'll add Nick's "declarative" as i
On 2017-09-10 18:20, Eric V. Smith wrote:
I'll think about adding some more language to the PEP about it.
Agreed, was only looking for mention or example that a specific type was not
required. Perhaps even dusting off the word "annotation" to describe them.
___
On 2017-09-10 23:38, Michel Desmoulin wrote:
I'm going to put some words in explaining why I don't want to use base
classes (I don't think it buys you anything). Do you have a reason for
preferring base classes?
Not preferring, but having it as an alternative. Mainly for 2 reasons:
1 - data
On 2017-09-10 14:23, Ivan Levkivskyi wrote:
This is not the case, static support for dataclasses is an import point of
motivation.
I've needed this functionality a decade before types became cool again. ;-)
It is hard to support static typing for many third party packages like attrs,
since
Thanks for the info.
On 2017-09-08 15:40, Eric V. Smith wrote:
- Are types required?
Annotations are required, the typing module is not.
Maybe an example or two with Any?
I'd rather leave it like it is: typing is referenced only once, for ClassVar.
Guess I really meant "object" or "ty
Thanks for the info.
On 2017-09-08 15:40, Eric V. Smith wrote:
- Are types required?
Annotations are required, the typing module is not.
Maybe an example or two with Any?
I'd rather leave it like it is: typing is referenced only once, for ClassVar.
Guess I really meant "object" or "ty
On 2017-09-08 07:57, Eric V. Smith wrote:
I've written a PEP for…
Apologies for the following list dumb questions and bikesheds:
- 'Classes can be thought of as "mutable namedtuples with defaults".'
- A C/C++ (struct)ure sounds like a simpler description that many more
would understan
On 2017-09-08 07:57, Eric V. Smith wrote:
I've written a PEP for…
Apologies for the following list dumb questions and bikesheds:
- 'Classes can be thought of as "mutable namedtuples with defaults".'
- A C/C++ (struct)ure sounds like a simpler description that many more
would understan
On 2017-07-26 16:36, MRAB wrote:
"nobreak" would introduce a new keyword, but "not break" wouldn't.
Whenever I've used the for-else, I've put a # no-break right next to it, to
remind myself as much as anyone else.
for...: not break: is the best alternative I've yet seen, congrats. Perhaps
While not super technical, this talk by RH got me up to speed on recent
improvements in the implementation:
https://www.youtube.com/watch?v=p33CVV29OG8
I believe there is some sample code linked that you might be able to use for
testing/benchmarking, etc.
-Mike
On 2017-04-25 12:52, Jos
Hi,
Does anyone know why Python 3.6 is not the default Python 3 under the upcoming
Ubuntu Zesty, or what may be holding it back? Is there anyone that could give
it a nudge? It's in the repos but not as python3:
http://packages.ubuntu.com/zesty/python3
http://packages.ubuntu.com/zesty/python
Mercurial is easier to use (for cases outside linux kernel development). It's
too bad the gravity of GitHub tends to override that.
-Mike
On 09/15/2015 05:20 PM, Chris Angelico wrote:
Looks like it's time I spun up my own hg, rather than using the 3.1.2
that ships with Debian.
＞ sudo pip i
And thanks for making it a reality. ;)
-Mike
On 09/08/2015 05:37 PM, Eric V. Smith wrote:
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pytho
Yeah, can't wait to use it!
-Mike
On 09/08/2015 05:37 PM, Eric V. Smith wrote:
On 9/8/2015 8:27 PM, Guido van Rossum wrote:
I'm accepting PEP 498. Congratulations Eric! And thanks to everyone who
contributed. A lot of thought and discussion went into this -- Eric
himself was against the idea
PEP 502 into an overview of the thinking that led to PEP 498?
Or maybe I wasn't clear enough that that's what I was encouraging. :-)
On Tue, Sep 8, 2015 at 11:21 AM, Mike Miller mailto:python-id...@mgmiller.net>> wrote:
Ok, I thought that's what you and others were asking
Ok, I thought that's what you and others were asking for in previous threads.
-Mike
On 09/08/2015 10:32 AM, Guido van Rossum wrote:
Sounds awfully premature. Style guides are typically updated in response to the
___
Python-Dev mailing list
Python-De
Hi,
I'd like to collect thinking on best practices that we can use as a style guide
for string interpolation. Now that arbitrary expressions are very likely to be
included, it is more important to set guidelines than it would otherwise be.
Below is a recent post with some good ideas (though
Nice work!
So we're on the eve of pronouncement and though I've read several bring up the
slightly-unfortunate naming of f-strings in the past, I've not seen recent
discussion on the subject. While the 498 implementation looks best, it still
could be tweaked on the surface to use one of the o
That could be helpful and done without too much work, adding in the best
practices and PEP8 guidelines that have been asked for in other threads.
Are people interested in a "rationale and best practices" for string
interpolation pep?
-Mike
On 09/04/2015 08:15 PM, Guido van Rossum wrote:
Th
On 09/04/2015 08:15 PM, Guido van Rossum wrote:
The text of the PEP has too much on motivation and rationale: maybe that would
be suitable for an informative PEP. The proposal itself is under-specified.
But the real weakness cannot be fixed by improving the text: it is in the key…
I'm plannin
On 08/11/2015 06:47 AM, Eric V. Smith wrote:
2. Let's call them "format strings" not "f-strings".
The latter sounds slightly obnoxious, and also inconsistent with the
others:
r'' raw string
u'' unicode object (string)
f'' format string
Here are my notes on PEP 498.
1. Title: Literal String Formatting
- String Literal Formatting
- Format String Expressions
?
2. Let's call them "format strings" not "f-strings".
The latter sounds slightly obnoxious, and also inconsistent with the
others:
r'' r
Yes, we enable the compile script.
As we require admin rights to install Python and system (not user) modules with
pip, the stdlib .pycs do get created under ProgramFiles at install time.
There might well be a situation where a system pipped module doesn't get
compiled, but to be honest the d
On 09/25/2014 08:43 AM, Donald Stufft wrote:
One thing about *nix is even though you can’t write to your normal Python
install location without root, invoking pip with permissions (assuming you have
them) is as easy as prefacing it with ``sudo`` in most cases. Does Windows have
an equivalent or
Paul Moore wrote:
One thing that I presume would be an issue. Isn't Program Files protected in
newer versions of Windows?
Yes, that's the feature that protects from malicious users/code editing "import
os" to run "format c:\", spam your address book, or look for credit card
numbers, etc.
I
On 09/25/2014 08:50 AM, Steve Dower wrote:
Unfortunately not. The "easy way" is for the executable to declare that it
needs administrative privileges, and then the OS will take over and let you
approve/reject/sign-in/etc. according to your settings.
There is the runas command, though it coul
On 09/24/2014 10:00 PM, Nick Coghlan wrote:
Subject: Re: [Python-Dev] 3.5 release schedule PEP
On 24 Sep 2014 15:15, "Tim Golden" wrote:
>
> On 23/09/2014 18:05, Steve Dower wrote:
>> I'm also considering/experimenting with installing into "Program
>> Files" by default, but I suspect that
On 04/30/2014 04:14 AM, Steve Dower wrote:
Since we are talking about humans, I'd gather most of them trying to install
something on Windows will have heard about ProgramFiles and not be too bothered
at its inclusion in the path.
Modifying PATH is not recommended by Microsoft...
Sorry, I mea
On 04/30/2014 04:14 AM, Steve Dower wrote:
Here are some more minuses beyond those listed on the issue:
I have to say I'm a bit baffled. I expected disagreement, but didn't expect
that multiple reasons against would be made up seemingly at random? I and a
company I work for (that distribut
Hi,
Stepping back a bit...
I doubt you'd take the idea this far, but that Python should need assembly by
professionals before use doesn't match its "Batteries Included" spirit, nor the
PC revolution for that matter.
The reason I brought up the subject at 2.7.7 is because there are greater
c
Hi,
Every change has pluses and minuses. I can't guarantee 100% benefits, only
trying to make the case that the benefits here outweigh them.
Since we are talking about humans, I'd gather most of them trying to install
something on Windows will have heard about ProgramFiles and not be too bot
On 04/29/2014 03:07 PM, Stephen J. Turnbull wrote:
> I have no objection *at all* to making the change in the next feature
> release. I think the "good citizenship" argument is more than
> sufficient, ...
> I'm questioning whether it is a sufficient reason to make a backwards-
> incompatible cha
On 04/29/2014 08:38 AM, Brian Curtin wrote:
The option to add the current install to your path was added 3.3.
Ok, thanks. So there is some precedent it would be useful.
Remember, python-dev's are not the target users of this package, and are a
rather minuscule fraction of the user base.
K
Hi, note the pep, it makes allowances for security enhancements.
-Mike
> Message: 5 Date: Mon, 28 Apr 2014 20:23:12 +0200
> From: Antoine Pitrou
> To: python-dev@python.org Subject:
> Re: [Python-Dev] Python 2.7.7. on Windows
> Message-ID: <20140428202312.6903d62a@fsol>
> Regardless of whether
Hi,
Those bugs were fixed 9 years ago or so around 2005. I use python in
ProgramFiles every day without issue. If another bug has crept in somewhere, it
can be fixed.
-Mike
--
From: Sturla Molden
To: python-dev@python.org
Subject: Re: [Python-Dev] Python 2.7.7
On 04/29/2014 05:12 AM, Steve Dower wrote:
This would be an incredibly painful change that would surprise and hurt a lot of
people.
Hi, I think "incredibly painful" is overstating the case a bit. ;) We're
talking about an installer default, a setting that would still be changeable as
it alw
Greetings,
I've just woken up and noticed Python 2.7.7 is on track to be released, and in a
rather unique event contains a few security enhancements
in addition to the usual fixes:
http://legacy.python.org/dev/peps/pep-0466/
I thought this might be a good time to make a final plea to fix a
lo
99 matches
Mail list logo
