On Feb 28, 2014, at 10:27 PM, Nick Coghlan wrote:
With the new macro in place, the existing Py_CLEAR(x) macro would be
equivalent to Py_SETREF(x, NULL).
Originally I was also concerned about the how will people know there's no
implicit incref?, but I've since become satisfied with the fact that
On Mar 01, 2014, at 08:15 AM, Nick Coghlan wrote:
It *is* playing refcounting games - it's decrefing the existing target
while stealing a reference to the new target, just like the existing
SET_ITEM macros and somewhat like Py_CLEAR (although in that case, it's
more obvious that we will never
On Feb 25, 2014, at 03:03 PM, Maciej Fijalkowski wrote:
Oh, I thought security fixes go to all python releases.
Well, not the EOL'd ones of course.
Where's the analysis on backporting SIPHash to older Python versions? Would
such a backport break backward compatibility? What other impacts
On Feb 21, 2014, at 12:36 AM, Ethan Furman wrote:
If not, should we put the change in RC2 / Final? The main reason I'm pushing
for this is that Enum is still new, but after 3.4.0 is cut we then have to
deal with backwards compatibility issues.
I concur this should be cherry picked. Let's not
On Feb 19, 2014, at 07:50 AM, Guido van Rossum wrote:
That's why it's RC2 and not 3.4final, right? Once Larry says it's baked,
everyone *will* have a chance to test it. What value is a preview of the
preview really going to add? Give Larry some trust and freedom to do things
in the way that makes
On Feb 20, 2014, at 10:24 AM, Stephen J. Turnbull wrote:
But should Ubuntu desires be distorting a volunteer RE's process?
Ubuntu 14.04 final freeze is April 10[1], so I think that's the drop dead date
for getting 3.4 final into Ubuntu 14.04. Matthias may correct me, but I think
if we can hit
On Feb 19, 2014, at 12:38 AM, Matthias Klose wrote:
Am 17.02.2014 00:25, schrieb Larry Hastings:
And my local branch will remain private until 3.4.0 final ships!
sorry, but this is so wrong. Is there *any* reason why to keep this branch
private?
IMO, no. read-only for !larry sure, but not
On Feb 18, 2014, at 08:25 AM, Nick Coghlan wrote:
Thanks, that's enough to persuade me that it is a good idea to restore that
behaviour (and make it an official part of the language spec) as part of
the eliminate remaining barriers to migration from Python 2 effort in 3.5.
At the very least,
On Feb 03, 2014, at 06:43 AM, Larry Hastings wrote:
But that only fixes part of the problem. Our theoretical extension that
wants to be binary-compatible with 3.3 and 3.4 still has a problem: how can
they support signatures? They can't give PyMethodDefEx structures to 3.3, it
will blow up. But
On Jan 28, 2014, at 09:17 AM, tds...@gmail.com wrote:
yes I know the main usage is to generate pyc files. But marshal is also used
for other stuff and is the fastest built in serialization method. For some
use cases it makes sense to use it instead of pickle or others. And people
use it not only
On Jan 20, 2014, at 12:05 AM, Larry Hastings wrote:
Contestant 5: Put in __clinic__ directory, add .h
foo.c - __clinic__/foo.c.h
foo.h - __clinic__/foo.h.h
This is cached output right? IOW, it can be regenerated if it's missing. If
so, this seems like a nice parallel to __pycache__.
On Jan 17, 2014, at 11:00 AM, Brett Cannon wrote:
I would rephrase it to switch to %-formatting for bytes usage for their
common code base.
-1. %-formatting is so neanderthal. :)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
On Jan 14, 2014, at 10:52 AM, Guido van Rossum wrote:
Which reminds me. Quite a few people have spoken out in favor of loud
failures rather than silent wrong output. But I think that in the
specific context of formatting output, there is a long and IMO good
tradition of producing (slightly) wrong
On Jan 12, 2014, at 06:11 PM, Guido van Rossum wrote:
Perhaps not, but it's a hint that you should probably think about an
encoding. It's symmetric with how '%s' % b'x' returns b'x'. Think of
it as payback time. :-)
Which unfortunately causes no end of headaches, often difficult to debug.
On Jan 12, 2014, at 09:45 PM, Glenn Linderman wrote:
Quotes in the stream are a great debug hint, without blowing up.
They actually terrible for debugging for exactly the same reason as coercion
in Python 2. It's rarely what you really want, it silently succeeds, and it
means that the user
On Jan 13, 2014, at 02:13 PM, Donald Stufft wrote:
On Jan 13, 2014, at 1:58 PM, Guido van Rossum gu...@python.org wrote:
I hear the objections against b'%s' % 'x' returning b'x' loud and
clear, and if the noise about that sub-issue is preventing folks from
seeing the absurdity in PEP 460, we
On Jan 11, 2014, at 10:38 AM, Ethan Furman wrote:
You've already stated you don't care that much and are willing to let the PEP
as-is be rejected. Why not remove your name and let Victor have it back? Is
he not the original author? (If this is protocol just say so -- remember I'm
still new to
(Resending with an adjusted Subject and not through Gmane. Apologies for
duplicates.)
On Jan 08, 2014, at 01:51 PM, Stephen J. Turnbull wrote:
Benjamin Peterson writes:
I agree. This is a very important, much-requested feature for low-level
networking code.
I hear it's much-requested, but
On Jan 08, 2014, at 01:51 PM, Stephen J. Turnbull wrote:
Benjamin Peterson writes:
I agree. This is a very important, much-requested feature for low-level
networking code.
I hear it's much-requested, but is there any description of typical
use cases?
The two unported libraries that are
On Jan 07, 2014, at 10:39 PM, Serhiy Storchaka wrote:
Only this option will solve all my issues.
How hard would it be to put together some sample branches that provide
concrete examples of the various options?
My own opinion could easily be influenced by having some hands-on time with
actual
On Jan 07, 2014, at 08:53 PM, Antoine Pitrou wrote:
- move all generated code to separate C files, which would then be
#included'd into the main module file
I'm not a big fan of this approach either, but maybe not as vehemently, so -0.
- gather all generated code to a single place in the C
On Jan 07, 2014, at 10:40 AM, Georg Brandl wrote:
Very nice, thanks. If I was to make a blasphemous suggestion I would
even target it for Python 3.4. (No, seriously, this is a big issue
- see the recent discussion by Armin - and the big names involved show
that it is a major holdup of 3.x
On Jan 07, 2014, at 11:13 AM, Victor Stinner wrote:
Twisted and Mercurial don't support Python 3.
(I heard that Twisted Core supports Python 3, but I don't know if it's
true nor the Python 3 version.)
Parts of Twisted do run on Python 3 (and are even available in Ubuntu), but if
PEP 460 helps
On Jan 07, 2014, at 05:16 AM, Donald Stufft wrote:
Given the low adoption rates for Python 3 it would not surprise me if people
who are hampered by the lack of this change are willing to wait until a Python
version is released that has it.
If that means waiting until 3.5, then I disagree. The
On Jan 07, 2014, at 11:13 PM, Antoine Pitrou wrote:
On Tue, 7 Jan 2014 15:46:50 -0500
Barry Warsaw ba...@python.org wrote:
If adopted for Python 3.4, PEP 460 should be modest in its goals, but I think
I'd still like to see the following excluded and unknown features added:
* Attribute
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Dec 17, 2013, at 01:18 PM, Tres Seaver wrote:
http://hg.python.org/cpython/rev/b1e94e332ec8
Do we really want to change an undocumented-but-effectively-public API in
a late-in-the-release-cycle third dot release? It caused, ZODB's tests
to
On Dec 09, 2013, at 04:00 PM, TaeWong wrote:
The name Jonas Wagner comes before Zachary Ware and Barry Warsaw.
Maybe it's time to give up on trying to sort by last name, and just sort by
first character?
No, this is not a bold attempt to jump higher up in the list.
-AABarry
On Nov 23, 2013, at 11:13 PM, Gregory P. Smith wrote:
our buildbots are setup to configure --with-pydebug which also
unfortunately causes them to compile with -O0... this results in a python
binary that is excruciatingly slow and makes the entire test suite run take
a long time.
It would be
On Nov 23, 2013, at 11:01 PM, Gregory P. Smith wrote:
http://buildbot.python.org/all/buildslaves/gps-ubuntu-exynos5-armv7l
Cool thanks. Antoine, do you still want or need my buildbot, or can I take it
off-line? (FWIW, because the hardware is no longer supported, it's pretty
much stuck at
On Nov 24, 2013, at 06:02 PM, Antoine Pitrou wrote:
If the hardware is not supported anymore, and since the machine was
rather slow, I agree it's ok to let it go.
Done!
(The machine's name was 'hope', so now we're hope-less :).
-Barry
___
Python-Dev
On Nov 23, 2013, at 10:34 AM, Gregory P. Smith wrote:
I've got a nice ARM box to add to the pool (it should be a lot faster and
more reliable than warsaw-ubuntu-arm; hopefully making its way to stable).
Once that's up, let me know. I'd like to eventually retire this box. It's
unsupported
On Nov 22, 2013, at 03:55 PM, Antoine Pitrou wrote:
(perhaps Barry will play a bass solo? :-))
Now, now, we don't want to give Chris incentive, do we? :)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
On Nov 21, 2013, at 06:36 PM, Terry Reedy wrote:
As usual, 'I am not a lawyer', but if Christian wants to push forward with
using 'Python 2.8', I suggest that he consult the PSF Trademark Committee and
lawyer first.
Just to make clear, I'm definitely *not* suggesting this particular case ever
On Nov 21, 2013, at 02:16 PM, Kristján Valur Jónsson wrote:
Oh, this is the misunderstanding. No one is trying to get permission for
CPython 2.8, only Stackless Python 2.8.
I think this is a very bad idea. We've worked hard to send the message that
the migration path is to Python 3 and while I
On Nov 22, 2013, at 02:04 AM, Victor Stinner wrote:
Hum, I don't think that regex module will enter Python 3.4 before this
week-end, there is no PEP.
Okay thanks, I'll remove this from PEP 429.
For the Introspection information for builtins, I think the PEP 436
has been accepted. The code has
On Nov 20, 2013, at 09:52 PM, Christian Tismer wrote:
Many customers are forced to stick with Python 2.X because of other products,
but they require a Python 2.X version which can be compiled using Visual
Studio 2010 or better. This is considered an improvement and not a bug fix,
where I
On Nov 17, 2013, at 05:14 PM, Victor Stinner wrote:
2013/11/16 Maciej Fijalkowski fij...@gmail.com:
Can I see some writeup how -OO benefit embedded devices?
You get smaller .pyc files. In an embedded device, the whole OS may be
written in a small memory, something like 64 MB or smaller.
On Nov 17, 2013, at 11:05 PM, Maciej Fijalkowski wrote:
My problem with -O and -OO is that their arguments are very circular.
Indeed, I understand the need why you would want in certain and
limited cases to remove both docstrings and asserts. So some options
for doing so are ok. But a lot of
On Nov 08, 2013, at 12:49 PM, Eric Snow wrote:
I'm pleased to announce that Brett Cannon and Nick Coghlan (the
co-BDFL-delegates) have accepted PEP 451 for inclusion in Python 3.4.
Both of them have contributed substantially to the discussions of the
proposal and have helped make it solid. I'm
On Nov 07, 2013, at 10:42 PM, Christian Heimes wrote:
You misunderstood me. I'm not proposing a global SSLContext object but a
factory function that creates a context for Python stdlib modules. Right
now every urllib, http.client, nntplib, asyncio, ftplib, poplib and
imaplib have duplicated code.
On Nov 04, 2013, at 08:04 AM, Nick Coghlan wrote:
Since making it work would be a lot of work for minimal benefit, the most
that could realistically be done is to make it fail a little more
gracefully (I believe that would need to be done on the Vim side of things,
though).
Right. I can't
Hello Pythoneers and Pythonistas,
Five years ago this month, we released Python 2.6. It was an important
version in Python's evolution, as it was developed in tandem with Python 3.0
and had the express intent of starting the transition toward Python 3.
Amazingly, here we are five years later,
On Oct 24, 2013, at 02:11 AM, Ned Deily wrote:
I don't know where any other potential 2.7.6 or 3.3.3 issues stand at this
point. But I'd like Benjamin and Georg to propose an aggressive schedule so
we can get these fixes out there.
Does this problem affect 2.6? 2.6.9 final is scheduled for
On Oct 25, 2013, at 07:54 AM, Nick Coghlan wrote:
Since the default build settings work, that sounds reasonable. Perhaps
include a note somewhere that targeting a more recent ABI may involve
copying the 2.7 readline.c?
I'll probably add issue 18458 to the announcement and release page. That way
On Oct 21, 2013, at 08:46 PM, Nick Coghlan wrote:
There's also the fact that I prefer the current lower case names, but
strongly dislike using lower case names for classes (despite the fact
closing was included in the original contextlib with a non PEP 8 compliant
class name).
Ha! The only
On Oct 21, 2013, at 08:46 PM, Nick Coghlan wrote:
There's also the fact that I prefer the current lower case names, but
strongly dislike using lower case names for classes (despite the fact
closing was included in the original contextlib with a non PEP 8 compliant
class name).
I think PEP 8
This is a reminder that Python 2.6.9 final - and by that I mean *really* final
as it will be the last supported version of Python 2.6 - is scheduled for
release one week from today, on October 28, 2013.
All known showstopper security bugs have been applied to the branch. If you
know of anything
On Oct 21, 2013, at 06:21 PM, Dan Stromberg wrote:
I may be missing something, but it seems the Python tarballs and hashes are
on the same host, and this is not an entirely good thing for security.
All the tarballs are signed with the GPG keys of the release managers. The
hashes are just a
On Oct 18, 2013, at 01:26 AM, Nick Coghlan wrote:
By contrast, suppress() and redirect_stdout() are the *first* general
purpose context managers added to contextlib since its incarnation in
Python 2.5 (although there have been many various domain specific
context manager additions elsewhere in
On Oct 17, 2013, at 08:40 PM, Xavier Morel wrote:
I think there's already a significant split between context managers
which handle the lifecycle of a local resource (file, transaction) and
those which purport to locally alter global-ish state (cwd,
decimal.localcontext, logging.captureWarnings,
On Oct 16, 2013, at 08:31 AM, Eric Snow wrote:
When a module's maintainer makes a decision on a relatively insignificant
addition to the module, I'd expect little resistance or even comment (the
original commit was months ago). That's why I'm surprised by the reaction
to this change. It just
On Oct 15, 2013, at 11:52 AM, R. David Murray wrote:
I think 'trap' would be much clearer. What about making the context
manager provide the trapped exception, in a fashion similar to
what assertRaises does? Even if that was almost never used in practice,
the fact that the CM provides only
On Oct 12, 2013, at 03:27 PM, Raymond Hettinger wrote:
The module maintainer (Nick) approved the name change from his original
preference for ignored(). That should had been the end of it.
As a general plea, please be sure to record the rationale and decisions in the
appropriate place, such as
On Oct 12, 2013, at 11:19 AM, Brett Cannon wrote:
Actually thanks should go to Barry who rewrote the language ref docs for
import.
I can actually say it was fun due to all the great work on importlib. :)
-Barry
___
Python-Dev mailing list
On Oct 11, 2013, at 07:24 AM, Ned Batchelder wrote:
I'd like to suggest that we not consider PEPs to be documentation.
Absolutely +1. That was never the intention behind PEPs.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
On Oct 11, 2013, at 09:24 AM, Antoine Pitrou wrote:
I don't think that this contextlib.ignore() thing has been discussed a
lot.
Ezio was -1 on the tracker, and Eric Smith was -0. I'd like to add my
-1 too. This is a useless addition (the traditional idiom is perfectly
obvious) and makes reading
On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote:
Maybe to fit in with other verb-like APIs used as context managers:
it's open() not opened().
open() predates context managers, but maybe we need a new convention.
with ignore(FileNotFoundError):
vs
with ignored(FileNotFoundError):
To me
On Oct 11, 2013, at 01:19 PM, Eric V. Smith wrote:
But, to continue to paint the shed, shouldn't it be ignoring, to match
closing?
Maybe so.
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
On Oct 11, 2013, at 08:32 PM, Serhiy Storchaka wrote:
I am -1 too. But I want to hear more about interact with ExitStack (note that
ExitStack itself is not widely used in the stdlib).
Yet. :)
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
On Oct 12, 2013, at 09:06 AM, Nick Coghlan wrote:
I'm not too fussy about the name (clearly). We originally picked ignored(),
Raymond asked if he could change it to ignore() (and I said yes),
Just as a point of order, it would be good to capture such side-channel
discussions in the relevant
On Oct 06, 2013, at 11:41 AM, Benjamin Peterson wrote:
What is the usecase for minimizing the memory usage of Python in the
middle of a program?
There are environments where Python is being actively discouraged in part due
to its memory footprint. For example, we can't use Python on Ubuntu
On Oct 03, 2013, at 02:08 PM, Eric Snow wrote:
On Thu, Oct 3, 2013 at 1:57 PM, A.M. Kuchling a...@amk.ca wrote:
On Thu, Oct 03, 2013 at 08:48:47PM +0200, eric.snow wrote:
-- Issue #19951: Fix docstring and use of _get_suppported_file_loaders() to
+- Issue #19151: Fix docstring and use of
On Sep 30, 2013, at 11:07 PM, Nick Coghlan wrote:
My plan now is to split the PEP in two, so the 3.4 changes can be accepted
as non-controversial, including the offer of core dev assistance in
creating and maintaining a Windows installer for pip to better support
earlier versions. The backporting
Hello Pythoneers and Pythonistas,
I'm happy to announce the availability of Python 2.6.9 release candidate 1.
Python 2.6.9rc1 is a security-fix source-only release for Python 2.6. This
means that general bug maintenance has ended, and only critical security
issues are being fixed. It also
Just a quick reminder that I intend to cut 2.6.9rc1 tomorrow.
Here are the open issues still on my list:
- 16040 - nntplib: unlimited readline() from connection
This one is waiting for a patch, but TBH if it doesn't make it into 2.6.9 I
won't care too much. I also don't mind reviewing and
On Sep 27, 2013, at 09:14 PM, Brett Cannon wrote:
I don't see any issue with redirecting the discussion. python-tulip@ is
acting like a SIG for the module, so no real precedent beyond it not being
hosted as a mail.python.org list.
The PEP process even allows for this formally. Please add a
On Sep 28, 2013, at 12:48 PM, Stephen J. Turnbull wrote:
*shrug* I just think the risks are higher than acknowledged (just
because you have so far failed to imagine a problem doesn't mean it
won't appear), and that the meta effect that Even Guido admits that
Python 3 isn't ready for prime time
On Sep 26, 2013, at 02:30 PM, Nick Coghlan wrote:
- the module name should be _ensurepip in all versions
- the PEP should explicitly state that the don't remove _ensurepip
and it's wheel files caveat for redistributors applies only in 3.4+
(where removing it will break pyvenv)
I'm sorry that I
On Sep 23, 2013, at 09:15 PM, Nick Coghlan wrote:
With the last round of updates, I believe PEP 453 is ready for
Martin's pronouncement.
I want to raise an objection to PEP's proposal to add this as a new feature to
Python 2.7 and 3.3. I understand the rationale as stated here:
On Sep 25, 2013, at 05:33 PM, Donald Stufft wrote:
I think it should be placed in the source tree for the stable releases. The
reasoning is that 2.7 is going to stick around for a long time. Immediately
this won't be ubiquitous but as time goes on you'll be able to be ensured
that a ``python -m
On Sep 26, 2013, at 07:14 AM, Nick Coghlan wrote:
On 26 Sep 2013 06:53, Barry Warsaw ba...@python.org wrote:
Why does it have to be added to the source tree for stable releases?
If it can get into the installers another way, it doesn't, really. It only
needs to be in the source tree for 3.4
On Sep 25, 2013, at 06:15 PM, Donald Stufft wrote:
Well I don't think many scripts will be executing ensurepip, maybe i'm wrong,
but yes it does mean that not all Python 2.7's are alike. Most likely though
at some point 2.7.XXX is going to be near standard as the 2.7 hold outs stay
on it and time
On Sep 26, 2013, at 09:01 AM, Nick Coghlan wrote:
Would a leading underscore in the module name make you more comfortable
with the idea? It's really intended mostly as a hidden implementation
detail of the installers and pyvenv anyway, so calling it _ensurepip
would help make that explicit while
On Sep 25, 2013, at 07:08 PM, Donald Stufft wrote:
On Sep 25, 2013, at 7:04 PM, Barry Warsaw ba...@python.org wrote:
So, why shouldn't we add enum to the Python 2.7 stdlib?
Because with PEP453 you can just ``pip install enum34`` it :)
Of course, pip messing with global Python state
On Sep 22, 2013, at 10:34 AM, Brett Cannon wrote:
The rule of thumb I go by is the docstring should be enough to answer the
question what args does this thing take and what does it do in general to
know it's the function I want and another one in the same module? quickly
and succinctly; i.e. just
On Sep 18, 2013, at 10:04 AM, Skip Montanaro wrote:
As a MacBook Pro user running Snow Leopard/10.6.8, I would find the
lack of a binary release problematic, were it not for the fact that I
routinely build from source (and don't do anything Mac-specific with
Python). For those not familiar with
On Sep 18, 2013, at 03:00 PM, r.david.murray wrote:
http://hg.python.org/cpython/rev/fb3ad8a749c8
changeset: 85749:fb3ad8a749c8
branch: 2.6
parent: 85735:1b673e0fd8f3
user:R David Murray rdmur...@bitdance.com
date:Wed Sep 18 08:49:25 2013 -0400
summary:
#14984: only
On Sep 11, 2013, at 01:09 PM, Serhiy Storchaka wrote:
In ideal it should be one high-quality (float64?) multichannel (5+1?) but
short master file and it's lower-quality copies made by third-party tools. In
ideal the content should be related to Python.
I have some pro-audio recording
On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote:
The http.client and email.message modules convert headers to lower
case, but keep the original case.
As RDM pointed out on the tracker, email headers aren't a great use case for
this because they aren't really dictionaries. They're lists with
On Sep 10, 2013, at 03:57 PM, Antoine Pitrou wrote:
Le Tue, 10 Sep 2013 09:49:28 -0400,
Barry Warsaw ba...@python.org a écrit :
On Sep 10, 2013, at 12:04 PM, Victor Stinner wrote:
The http.client and email.message modules convert headers to lower
case, but keep the original case.
As RDM
On Sep 10, 2013, at 08:08 AM, Guido van Rossum wrote:
Why do several posts in this thread have an Unsubscribe link that tries to
unsubscribe me from the list? (I saw one by Glen, and another one by Donald
Stufft.)
This is way off topic, but I suspect your original response didn't trim your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sep 05, 2013, at 07:31 PM, Jesus Cea wrote:
I just received an email from my OpenID provider, myOpenID, saying
that they drop OpenID service next February. I wonder what other
OpenID providers are used by other python-dev fellows.
What are you
On Sep 05, 2013, at 11:33 AM, Toshio Kuratomi wrote:
Sortof The way OAuth looks to me, it's designed to prove that a given
client is authorized to perform an action. It's not designed to prove that
the given client is a specific person. In some cases, you really want to
know the latter and
On Sep 05, 2013, at 09:07 PM, Antoine Pitrou wrote:
Which sites exactly? I can login to BitBucket and *.python.org using
OpenID, not Persona.
I think Persona is just too new to see it around much yet. Or maybe Mozilla
needs better PR.
-Barry
___
On Sep 06, 2013, at 01:09 AM, Oleg Broytman wrote:
I will change my mind when Google and GitHub start using them.
Neither Google nor GitHub are free or open. Bitbucket and Facebook aren't
either. I'm not saying they're bad services because of that of course, but I
don't want to have to rely on
On Sep 06, 2013, at 12:36 AM, Oleg Broytman wrote:
You cannot login using OpenID to most interesting popular sites.
GMail? No. Twitter? No. Facebook? FriendFeed? identi.ca? No, no, no.
I'd be surprised if you ever saw the big social networking sites support
OpenID or Persona. They want to
Hello Pythonistas,
Python 2.6.9 is the last planned release of the 2.6.x series. This will be a
security-only source-only release. It is currently scheduled for October
2013, and after this Python 2.6 will have reached its end-of-life and the
branch will be retired.
On Aug 20, 2013, at 07:33 PM, Tim Peters wrote:
So let's try a different question ;-) Would anyone _object_ to
completing the process described in the docs: merge 3.2 into 3.3,
then merge 3.3 into default? I'd be happy to do that. I'd throw away
all the merge changes except for adding the
On Aug 06, 2013, at 02:36 PM, Eli Bendersky wrote:
Personally, I dislike all non-simple uses of Enums. One such use is adding
behavior to them. This can always be split to separate behavior from the
Enum itself, and I would prefer that. We went to great lengths to ensure
that things work in
On Aug 01, 2013, at 11:05 AM, Alexander Belopolsky wrote:
I will start experimenting with 100-char limit, but I think it is still too
wide for auto-wrapped text. Maybe we should have a stronger
recommendation to keep 80-char limit for docstrings and other embedded
text. It is OK to have an
On Aug 01, 2013, at 11:52 AM, R. David Murray wrote:
So as we edit the docs, we re-wrap. Just like we do with the legacy
code :)
+1!
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On Jul 24, 2013, at 05:12 AM, Bohuslav Kabrda wrote:
in recent days, there has been a discussion on fedora-devel (see thread [1])
about moving to Python 3 as a default.
I've been lurking via Gmane. :)
- Should we point /usr/bin/python to Python 3 when we make the move?
Over in Debian
On Jul 24, 2013, at 08:26 AM, Toshio Kuratomi wrote:
nod I think bkabrda is looking for some clarification on PEP-394. My
reading and participation in the previous discussions lead me to believe
that while PEP-394 wants to be diplomatic, the message it wants to get
across is:
1) warn
On Jul 25, 2013, at 01:41 AM, Nick Coghlan wrote:
How's this for an updated wording in the abstract:
* for the time being, all distributions should ensure that python
refers to the same target as python2
* however, users should be aware that python refers to python3 on at
least Arch Linux
On Jul 17, 2013, at 09:35 AM, Brett Cannon wrote:
Or how about dropping the whole ``from ... import ...`` format entirely?
0.5 wink; seriously, it's implementation is a pain and it has wonky
semantics
Yes, let's break *everything* :)
-Barry
signature.asc
Description: PGP signature
On Jul 16, 2013, at 02:02 PM, Thomas Wouters wrote:
In my experience changing the name of a package is problematic for more
reasons than just 'import'. We used to do the put-in-a-package thing for
third-party packages at Google, and we quit doing it because it was just
too painful: it's hard to
On Jul 15, 2013, at 11:02 PM, Chris McDonough wrote:
Given that misunderstanding, is there a way to divorce stdlib-centric
guidelines like the one being discussed now from PEP8-ness? I don't
think any amount of marketing effort or reasoned explanation is going to
separate PEP8 from correct code
On Jul 16, 2013, at 11:28 AM, Richard Oudkerk wrote:
BTW, how does the use of __all__ effect things? Somewhere I got the idea
that if a module uses __all__ then anything not listed is internal. I take
it that is wrong?
Purely technically, __all__ is there to affect how from-import-* works. I
On Jul 16, 2013, at 11:48 PM, Nick Coghlan wrote:
For the general case, the patch I posted to the issue tracker sets the
precedence as docs - __all__ - leading underscore.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
On Jul 16, 2013, at 04:10 PM, Nick Coghlan wrote:
Yeah, we should probably be a bit more vocal in pointing out that PEP
8 is something to be applied judiciously, *not* treated as sacred
writ, never to be questioned. It's very tempting to just sigh and
ignore it, instead of explicitly pointing out
601 - 700 of 2552 matches
Mail list logo
