On 10/5/2011 8:07 PM, Antoine Pitrou wrote:
On Thu, 6 Oct 2011 10:55:07 +1100
Cameron Simpson wrote:
Equally, why on earth are you running tests as root!?!?!?!?! Madness.
It's as bad as compiling stuff as root etc etc. A bad idea all around,
securitywise.
Especially, I would think, a builtbot
On 10/7/2011 10:06 AM, Nick Coghlan wrote:
On Fri, Oct 7, 2011 at 9:21 AM, "Martin v. Löwis" wrote:
> if (!PyUnicode_READY(foo)) is not better, also because of
PyUnicode_IS_READY(foo).
I prefer PyUnicode_IS_READY(foo)< 0 over PyUnicode_IS_READY(foo) == -1.
Ok, so feel free to replace
On 10/7/2011 6:18 AM, Glyph wrote:
To sum up what I believe is now the consensus from this thread:
1. Anyone setting up a buildslave should take care to invoke the build
in an environment where an out-of-control buildbot, potentially
executing arbitrarily horrible and/or malicious code
On 10/8/2011 12:57 PM, Giampaolo Rodolà wrote:
I have a couple of doubts about this though.
The first one is about licensing.
Other have answered -- follow the license in giving credit, etc.
My second doubt is about morality.
Although this might be useful to those people who are forced to us
On 10/10/2011 4:21 PM, Giampaolo Rodolà wrote:
Thanks everybody for your feedback.
I created a gcode project here:
http://code.google.com/p/pycompat/
This project will be easier if the test suite for a particular
function/class/module is up to par. If you find any gaping holes, you
might file
On 10/12/2011 10:58 AM, Barry Warsaw wrote:
On Oct 12, 2011, at 10:24 AM, Benjamin Peterson wrote:
2011/10/12 Antoine Pitrou:
I'd like some advice on what the best path is in cases such as:
A :exc:`socket.error` is raised for errors from the call
to :func:`inet_ntop`.
Should I replace
On 10/15/2011 7:47 AM, "Martin v. Löwis" wrote:
-- Issue #10517: After fork(), reinitialize the TLS used by the
PyGILState_* - APIs, to avoid a crash with the pthread implementation in
RHEL 5. Patch - by Charles-François Natali.
You should restore this NEWS entry and add a new one to say that t
On 10/17/2011 9:16 AM, Michael Foord wrote:
Hey folks,
The title of the "Global Module Index" for 3.2 documentation is "Python
3.1.3 documentation".
http://docs.python.org/py3k/modindex.html
Verified. Clicking [index] in upper right goes to
http://docs.python.org/py3k/genindex.html
3.2.2 vers
On 10/25/2011 4:31 AM, Victor Stinner wrote:
Le Mardi 25 Octobre 2011 09:09:56 vous avez écrit :
I propose to raise Unicode errors if a filename cannot be decoded on
Windows, instead of creating a bogus filenames with questions marks.
Can you please elaborate what APIs you are talking about ex
On 10/30/2011 5:39 PM, Victor Stinner wrote:
Terry J. Reedy is also concerned about backward compatibility (3.2 ->
3.3). Emiting a warning, disabled by default, is a softer solution :-)
The fact that Mark, Martin, and someone else, I believe, agree with you
that the bytes api is not useful at
On 11/1/2011 2:20 PM, David Bailey wrote:
population of windows users of python, make idle easier to use or fix
print in 3.X or both.
print is fixed in 3.x. This is not the place to argue otherwise. If you
want to rant againt print as function, go to python-list.
If one looks up 'print' in
On 11/3/2011 3:16 PM, Victor Stinner wrote:
Le jeudi 3 novembre 2011 18:14:42, mar...@v.loewis.de a écrit :
There is a backwards compatibility issue with PEP 393 and Unicode
exceptions: the start and end indices: are they Py_UNICODE indices, or
code point indices?
I had the impression that we
On 11/3/2011 5:43 PM, "Martin v. Löwis" wrote:
I had the impression that we were abolishing the wide versus narrow
build difference and that this issue would disappear. I must have missed
something.
Most certainly. The Py_UNICODE type continues to exist for backwards
compatibility. It is now
On 11/4/2011 3:39 AM, "Martin v. Löwis" wrote:
Is it worth the hassle? We can just port our existing error handlers,
and I guess the few third-party error handlers written in C (if any)
can bear the transition.
That was my question exactly. As the author of PEP 393, I was leaning
towards full b
On 11/8/2011 10:49 AM, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When merging from 3.2 to 3.3 "Misc/NEWS" always conflicts (lately).
Instead of copy&paste the test manually between versions, has anybody
a better workflow?.
If a bug is fixed in 3.2.latest, then it will not
On 11/9/2011 6:28 AM, Nick Coghlan wrote:
So bug fixes should be recorded in both places - the 3.3a1 notes
record the deltas against 3.2.0, not against whatever the latest
release of 3.2 happens to be when 3.3 is released.
OK, I see that now.
Idea 2: If "What's New in Python 3.3 Alpha 1?" had
On 11/9/2011 11:14 AM, Barry Warsaw wrote:
I think we should have an official pronouncement about Python 2.8,
http://python.org/download/releases/2.7.2/ (and similar) already say:
The Python 2.7 series is scheduled to be the last major version in the
2.x series before 2.x moves into an extende
On 11/13/2011 5:52 PM, eli.bendersky wrote:
http://hg.python.org/cpython/rev/87ecfd5cd5d1
changeset: 73541:87ecfd5cd5d1
branch: 2.7
parent: 73529:c3b063c82ae5
user:Eli Bendersky
date:Mon Nov 14 01:02:20 2011 +0200
summary:
Normalize the keyword arguments documentati
On 11/21/2011 5:36 AM, Maciej Fijalkowski wrote:
==
PyPy 1.7 - widening the sweet spot
==
We're pleased to announce the 1.7 release of PyPy. As became a habit, this
release brings a lot of bugfixes and performance improvements over
On 11/22/2011 10:35 AM, Stefan Behnel wrote:
Maciej Fijalkowski, 22.11.2011 15:46:
2011/11/21 Terry Reedy:
I strongly recommend that where it makes a difference, the pypy
python3
project target 3.3. In particular, don't reproduce the buggy
narrow-build
behavior of 3.2 and before (pe
On 11/22/2011 3:28 PM, Philip Jenvey wrote:
One reason to target 3.2 for now is it's not a moving target.
Neither is the basic design and behavior of the new unicode
implementation. On 3.2 narrow builds, including Windows
>>> len('\U00010101')
2
With 3.3, the answer will be, properly, 1. I
On 11/22/2011 7:42 PM, Benjamin Peterson wrote:
2011/11/22 Antoine Pitrou:
On Tue, 22 Nov 2011 16:42:35 -0500
Benjamin Peterson wrote:
2011/11/22 Antoine Pitrou:
On Tue, 22 Nov 2011 21:29:43 +0100
benjamin.peterson wrote:
http://hg.python.org/cpython/rev/77ab830930ae
changeset: 73697:77ab
On 11/24/2011 5:02 PM, Matt Joiner wrote:
What if you broke up the read and built the final string object up. I
always assumed this is where the real gain was with read_into.
If a pure read takes twice as long in 3.3 as in 3.2, that is a concern
regardless of whether there is a better way.
-
On 12/3/2011 3:58 PM, Antoine Pitrou wrote:
On Sat, 3 Dec 2011 21:39:03 +0100
Antoine Pitrou wrote:
One primary example is the performance question:
file:///home/antoine/cpython/32/Doc/build/html/faq/programming.html#my-program-is-too-slow-how-do-i-speed-it-up
Woohoo. This should of course b
On 12/4/2011 5:59 AM, Tim Golden wrote:
http://bugs.python.org/issue13524
Someone raised issue13524 yesterday to illustrate that a
subprocess will crash immediately if an environment block is
passed which does not contain a valid SystemRoot environment
variable.
Note that the calling (Python) p
On 12/8/2011 1:31 AM, Chris McDonough wrote:
What's the case against?
From a 3.x perpective, an irrelevant 'u' would be pure noise and make
the language a bit harder to learn. The intent for 3.x is that one be
able to learn 3.x without knowing anything about 2.x. So bridge stuff
has been pu
On 12/8/2011 10:53 AM, Jannis Leidel wrote:
possible at all). That means to reduce the number of hacks needed and
thoroughly reviewing to not suddenly lead into a maintenance dead
end. E.g. I'm still not sure the one codebase strategy is better than
the 2to3 strategy.
One codebase with version
On 12/8/2011 7:52 PM, Glyph wrote:
Zooming back in to the actual issue this thread is about, I think the
u""-vs-"" issue is a bit of a red herring, because the _real_ problem
here is that 2to3 is slow and buggy and so migration efforts are
starting to work around it, and therefore want to run the
On 12/8/2011 8:39 PM, Vinay Sajip wrote:
It's not the speed of 2to3 per se; this seems very reasonable for a
> tool of its type > It's the overall process, which currently involves
running 2to3
> on an
entire codebase (for example, using setup.py with flags to run 2to3
during setup).
Oh. Tha
On 12/8/2011 8:31 AM, Philipp A. wrote:
hi devs,
just an idea that popped up in my mind: re.findall() returns a list of
tuples, where every entry of each tuple represents a match group.
since match groups can be named, we are able to use named tuples instead
of plain tuples here, in the same fas
On 12/9/2011 5:17 AM, Nick Coghlan wrote:
As Chris pointed out though, the real problem with the "repeatedly run
2to3" workflow is that it can make interpreting tracebacks from the
field *really* hard.
This just gave me the idea of tagging tracebacks with the Python version
number. Something
On 12/10/2011 12:09 PM, PJ Eby wrote:
On Fri, Dec 9, 2011 at 11:11 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:
This just gave me the idea of tagging tracebacks with the Python
version number. Something like
Traceback (Py3.2.2, most recent call last):
and perhaps wi
On 12/10/2011 12:52 PM, Steven D'Aprano wrote:
Terry Reedy wrote:
On 12/9/2011 5:17 AM, Nick Coghlan wrote:
As Chris pointed out though, the real problem with the "repeatedly run
2to3" workflow is that it can make interpreting tracebacks from the
field *really* hard.
This j
On 12/10/2011 4:32 PM, Glyph Lefkowitz wrote:
On Dec 10, 2011, at 2:38 AM, Stefan Behnel wrote:
Note, however, that html5lib is likely way too big to add it to the
stdlib, and that BeautifulSoup lacks a parser for non-conforming HTML
in Python 3, which would be the target release series for bet
On 12/10/2011 9:25 PM, Glyph Lefkowitz wrote:
On Dec 10, 2011, at 6:30 PM, Terry Reedy wrote:
A little data: the HTML5lib project lives at
https://code.google.com/p/html5lib/
It has 4 owners and 22 other committers.
If there really are 4 'owners' rather than 4 people with admin
On 12/13/2011 2:02 PM, PJ Eby wrote:
On Tue, Dec 13, 2011 at 11:24 AM, Antoine Pitrou mailto:solip...@pitrou.net>> wrote:
On Tue, 13 Dec 2011 15:28:31 +0100
"Laurence Rowe" mailto:l...@lrowe.co.uk>> wrote:
>
> The approach that most people seem to have settled on for porting
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which aims to do
this. It's basically 2to3, but with a package of custom fixers in a package
'lib2to23.fixers' adapted from the corresponding fixers in lib2to3.
When, some year in the future,
On 12/13/2011 6:36 PM, exar...@twistedmatrix.com wrote:
On 09:37 pm, tjre...@udel.edu wrote:
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which
aims to do
this. It's basically 2to3, but with a package of custom fixers in a
package
'lib2t
On 12/13/2011 7:01 PM, "Martin v. Löwis" wrote:
What I'm asking is that
(1) The other values be documented as reserved, rather than as illegal.
How is that different?
(2) The macros produce an error rather than silently corrupting data.
In debug mode, or release mode? -1 on release mode.
On 12/14/2011 2:26 PM, Petri Lehtinen wrote:
The problem boils down to the fact that you cannot really check
whether a filesystem entry is a directory without calling stat() or
fstat().
My personal opinion is that support for DONT_HAVE_STAT and
DONT_HAVE_FSTAT defines should be dropped because
On 12/15/2011 5:31 AM, Vinay Sajip wrote:
In response to http://bugs.python.org/issue13516 I'm thinking of implementing
some changes in the rotating file handlers, as outlined here:
http://plumberjack.blogspot.com/2011/12/improved-flexibility-for-log-file.html
The changes (including tests) are
On 12/15/2011 3:58 AM, anatoly techtonik wrote:
1. It is not a proposal, but a defect (well, you may argue, but please,
don't)
You state a controversial opinion as a fact and then request that others
not discuss it. To me, this is a somewhat obnoxious hit-and-run tactic.
If you do not want t
On 12/16/2011 5:03 AM, Mark Shannon wrote:
Of course using __slots__ saves more memory,
but people don't use them much.
Do you think the stdlib should be using __slots__ more?
--
Terry Jan Reedy
___
Python-Dev mailing list
Python-Dev@python.org
htt
On 12/20/2011 3:51 AM, Antoine Pitrou wrote:
On Mon, 19 Dec 2011 22:42:43 +0100
benjamin.peterson wrote:
http://hg.python.org/cpython/rev/d85efd73b0e1
changeset: 74088:d85efd73b0e1
branch: 3.2
parent: 74082:71e5a083f9b1
user:Benjamin Peterson
date:Mon Dec 19 16:41:11
On 12/20/2011 11:15 AM, Benjamin Peterson wrote:
2011/12/20 Antoine Pitrou:
Le mardi 20 décembre 2011 à 10:57 -0500, Benjamin Peterson a écrit :
In that case, I would rather speak of "fast" functions rather than
"implemented in C" functions (a la the itertools docs). Would that be
acceptable?
The talk was a presentation yesterday by Alexander Klink and Julian
Wälde at the Chaos Communication Congress in Germany hash...@alech.de
I read the non-technical summary at
http://arstechnica.com/business/news/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack.ars
and
On 12/29/2011 4:31 PM, Christian Heimes wrote:
The hash randomization idea adds a salt to throw the attacker of course.
Instead of
position = hash& mask
it's now
hash = salt + hash
As I understood the talk (actually, the bit of Perl interpreter C code
shown), the randomization is to
On 12/30/2011 8:04 PM, Jim Jewett wrote:
I'll state it more strongly. hash probably should not change (at
least for this),
I agree, especially since the vulnerability can be avoided by using 64
bit servers and will generally abate as more switch anyway.
> but we may
want to consider a dif
On 12/31/2011 4:43 PM, PJ Eby wrote:
Here's an idea. Suppose we add a sys.hash_seed or some such, that's
settable to an int, and defaults to whatever we're using now. Then
programs that want a fix can just set it to a random number,
I do not think we can allow that to change once there are h
On 1/1/2012 10:13 AM, Guido van Rossum wrote:
PS. Is the collision-generator used in the attack code open source?
As I posted before, Alexander Klink and Julian Wälde gave their project
email as hash...@alech.de. Since they indicated disappointment in not
hearing from Python, I presume they w
On 1/1/2012 12:28 PM, Christian Heimes wrote:
Am 01.01.2012 17:54, schrieb Antoine Pitrou:
I don't understand. FNV-1 multiplies the current running result with a
prime and then xors it with the following byte. This is also what we do.
(I'm assuming 103 is prime)
There must be a major diffe
On 1/2/2012 12:55 AM, Paul McMillan wrote:
Terry Reedy said:
I understood Alexander Klink and Julian Wälde, hash...@alech.de, as saying
that they consider that using a random non-zero start value is sufficient to
make the hash non-vulnerable.
I've been talking to them. They're hap
On 1/3/2012 5:02 PM, Bill Janssen wrote:
Software that depends on an undefined hash function for synchronization
and persistence deserves to break, IMO. There are plenty of
well-defined hash functions available for this purpose.
The doc for id() now says "This is an integer which is guarantee
On 1/5/2012 3:01 PM, Paul Smedley wrote:
File "./setup.py", line 1154, in detect_modules
for arg in sysconfig.get_config_var("__CONFIG_ARGS").split()]
AttributeError: 'NoneType' object has no attribute 'split'
make: *** [sharedmods] Error 1
File "./setup.py", line 1368, in detect_modules
if '
On 1/5/2012 3:10 PM, Ethan Furman wrote:
Tres Seaver wrote:
1) the security problem is not in CPython, but rather in web servers
that use dict inappropriately.
Most webapp vulnerabilities are due to their use of Python's cgi module,
which it uses a dict to hold the form / query string data b
On 1/7/2012 3:48 AM, Paul Smedley wrote:
using _init_posix() for 'os2' instead of _init_non_posix is the fix for
this.
sysconfig.py also needs the following changes:
--- \dev\Python-2.7.2-o\Lib\sysconfig.py 2012-01-06 19:27:14.0
+1030
+++ sysconfig.py 2012-01-07 19:03:00.0 +1030
On 1/7/2012 12:57 PM, Christian Heimes wrote:
Am 07.01.2012 12:02, schrieb Stefan Behnel:
Admittedly, this may require some adaptation for the PEP393 unicode memory
layout in order to produce identical hashes for all three representations
if they represent the same content. So it's not a drop-
On 1/7/2012 4:47 PM, Benjamin Peterson wrote:
2012/1/7 "Martin v. Löwis":
I just tried porting Python as a Metro (Windows 8) App, and failed.
Is this required for Python to run on Windows 8?
No, normal 'desktop' programs will still run in desktop mode.
Sorry if that's a dumb question. I'm
On 1/7/2012 4:25 PM, Vinay Sajip wrote:
The subprocess.Popen constructor takes stdin, stdout and stderr keyword
arguments which are supposed to represent the file handles of the child process.
The object also has stdin, stdout and stderr attributes, which one would naively
expect to correspond to
On 1/9/2012 8:52 PM, Nick Coghlan wrote:
On Tue, Jan 10, 2012 at 7:59 AM, Antoine Pitrou wrote:
Please avoid using the terms "minor version" and "major version", they
are confusing.
Indeed. "Feature release" (2.7, 3.2, 3.3) and "release series" (2.x,
3.x) are the least confusing terms we have
On 1/10/2012 12:14 PM, Antoine Pitrou wrote:
I changed the terminology in my latest changeset:
http://hg.python.org/devguide/rev/f39d063ab3dd
Important to notice is that the major / minor distinction isn't
relevant in most contexts, while the feature / bugfix distinction is.
Where "major" plays
On 1/13/2012 7:14 AM, Nick Coghlan wrote:
print("\n".join(list((lambda:(yield from ("Cheers,", "Nick")))(
I pulled, rebuilt, and it indeed works (on Win 7).
I just remembered that Tim Peters somewhere (generator.c?) left a large
comment with examples of recursive generators, such as knigh
On 1/13/2012 8:58 PM, Gregory P. Smith wrote:
It is perfectly okay to break existing users who had anything depending
on ordering of internal hash tables. Their code was already broken.
Given that the doc says "Return the hash value of the object", I do not
think we should be so hard-nosed. T
On 1/17/2012 3:34 PM, Antoine Pitrou wrote:
Hello,
We would like to propose the following PEP to change (C)Python's release
cycle. Discussion is welcome, especially from people involved in the
release process, and maintainers from third-party distributions of
Python.
Regards
Antoine.
PEP: 4
On 1/17/2012 5:59 AM, anatoly techtonik wrote:
1. print() buffers output on Python3
2. print() also buffers output on Python2, but only on Linux
No, print() does not buffer output. It merely sends it to a file.
4. print() is not guilty - it is sys.stdout.write() that buffers output
Oh, you
On 1/17/2012 6:42 PM, Antoine Pitrou wrote:
On Tue, 17 Jan 2012 18:29:11 -0500
Terry Reedy wrote:
To me, as I understand the proposal, the title is wrong. Our current
feather releases already are long-term support versions. They get bugfix
releases at close to 6 month intervals for 1 1/2 -2
On 1/18/2012 8:06 PM, Nick Coghlan wrote:
On Thu, Jan 19, 2012 at 10:19 AM, Steven D'Aprano wrote:
Do we have any evidence of this alleged bitrot? I spend a lot of time on the
comp.lang.python newsgroup and I see no evidence that people using Python
believe the standard library is rotting from
On 1/19/2012 1:04 PM, Stephen J. Turnbull wrote:
Ethan Furman writes:
> Where does one draw the line between feature and bug?
Bug: Doesn't work as documented.
The basic idea is that the x.y docs define (mostly) the x.y language.
Patches to the x.y docs fix typos, omissions, ambiguiti
On 1/20/2012 11:17 AM, Victor Stinner wrote:
There is no perfect solutions, drawbacks of each solution should be compared.
Amen.
One possible attack that has been described for a collision counting
dict depends on knowing precisely the trigger point. So let
MAXCOLLISIONS either be configure
On 1/20/2012 10:55 AM, Frank Sievertsen wrote:
Hello,
I still see at least two ways to create a DOS attack even with the
collison-counting-patch.
2. The second attack actually attacks that 1000 allowed string
comparisons are still a lot of work.
First I added 999 strings that collide with a o
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as
OtherError'. This is just what you want to be able to say. Since 'raise'
without a current error results in a TypeError, so should 'raise as
OtherError'. I would
On 1/20/2012 2:51 PM, Donald Stufft wrote:
I think the counting collision is at best a bandaid and not a proper fix
stemmed from a desire to not break existing applications on a bugfix
release ...
My opinion of counting is better than yours, but even conceding the
theoretical, purity argument
On 1/20/2012 7:40 PM, Steven D'Aprano wrote:
Benjamin Peterson wrote:
2012/1/20 Terry Reedy :
Since 'raise' means 're-raise the current error', 'raise as OtherError'
means (clearly to me, anyway) 're-raise the current error as
OtherError'.
Tha
On 1/27/2012 2:54 PM, Guido van Rossum wrote:
On Fri, Jan 27, 2012 at 9:08 AM, Ethan Furman wrote:
Guido van Rossum wrote:
Did you consider to just change the
words so users can ignore it more easily?
Yes, that has also been discussed.
Speaking for myself, it would be only slightly better
On 1/28/2012 3:55 AM, Nick Coghlan wrote:
I am currently -something on the proposal as it because it will surely
create a lot of hassles and because I do not think it is necessary the
best solution to the motivating concerns.
Don't consider this PEP a purely theoretical proposal, because it
On 1/31/2012 3:10 PM, Raymond Hettinger wrote:
On Jan 29, 2012, at 6:11 PM, John O'Connor wrote:
On Sat, Jan 28, 2012 at 3:07 PM, Benjamin Peterson
mailto:benja...@python.org>> wrote:
But why would you want to pass a float? It seems like API abuse to me.
Agreed. Anything else seems meaning
On 2/1/2012 3:07 PM, Guido van Rossum wrote:
On Wed, Feb 1, 2012 at 10:48 AM, Ethan Furman wrote:
Guido van Rossum wrote:
Hm... Reading this draft, I like the idea of using "raise X from
None", but I still have one quibble. It seems the from clause sets
__cause__, and __cause__ can indicate t
On 2/3/2012 9:53 AM, Yury Selivanov wrote:
Re "raise ValueError from ..."
The use cases for Ellipsis/... are 99.99% internal. The typical Python
programmer will never see or have cause to worry about such a thing.
The problem is that we really want an exception attribute that is
missing in
On 2/3/2012 6:18 PM, Steven D'Aprano wrote:
Now we're talking about having to add __preview__ into that mix too?
As I understand it, Guido nixed that idea. (Or did I imagine that?)
No, you are right, discussion should cease. It is already marked
'rejected' and listed under Abandoned, Withdr
On 2/5/2012 12:44 PM, Blockheads Oi Oi wrote:
You may remember me from a couple of years ago when I was trying to help
out with Python. Unfortunately I trod on a few toes. I now know why. I
have been diagnosed with Asperger Syndrome at 55 years old.
I would like to give it another go.
Hi Mark,
On 2/6/2012 8:01 AM, Eli Bendersky wrote:
On one hand I agree that ET should be emphasized since it's the better
API with a much faster implementation. But I also understand Martin's
point of view that minidom has its place, so IMHO some sort of
compromise should be reached. Perhaps we can recom
On 2/7/2012 4:51 PM, PJ Eby wrote:
One thing I'm a bit worried about is repeated imports, especially ones
that are inside frequently-called functions. In today's versions of
Python, this is a performance win for "command-line tool platform"
systems like Mercurial and PEAK, where you want to del
On 2/7/2012 9:35 PM, PJ Eby wrote:
On Tue, Feb 7, 2012 at 6:40 PM, Terry Reedy mailto:tjre...@udel.edu>> wrote:
importlib could provide a parameterized decorator for functions that
are the only consumers of an import. It could operate much like this:
def imps(mod):
On 2/8/2012 11:13 AM, Brett Cannon wrote:
On Tue, Feb 7, 2012 at 22:47, Nick Coghlan
I'm not sure such an addition would help much with the base
interpreter start up time though - most of the modules we bring in are
because we're actually using them for some reason.
It wouldn't.
On 2/8/2012 3:16 PM, Brett Cannon wrote:
On Wed, Feb 8, 2012 at 14:57, Terry Reedy
The intent of what I proposed it to be transparent for imports within
functions. It would be a minor optimization if anything, but it would
mean that there is a lazy mechanism in place.
For top-level imports
On 2/8/2012 2:18 PM, Mark Shannon wrote:
A pretty clear draft PEP.
Changes to repr() output and iteration order:
For most cases, this will be unchanged.
However for some split-table dictionaries the iteration order will
change.
Neither of these cons should be a problem.
Modules which meddle wi
On 2/9/2012 3:27 PM, Glenn Linderman wrote:
On 2/9/2012 11:53 AM, Mike Meyer wrote:
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannon wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Eby wrote:
Again, the goal is fast startup of command-line tools that only use a
small subset of the overall framework; d
On 2/9/2012 7:19 PM, PJ Eby wrote:
Right. It was the part of the post that mentioned that all they sped up
was knowing which directory the files were in, not the actual loading of
bytecode. The thought then occurred to me that this could perhaps be
applied to normal importing, as a zipimport-s
On 2/10/2012 9:06 AM, Eli Bendersky wrote:
Whenever the Python core development team decides that a new package should be
included into the standard library, but isn't entirely sure about whether the
package's API is optimal, the package can be included and marked as
"provisional".
In the next
On 2/18/2012 11:54 PM, Ejaj Hassan wrote:
Hello everyone,
I am trying to work on Python bugs following the tutorial given in the
python website.
I have installed Tortoise svn and visual studio 2010, I cloned a copy
of cpython as it is advised in the website using, however I am having
some problem
On 2/20/2012 8:23 AM, Nick Coghlan wrote:
Does anyone object to me naming myself PEP czar for PEP 3144?
I think it great that you volunteer to be the PEP czar and hope Guido
appoints you -- especially after your response to Antoine. Since this is
a Python 3 module, let us start off with a mod
On 2/20/2012 7:49 AM, anatoly techtonik wrote:
People on NaCl list are asking about Python support for development
of native web applications in Python. Does anybody have experience
compiling Python for NaCl?
https://groups.google.com/d/topic/native-client-discuss/ioY2jmw_OUQ/discussion
I s
On 2/20/2012 1:33 PM, antoine.pitrou wrote:
http://hg.python.org/cpython/rev/c760bd844222
changeset: 75058:c760bd844222
user:Antoine Pitrou
date:Mon Feb 20 19:30:23 2012 +0100
summary:
Issue #13641: Decoding functions in the base64 module now accept ASCII-only
unicode stri
On 2/20/2012 11:52 PM, Guido van Rossum wrote:
On Mon, Feb 20, 2012 at 4:53 PM, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
> Also, "Czar" is commonly used in US politics as an informal term for the
top
> official responsible for an area.
I think here the most important connotat
On 2/22/2012 1:57 AM, Nick Coghlan wrote:
In the tracker, someone proposed that the option is necessary to synchronize
the seed across processes in a cluster. I'm sure people will use it for that
if they can.
Yeah, that use case sounds reasonable, too. Another example is that,
even within a ma
On 2/24/2012 11:41 AM, Benjamin Peterson wrote:
2012/2/24 Tshepang Lekhonkhobe:
Hi,
I was of the thought that Old String Formatting |"%s" % foo| was to be
phased out by Advanced String Formatting |"{}.format(foo)|. I however
keep seeing new code committed into the main VCS using the old style.
We have two similar proposals, PEPs 407 and 413, to speed up the release
of at least library changes. To me, both have major problems with
version numbering.
I think the underlying problem is starting with a long-term fixed
leading '3', which conveys no information about current and future
ch
On 2/26/2012 1:50 PM, mar...@v.loewis.de wrote:
Zitat von Eli Bendersky :
- The formatting operations described here are obsolete and may go away
in future
- versions of Python. Use the new :ref:`string-formatting` in new code.
+ The formatting operations described here are modelled on C's pr
Stefan, thank you for the massive rewrite.
On 2/26/2012 11:21 AM, Paul Moore wrote:
On 26 February 2012 13:41, Antoine Pitrou wrote:
We have several options with regard to 2.7 and 3.2:
1) Won't fix.
Given the extent of the rewrite, this one has my preference.
+1 (although I'd word it a
On 2/26/2012 5:38 PM, Nick Coghlan wrote:
Ah, thanks, I knew there was another term that had a new-style
counterpart: percent formatting vs brace formatting.
Hooray!
Exact parallel and value-neutral.
--
Terry Jan Reedy
___
Python-Dev mailing list
Py
2001 - 2100 of 2504 matches
Mail list logo
