in 2.6 and before execfile is listed in builtin functions, and is not
marked deprecated, and exec is in the simple statements, and is not
marked deprecated.
in 3.0 execfile is not listed in builtin functions, exec is. exec is
not listed in simple statements.
I guess this is an intended
On approximately 1/9/2009 3:40 PM, came the following characters from
the keyboard of Terry Reedy:
Glenn Linderman wrote:
in 2.6 and before execfile is listed in builtin functions, and is not
marked deprecated, and exec is in the simple statements, and is not
marked deprecated.
Because
On approximately 3/3/2009 4:51 PM, came the following characters from
the keyboard of Greg Ewing:
Terry Reedy wrote:
I almost agree, except that the API uses the dict, not list, API.
Yes, as long as the API is dict-like, it really needs to
be thought of as a kind of dict.
Perhaps the
On approximately 3/3/2009 11:22 PM, came the following characters from
the keyboard of Raymond Hettinger:
Perhaps the terminology should be
ordereddict -- what we have here
sorteddict -- hypothetical future type that keeps
itself sorted in key order
+1
-1
Introducing
On approximately 3/22/2009 8:48 PM, came the following characters from
the keyboard of Terry Reedy:
One of the disappointments of CPython 3.0 on Windows is that the switch
to unicode for text (str), coupled with the continued use of a
unicode-oblivious (obtuse) user interface (MS 'Command
On approximately 3/23/2009 12:12 PM, came the following characters from
the keyboard of Terry Reedy:
Glenn Linderman wrote:
One can set CMD into Unicode mode (chcp 65001)... not sure how Python
reacts to that either. But even then...
I tried that and others have reported doing so
On approximately 3/24/2009 10:16 AM, came the following characters from
the keyboard of INADA Naoki:
Hi. I'm Japanese and non-ascii charactor user. (cp932)
We have to use IME to input non-ascii charactor in Windows.
When chcp 65001 in cmd.exe, we cannot use IME on cmd.exe.
So setting codepage
On approximately 4/10/2009 9:56 AM, came the following characters from
the keyboard of Barry Warsaw:
On Apr 10, 2009, at 1:19 AM, gl...@divmod.com wrote:
On 02:38 am, ba...@python.org wrote:
So, what I'm really asking is this. Let's say you agree that there
are use cases for accessing a
On approximately 4/12/2009 2:41 PM, came the following characters from
the keyboard of Tony Nelson:
At 16:30 -0400 04/12/2009, Terry Reedy wrote:
...
Source in .pyb (python-brazil) is parsed with with your new parser,
...
In case anyone ever does this again, I suggest that the extension be
On approximately 4/24/2009 12:59 AM, came the following characters from
the keyboard of Simon Cross:
On Wed, Apr 22, 2009 at 8:50 AM, Martin v. Löwis mar...@v.loewis.de wrote:
For Python 3, one proposed solution is to provide two sets of APIs: a
byte-oriented one, and a character-oriented one,
On approximately 4/24/2009 11:40 AM, came the following characters from
the keyboard of Stephen J. Turnbull:
Antoine Pitrou writes:
Stephen J. Turnbull stephen at xemacs.org writes:
Well, the problem is that both parts are false. If you didn't start
with a valid string in a known
On approximately 4/24/2009 10:06 AM, came the following characters from
the keyboard of Oleg Broytmann:
On Fri, Apr 24, 2009 at 05:29:29PM +0100, MRAB wrote:
I've recently subscribed to this list and received my first Summary of
Python tracker Issues. What I find annoying are the dates, for
On approximately 4/25/2009 5:35 AM, came the following characters from
the keyboard of Martin v. Löwis:
Because the encoding is not reliably reversible.
Why do you say that? The encoding is completely reversible
(unless we disagree on what reversible means).
I'm +1 on the concept, -1 on the
On approximately 4/25/2009 5:22 AM, came the following characters from
the keyboard of Martin v. Löwis:
The problem with this, and other preceding schemes that have been
discussed here, is that there is no means of ascertaining whether a
particular file name str was obtained from a str API, or
On approximately 4/27/2009 12:55 AM, came the following characters from
the keyboard of Cameron Simpson:
On 26Apr2009 23:39, Glenn Linderman v+pyt...@g.nevcal.com wrote:
[...snip...]
There are still issues regarding how Windows and POSIX programs that are
sharing cross-mounted file systems
On approximately 4/27/2009 12:42 PM, came the following characters from
the keyboard of Martin v. Löwis:
It's a private use area. It will never carry an official character
assignment.
I know that U+F - U+F is a private use area. I don't find a
definition of U+F01xx to know what the
On approximately 4/27/2009 12:48 PM, came the following characters from
the keyboard of Martin v. Löwis:
There are still issues regarding how Windows and POSIX programs that
are sharing cross-mounted file systems might communicate file names
between each other, which is not at all clear from
On approximately 4/27/2009 2:14 PM, came the following characters from
the keyboard of Cameron Simpson:
On 27Apr2009 00:07, Glenn Linderman v+pyt...@g.nevcal.com wrote:
On approximately 4/25/2009 5:22 AM, came the following characters from
the keyboard of Martin v. Löwis:
The problem
On approximately 4/27/2009 5:42 PM, came the following characters from
the keyboard of Cameron Simpson:
I think that, almost independent of this PEP, there should be an
os.fsencode() function that takes a byte string (as a POSIX OS call
will take) and performs the _same_ byte-string encoding
On approximately 4/27/2009 8:35 PM, came the following characters from
the keyboard of Martin v. Löwis:
Glenn Linderman wrote:
On approximately 4/27/2009 12:42 PM, came the following characters from
the keyboard of Martin v. Löwis:
It's a private use area. It will never carry an official
On approximately 4/27/2009 8:39 PM, came the following characters from
the keyboard of Martin v. Löwis:
I'm not suggesting the PEP should solve the problem of mounting foreign
file systems, although if it doesn't it should probably point that out.
I'm just suggesting that if the people that
On approximately 4/27/2009 7:11 PM, came the following characters from
the keyboard of Cameron Simpson:
On 27Apr2009 18:15, Glenn Linderman v+pyt...@g.nevcal.com wrote:
The problem with this, and other preceding schemes that have been
discussed here, is that there is no means of ascertaining
On approximately 4/28/2009 10:00 AM, came the following characters from
the keyboard of Martin v. Löwis:
An alternative that doesn't suffer from the risk of not being able to
store decoded strings would have been the use of PUA characters, but
people rejected it because of the potential
On approximately 4/28/2009 10:53 AM, came the following characters from
the keyboard of James Y Knight:
On Apr 28, 2009, at 2:50 AM, Martin v. Löwis wrote:
James Y Knight wrote:
Hopefully it can be assumed that your locale encoding really is a
non-overlapping superset of ASCII, as is
On approximately 4/28/2009 11:55 AM, came the following characters from
the keyboard of MRAB:
I've been thinking of python-escape only in terms of UTF-8, the only
encoding mentioned in the PEP. In UTF-8, bytes 0x00 to 0x7F are
decodable.
UTF-8 is only mentioned in the sense of having special
On approximately 4/28/2009 6:01 AM, came the following characters from
the keyboard of Lino Mastrodomenico:
2009/4/28 Glenn Linderman v+pyt...@g.nevcal.com:
The switch from PUA to half-surrogates does not resolve the issues with the
encoding not being a 1-to-1 mapping, though. The very fact
On approximately 4/28/2009 1:25 PM, came the following characters from
the keyboard of Martin v. Löwis:
The UTF-8b representation suffers from the same potential ambiguities as
the PUA characters...
Not at all the same ambiguities. Here, again, the two choices:
A. use PUA characters to
On approximately 4/28/2009 2:02 PM, came the following characters from
the keyboard of Martin v. Löwis:
Glenn Linderman wrote:
On approximately 4/28/2009 1:25 PM, came the following characters from
the keyboard of Martin v. Löwis:
The UTF-8b representation suffers from the same potential
On approximately 4/28/2009 2:01 PM, came the following characters from
the keyboard of MRAB:
Glenn Linderman wrote:
On approximately 4/28/2009 11:55 AM, came the following characters
from the keyboard of MRAB:
I've been thinking of python-escape only in terms of UTF-8, the only
encoding
On approximately 4/28/2009 7:40 PM, came the following characters from
the keyboard of R. David Murray:
On Tue, 28 Apr 2009 at 13:37, Glenn Linderman wrote:
C. File on disk with the invalid surrogate code, accessed via the str
interface, no decoding happens, matches in memory the file on disk
call 3rd party filenames-as-bytes libraries in 2.x must be tweaked
to do something different than they did before.
On 27Apr2009 23:52, Glenn Linderman v+pyt...@g.nevcal.com wrote:
On approximately 4/27/2009 7:11 PM, came the following characters from
the keyboard of Cameron Simpson
On approximately 4/28/2009 10:52 PM, came the following characters from
the keyboard of Martin v. Löwis:
C. File on disk with the invalid surrogate code, accessed via the str
interface, no decoding happens, matches in memory the file on disk with
the byte that translates to the same surrogate,
On approximately 4/29/2009 12:17 AM, came the following characters from
the keyboard of Martin v. Löwis:
OK, so you are saying that under PEP 383, utf-8b wouldn't be used
anywhere on Windows by default. That's not clear from your proposal.
You didn't read it carefully enough. The first three
On approximately 4/29/2009 12:38 AM, came the following characters from
the keyboard of Baptiste Carvello:
Glenn Linderman a écrit :
3. When an undecodable byte 0xPQ is found, decode to the escape
codepoint, followed by codepoint U+01PQ, where P and Q are hex digits.
The problem
On approximately 4/29/2009 12:29 AM, came the following characters from
the keyboard of Martin v. Löwis:
C. File on disk with the invalid surrogate code, accessed via the str
interface, no decoding happens, matches in memory the file on disk
with
the byte that translates to the same surrogate,
On approximately 4/29/2009 4:07 AM, came the following characters from
the keyboard of R. David Murray:
On Tue, 28 Apr 2009 at 20:29, Glenn Linderman wrote:
On approximately 4/28/2009 7:40 PM, came the following characters from
the keyboard of R. David Murray:
On Tue, 28 Apr 2009 at 13:37
On approximately 4/29/2009 1:28 PM, came the following characters from
the keyboard of Martin v. Löwis:
C. File on disk with the invalid surrogate code, accessed via the
str interface, no decoding happens, matches in memory the file on disk
with the byte that translates to the same surrogate,
On approximately 4/29/2009 1:06 PM, came the following characters from
the keyboard of Martin v. Löwis:
Thanks, fixed.
Thanks for your fixes. They are helpful.
I'm at a loss how to make the text more clear than it already is. I'm
really not good at writing long essays, with a lot of
On approximately 4/29/2009 8:46 PM, came the following characters from
the keyboard of Terry Reedy:
Glenn Linderman wrote:
On approximately 4/29/2009 1:28 PM, came the following characters from
So where is the ambiguity here?
None. But not everyone can read all the Python source code
On approximately 4/29/2009 10:17 PM, came the following characters from
the keyboard of Martin v. Löwis:
I don't understand the proposal and issues. I see a lot of people
claiming that they do, and then spending all their time either
talking past each other, or disagreeing. If everyone who
On approximately 4/29/2009 7:50 PM, came the following characters from
the keyboard of Aahz:
On Thu, Apr 30, 2009, Cameron Simpson wrote:
The lengthy discussion mostly revolves around:
- Glenn points out that strings that came _not_ from listdir, and that are
_not_ well-formed unicode
On approximately 4/30/2009 1:48 AM, came the following characters from
the keyboard of Martin v. Löwis:
I checked how GUI libraries deal with half surrogates.
In pygtk, a warning gets issued to the console
/tmp/helloworld.py:71: PangoWarning: Invalid UTF-8 string passed to
On approximately 5/6/2009 6:33 AM, came the following characters from
the keyboard of Stephen J. Turnbull:
Martin v. Löwis writes:
In any case, Python 3.1b1 may get released today, so it's way too late
for new features in the PEP. They can wait for Python 3.2.
You have convinced me that the
On approximately 5/6/2009 3:08 AM, came the following characters from
the keyboard of MRAB:
M.-A. Lemburg wrote:
Martin v. Löwis wrote:
Judging by the existing names, I think that 'surrogate' would be
reasonable. It already contains the meaning of substitute, it's not too
long, and the codes
On approximately 5/6/2009 12:53 AM, came the following characters from
the keyboard of Martin v. Löwis:
Sorry! I suggest substituting the paragraph above for the paragraph
which begins The encode error handler interface presentlyrequires...
at line 129.
Ah, ok. This was Glen Linderman's
On approximately 5/6/2009 12:18 PM, came the following characters from
the keyboard of Zooko Wilcox-O'Hearn:
On May 6, 2009, at 10:54 AM, Antoine Pitrou wrote:
Zooko Wilcox-O'Hearn zooko at zooko.com writes:
I'm not thinking of API compatibility as much as data compatibility
-- someone used
On approximately 5/6/2009 6:06 PM, came the following characters from
the keyboard of M.-A. Lemburg:
Martin, please stop being silly and just change the name.
Yes, please. If indeed Marc-Andre invented the codec business as he
claims, he would be an appropriate person to give a fiat name
On approximately 5/6/2009 10:53 PM, came the following characters from
the keyboard of Martin v. Löwis:
The error handler designed with utf-8 in mind has no name in the encode
direction and is called utf_8b_decoder_invalid_bytes in the decode
direction. By your reasoning, *that* should be its
On approximately 5/6/2009 11:16 PM, came the following characters from
the keyboard of Martin v. Löwis:
So are you proposing that I should rename the PEP 383 handler
to utf_8b_encoder_invalid_codepoints?
No, he's saying that your algorithm for choosing the PEP 383 handler
should have come up
On approximately 5/7/2009 3:27 PM, came the following characters from
the keyboard of MRAB:
Terry Reedy wrote:
Martin v. Löwis wrote:
So I'm happy to make it surrogatepass and surrogateescape as
These seem adequate. It is not what I would choose or suggest, but it
is adequate, and it is
On approximately 5/16/2009 9:55 AM, came the following characters from
the keyboard of P.J. Eby:
At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote:
Ok I've changed the PEP with all the points you mentioned, if you want
to take a look.
Some notes:
1. Why ';' separation, instead of tabs as in PEP
On approximately 5/16/2009 11:58 AM, came the following characters from
the keyboard of P.J. Eby:
At 11:17 AM 5/16/2009 -0700, Glenn Linderman wrote:
On approximately 5/16/2009 9:55 AM, came the following characters from
the keyboard of P.J. Eby:
At 06:06 PM 5/16/2009 +0200, Tarek Ziadé wrote
On approximately 5/16/2009 1:08 PM, came the following characters from
the keyboard of Martin v. Löwis:
Alexander Shigin wrote:
В Сбт, 16/05/2009 в 14:58 -0400, P.J. Eby пишет:
; *is* valid in Windows filenames, actually. Tabs aresn't.
I was sure ';' is separator for PATH in Windows. Do I
On approximately 5/26/2009 12:48 PM, came the following characters from
the keyboard of Phillip Sitbon:
Hi everyone,
I'm new to the list but I've been embedding Python and working very
closely with the core sources for many years now. I discovered Python
a long time ago when I needed to embed a
On approximately 6/16/2009 11:20 AM, came the following characters from
the keyboard of Scott David Daniels:
MRAB wrote:
I was thinking along the lines of:
def peek(self, size=None, block=True)
If 'block' is True then return 'size' bytes, unless the end of the
file/stream is reached; if
On approximately 8/5/2009 4:28 AM, came the following characters from
the keyboard of Dirkjan Ochtman:
On Wed, Aug 5, 2009 at 13:19, Mark Hammondmhamm...@skippinet.com.au wrote:
Configuring on each clone would certainly be sub-optimal, so the proposal is
this configuration be stored in a
On approximately 8/10/2009 12:12 PM, came the following characters from
the keyboard of Thomas Wouters:
I'm still waiting on a replacement controller, so it wasn't to be today.
Hopefully tomorrow, if the hardware supplier has one in stock. Still no
news on whether we have any chance at all on
On 1/5/2012 9:34 AM, Maciej Fijalkowski wrote:
Also consider that new 2.6.x would go as a security fix to old
ubuntu, but all other packages won't, because they'll not contain
security fixes. Just so you know
Why should CPython by constrained by broken policies of Ubuntu? If the
other
On 1/5/2012 11:49 AM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/05/2012 02:14 PM, Glenn Linderman 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
On 1/5/2012 5:52 PM, Steven D'Aprano wrote:
At some point, presuming that there is no speed penalty, the behaviour
will surely become not just enabled by default but mandatory. Python
has never promised that hashes must be predictable or consistent, so
apart from backwards compatibility
On 1/5/2012 4:10 PM, Nick Coghlan wrote:
On Fri, Jan 6, 2012 at 8:15 AM, Serhiy Storchakastorch...@gmail.com wrote:
05.01.12 21:14, Glenn Linderman написав(ла):
So, fixing the vulnerable packages could be a sufficient response,
rather than changing the hash function. How to fix? Each
On 1/13/2012 5:35 PM, Victor Stinner wrote:
- Glenn Linderman proposes to fix the vulnerability by adding a new
safe dict type (only accepting string keys). His proof-of-concept
(SafeDict.py) uses a secret of 64 random bits and uses it to compute
the hash of a key.
We could mix Marc's collision
On 1/18/2012 9:52 AM, Martin v. Löwis wrote:
I've been seriously considering implementing a balanced tree inside
the dict (again for string-only dicts, as ordering can't be guaranteed
otherwise). However, this would be a lot of code for a security fix.
It*would* solve the issue for good,
On 1/19/2012 8:54 PM, Carl Meyer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Victor,
On 01/19/2012 05:48 PM, Victor Stinner wrote:
[snip]
Using a randomized hash may
also break (indirectly) real applications because the application
output is also somehow randomized. For example,
On 1/23/2012 12:53 AM, Frank Sievertsen wrote:
What if we use a second (randomized) hash-function in case there
are many collisions in ONE lookup. This hash-function is used only
for collision resolution and is not cached.
So this sounds like SafeDict, but putting it under the covers and
On 1/23/2012 10:58 AM, Frank Sievertsen wrote:
On 23.01.2012 19:25, Glenn Linderman wrote:
So this sounds like SafeDict, but putting it under the covers and
automatically converting from dict to SafeDict after a collision
threshold has been reached. Let's call it fallback-dict.
and costs
On 1/26/2012 10:25 PM, Gregory P. Smith wrote:
(and on top of all of this I believe we're all settled on having per
interpreter hash randomization_as well_ in 3.3; but this AVL tree
approach is one nice option for a backport to fix the major
vulnerability)
If the tree code cures the problem,
On 1/26/2012 10:47 PM, Glenn Linderman wrote:
On 1/26/2012 10:25 PM, Gregory P. Smith wrote:
(and on top of all of this I believe we're all settled on having per
interpreter hash randomization_as well_ in 3.3; but this AVL tree
approach is one nice option for a backport to fix the major
On 1/27/2012 11:39 AM, mar...@v.loewis.de wrote:
Another issue occurs to me: when a hash with colliding keys (one that
has been attacked, and has trees) has a non-string key added, isn't
the flattening process likely to have extremely poor performance?
Correct.
Thanks for the
On 2/2/2012 2:10 PM, Ethan Furman wrote:
* Use /Ellipsis/ as the default value (the /.../ singleton).
Accepted. There are no other possible values; it cannot be raised as
it is not an acception; it has the connotation of 'fill in the
rest...' as in /__cause__/ is not set, look in
On 2/2/2012 6:28 AM, Antoine Pitrou wrote:
On Thu, 2 Feb 2012 15:09:41 +0100
Victor Stinnervictor.stin...@haypocalc.com wrote:
Why int? That doesn't seem to bring anything.
It helps to deprecate/replace os.stat_float_times(), which may be used
for backward compatibility (with Python 2.2 ?
On 2/2/2012 3:38 PM, Nick Coghlan wrote:
On Fri, Feb 3, 2012 at 8:37 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
Sorry to bring this up, but the PEP should probably consider another option:
Introducing a precedent following os.stat_decimal_times(). Like
os.stat_float_times, it would
On 2/9/2012 11:53 AM, Mike Meyer wrote:
On Thu, 9 Feb 2012 14:19:59 -0500
Brett Cannonbr...@python.org wrote:
On Thu, Feb 9, 2012 at 13:43, PJ Ebyp...@telecommunity.com wrote:
Again, the goal is fast startup of command-line tools that only use a
small subset of the overall framework; doing
On 2/17/2012 9:24 PM, Mark Hammond wrote:
I've been using the implementation for a number of months now and I
find it incredibly useful.
+1
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 2/21/2012 11:58 AM, Benjamin Peterson wrote:
2012/2/21 Antoine Pitrousolip...@pitrou.net:
Hello,
Shouldn't it be enabled by default in 3.3?
Should you be able to disable it?
Yes, absolutely.
___
Python-Dev mailing list
Python-Dev@python.org
On 3/12/2012 8:48 PM, C. Titus Brown wrote:
I feel like there's a middle ground where stable, long-term go-to modules could
be mentioned, though. I don't spend a lot of time browsing PyPI, but I suspect
almost everyone spends a certain amount of time in the Python docs (which is a
testimony to
On 3/13/2012 6:31 AM, Paul Moore wrote:
It can be very hard to separate the good from the indifferent (or even
bad) when browsing PyPI. I've found some very good packages recently
which I'd never have known about without some random comment on a
mailing list.
+1
However, I'm not keen on
On 3/14/2012 8:57 AM, Terry Reedy wrote:
On 3/14/2012 10:12 AM, Brian Curtin wrote:
As with last year, I've put together a summary of the Python Language
Summit which took place last week at PyCon 2012. This was compiled
from my notes as well as those of Eric Snow and Senthil Kumaran, and I
On 3/16/2012 9:22 AM, Lindberg, Van wrote:
On 3/16/2012 10:53 AM, Paul Moore wrote:
The only way I can read this to make sense is that you somehow
consider the Python installation as part of your development
environment (you mentioned source control earlier in the thread -
surely you
On 3/16/2012 6:25 PM, Carl Meyer wrote:
Hi Mark,
On 03/16/2012 05:53 PM, Mark Hammond wrote:
* All executables and scripts go into the root of the Python install.
This directory is largely empty now - it is mainly a container for other
directories. This would solve the problem of needing 2
On 3/19/2012 2:26 AM, Kristján Valur Jónsson wrote:
Hi Carl.
I'm very interested in this work.
At CCP we work heavily with virtual environments. Except that we don't use virtualenv
because it is just a pain in the neck. We like to be able to run virtual python
environments of various types
On 3/19/2012 11:52 AM, Jesse Noller wrote:
I'd like to discuss top-posting.
Somewhere else, please.
Oh, that was your point :)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 3/20/2012 11:50 AM, Merlijn van Deen wrote:
As this is being considered an 'incompatible change' on the bug
tracker item [1] in any case, I'd like to mention that this might also
be a convenient moment to re-think the default install location. After
all, software is supposed to be installed
On 3/20/2012 4:25 PM, Mark Hammond wrote:
I think it does. Consider I've installed Python as a system
install. Now I want to install some other package - ideally that
installer will request elevation - all well and good - the .py files
are installed. However, next time I want to run Python,
On 3/22/2012 10:02 AM, Steven D'Aprano wrote:
As they say, the 99% who are lousy designers give the rest a bad name.
*wink*
:)
My first impression of this page:
http://www.python.org/~gbrandl/build/html/index.html
was that the grey side-bar gives the page a somber, perhaps even
dreary,
On 3/24/2012 5:41 PM, Ben Finney wrote:
It's madness to expect web designers to hobble the flexibility of a web
page to cater preferentially for one minority over others.
But largely, the 99% that makes the rest of them look bad, do, in fact,
do exactly that.
On 3/24/2012 11:34 PM, Georg Brandl wrote:
I've also added a little questionable gimmick to the sidebar (when you collapse
it and expand it again, the content is shown at your current scroll location).
It would be educational to see how you pulled that trick! I will look if
I get time.
On 3/26/2012 10:19 AM, R. David Murray wrote:
Like Philip, I have*one* window. My window manager (ratpoison) is more
like 'screen' for X: you*can* split the window up, but it is*much* more
useful to have only one window visible at a time, most of the time.
I'm amazed at the number of
On 3/26/2012 10:58 AM, Ethan Furman wrote:
Glenn Linderman wrote:
On 3/26/2012 10:19 AM, R. David Murray wrote:
Like Philip, I have *one* window. My window manager (ratpoison) is
more
like 'screen' for X: you *can* split the window up, but it is *much*
more
useful to have only one window
On 3/26/2012 12:27 PM, PJ Eby wrote:
On Mon, Mar 26, 2012 at 12:58 PM, Carl Meyer c...@oddbird.net
mailto:c...@oddbird.net wrote:
No disagreement here. I think virtualenv's sweet spot is as a
convenient
tool for development environments (used in virtualenvwrapper fashion,
where
On 3/26/2012 1:21 PM, Glenn Linderman wrote:
Hmm. And here's something else that might be missing: integration of
the launcher with .py files that are actually ZIP archives... where
does it find the #! line? (probably it can't, currently -- I couldn't
figure out how to make it do
On 3/29/2012 3:50 PM, Brian Curtin wrote:
On Thu, Mar 29, 2012 at 17:45, Benjamin Petersonbenja...@python.org wrote:
2012/3/29 Brian Curtinbr...@python.org:
After talking with Martin and several others during the language
summit and elsewhere around PyCon, PEP 397 should be accepted. I
On 4/2/2012 4:37 AM, Victor Stinner wrote:
The API looks much more complex than the API proposed in PEP 418 just
to get the time. You have to call a function to get a function, and
then call the function, instead of just calling a function directly.
Instead of returning an object with a now()
On 4/2/2012 2:40 PM, Nick Coghlan wrote:
On Tue, Apr 3, 2012 at 3:44 AM, Glenn Lindermanv+pyt...@g.nevcal.com wrote:
One thing I don't like about the idea of fallback being buried under some
API is that the efficiency of that API on each call must be less than the
efficiency of directly
On 4/6/2012 4:11 PM, Cameron Simpson wrote:
Another alternative is the public lists-of-clocks.
After watching this thread with amusement and frustration, amusement
because it is so big, and so many people have so many different
opinions, frustration, because it seems that few of the clocks
On 4/21/2012 8:53 PM, Brett Cannon wrote:
imp.cache_from_source() (and thus also imp.source_from_cache()) has
special semantics compared to how os.path.join() works. For instance,
if you look at test_imp you will notice it tries to use the same path
separator as is the farthest right in the
On 4/27/2012 12:34 AM, Eric Snow wrote:
On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsawba...@python.org wrote:
It's somewhat of a corner case, but I think a PEP couldn't hurt. The
rationale section would be useful, at least.
On 4/27/2012 11:49 AM, R. David Murray wrote:
On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Lindermanv+pyt...@g.nevcal.com
wrote:
On 4/27/2012 12:34 AM, Eric Snow wrote:
On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsawba...@python.org wrote:
It's somewhat of a corner case, but I think a PEP
On 4/27/2012 1:00 PM, Brett Cannon wrote:
I'm personally in favour of changing the insertion of '' to sys.path
to inserting the cwd when the interpreter is launched.
+1
___
Python-Dev mailing list
Python-Dev@python.org
On 5/3/2012 2:00 PM, mar...@v.loewis.de wrote:
I think that .bat files strictly *have* to have CRLF line endings.
Nope. Both .bat and .cmd work fine with LF only in Win7 (and IIRC, in
XP as well, but I just tested Win7)
___
Python-Dev mailing list
1 - 100 of 674 matches
Mail list logo
