On Mon, Mar 19, 2012 at 20:20, Barry Warsaw wrote:
>>Can we have some guideline to allow only plain text emails, so as to
>>avoid cases like
>>http://mail.python.org/pipermail/docs/2012-March/007999.html, where
>>you are forced to scroll horizontally in order to read the text.
>
> docs is a differ
I believe we should make a monotonic_time method that assures monotonicity
and be done with it. Forward steadiness can not be guaranteed. No
parameters.
On Mar 20, 2012 2:56 PM, "Steven D'Aprano" wrote:
> On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote:
>
> > Said differently: time
On Mar 20, 2012, at 3:33 AM, Matt Joiner wrote:
> I believe we should make a monotonic_time method that assures monotonicity
> and be done with it. Forward steadiness can not be guaranteed. No parameters.
>
I think this discussion has veered off a bit into the overly-theoretical.
Python cann
Guido van Rossum wrote:
I personally like having 'iter' in the name (e.g. iterkeys() -- note
that we dropped this in Py3k because it's no longer an iterator, it's
a dict view now. But I don't want to promote that style for ipaddr.py.
+1 from me too on having all methods that return iterators
c
2012/3/20 Jim J. Jewett :
>
>
> In http://mail.python.org/pipermail/python-dev/2012-March/117762.html
> Georg Brandl posted:
>
>>> + If available, a monotonic clock is used. By default, if *strict* is
>>> False,
>>> + the function falls back to another clock if the monotonic clock failed
>>>
> I think this discussion has veered off a bit into the overly-theoretical.
> Python cannot really "guarantee" anything here
That's why the function name was changed from time.monotonic() to
time.steady(strict=True). If you want to change something, you should
change the documentation to list OS
For those who missed it, in http://bugs.python.org/issue14302, Martin
recently commented:
"""
After more discussion, it appears that this change is too incompatible
to be done in a single release.
Therefore, I propose a long-term change into this direction, with the
actual change not happeni
On Tue, 20 Mar 2012 04:43:44 -0400, Glyph wrote:
>
> On Mar 20, 2012, at 3:33 AM, Matt Joiner wrote:
>
> > I believe we should make a monotonic_time method that assures monotonicity
> > and be done with it. Forward steadiness can not be guaranteed. No
> > parameters.
> >
>
> I think this dis
pysandbox is a Python sandbox. By default, untrusted code executed in
the sandbox cannot modify the environment (write a file, use print or
import a module). But you can configure the sandbox to choose exactly
which features are allowed or not, e.g. import sys module and read
/etc/issue file.
http
Greg Ewing wrote:
Guido van Rossum wrote:
I personally like having 'iter' in the name (e.g. iterkeys() -- note
that we dropped this in Py3k because it's no longer an iterator, it's
a dict view now. But I don't want to promote that style for ipaddr.py.
+1 from me too on having all methods that
On 3/20/2012 5:48 AM, Mark Hammond wrote:
> While I'm still unclear on the actual benefits of this, Martin's
> approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of the latest
discussion.
A question for you Mark, Paul, (a
On 20/03/2012 14:08, VanL wrote:
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of the latest
discussion.
A
Germane to this discussion, I reached out for feedback. Most people
didn't care about the issue, or were slightly inclined to have it be
uniform across platforms.
As Terry mentioned, I think that long-term uniformity will benefit
everybody down the line, and that is the way to go.
The most i
> In hearing from a couple people who teach python to beginners, this is a
> substantial hurdle - the first thing they need to do is to edit their
> environment to add these directories to the PATH.
This is something I never understood. On Windows, it's custom to launch
programs from the start men
Well, I really hope that the PEP regarding frozendict will be accepted.
Especially due to the fact that the required changes are small.
With the recent projects like clojure-py, blog posts like
http://goo.gl/bFB5x (Python becomes a platform), your pysandbox,
it became clear that people start eval
On 3/20/2012 10:52 AM, "Martin v. Löwis" wrote:
In hearing from a couple people who teach python to beginners, this is a
substantial hurdle - the first thing they need to do is to edit their
environment to add these directories to the PATH.
This is something I never understood. On Windows, it's
On Tue, Mar 20, 2012 at 10:52, "Martin v. Löwis" wrote:
>> In hearing from a couple people who teach python to beginners, this is a
>> substantial hurdle - the first thing they need to do is to edit their
>> environment to add these directories to the PATH.
>
> This is something I never understood
> 1. Run python from the start menu.
> - Import sys, fiddle with sys.path to add my module, import/run my
> module, do my tests. When you exit /hard error out, the python window
> disappears.
>
> 2. Double-click the .py file
> - Runs the file, but then disappears immediately (unless you put in
> s
On 3/20/2012 11:19 AM, "Martin v. Löwis" wrote:
No - there is an version #3a: 3.a) Get a shell and run the script CD
into the directory, then directly run foo.py, without prefixing it
with python.exe. This doesn't require any changes to the path, and is
shorter in usage than having the path spe
On 3/20/2012 12:02 PM, VanL wrote:
On 3/20/2012 10:52 AM, "Martin v. Löwis" wrote:
In hearing from a couple people who teach python to beginners, this is a
substantial hurdle - the first thing they need to do is to edit their
environment to add these directories to the PATH.
This is something I
On 3/20/2012 11:19 AM, "Martin v. Löwis" wrote:
No - there is an version #3a: 3.a) Get a shell and run the script CD
into the directory, then directly run foo.py, without prefixing it
with python.exe. This doesn't require any changes to the path, and is
shorter in usage than having the path sp
On 20 March 2012 14:08, Lindberg, Van wrote:
> On 3/20/2012 5:48 AM, Mark Hammond wrote:
>> While I'm still unclear on the actual benefits of this, Martin's
>> approach strikes a reasonable compromise so I withdraw my objections.
>
>
> Ok. I was out of town and so could not respond to most of the
When IDLE crashes, running it from a cmd window is the only way to
get a traceback to help diagnose the problem.
Certainly. In this case, there is no PATH issue, though: you have to CD
into the Python installation, anyway, to start IDLE - and there you have
python.exe in the current directory.
On 03/20/2012 12:19 PM, Paul Moore wrote:
> I also note that I'm assuming virtualenv will change to match whatever
> the Python version it's referencing does. I don't see how you can
> guarantee that, but if there are discrepancies between virtualenvs and
> installed Pythons, my level of objection
On 13 March 2012 20:43, VanL wrote:
> Following up on conversations at PyCon, I want to bring up one of my
> personal hobby horses for change in 3.3: Fix install layout on Windows, with
> a side order of making the PATH work better.
As this is being considered an 'incompatible change' on the bug
On 20 March 2012 14:27, VanL wrote:
> Germane to this discussion, I reached out for feedback. Most people didn't
> care about the issue, or were slightly inclined to have it be uniform across
> platforms.
>
> As Terry mentioned, I think that long-term uniformity will benefit everybody
> down the l
On 3/20/2012 1:50 PM, Merlijn van Deen wrote:
On 13 March 2012 20:43, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
As this is being con
On 3/20/2012 1:56 PM, Paul Moore wrote:
This is covered (better, IMO) by PEP 397 - Python Launcher for
Windows. Step 2, just run "py". If you prefer a particular version,
run "py -2" or "py -3" or "py -3.2".
Interesting. I haven't played around with that at all, so can't comment.
I will hav
On 3/20/2012 1:19 PM, Paul Moore wrote:
> Somewhat. I don't really object to #1, but mildly object to #2. I also
> note that the proposals round the Lib directory seem to have
> disappeared. I assume those have been dropped - they were the ones I
> did object to.
They are of secondary importance t
2012/3/20 larry.hastings :
> http://hg.python.org/cpython/rev/052779d34945
> changeset: 75842:052779d34945
> parent: 75839:1c0058991740
> user: Larry Hastings
> date: Tue Mar 20 20:06:16 2012 +
> summary:
> Issue #14328: Add keyword-only parameters to PyArg_ParseTupleAndK
On 20 March 2012 19:35, Lindberg, Van wrote:
> I would like to know if you would object to user lib installs matching
> the system install. I.e., would it cause problems with you if it were
> just 'lib' everywhere, with no 'lib/python{version}'? It sounded like
> adding the version directory was t
On 20 March 2012 19:22, VanL wrote:
> There are a number of casual users that probably only have one version
> installed, but every python user/dev on windows that I know has one python
> that they consider to be "python," and everything else needs to be launched
> with a suffix (e.g., python26.ex
On 3/20/2012 3:15 PM, Paul Moore wrote:
On 20 March 2012 19:35, Lindberg, Van wrote:
I would like to know if you would object to user lib installs matching
the system install. I.e., would it cause problems with you if it were
just 'lib' everywhere, with no 'lib/python{version}'? It sounded like
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 in
On 3/20/2012 3:31 PM, Paul Moore wrote:
> Serious question: Given a brand new PC, if you were installing Python
> 2.7, 3.2, 3.3a1, jython, and pypy, what would you do (beyond simply
> running 5 installers) to get your environment set up the way you want?
I install each python in its own directory:
On 21/03/2012 1:08 AM, Lindberg, Van wrote:
On 3/20/2012 5:48 AM, Mark Hammond wrote:
While I'm still unclear on the actual benefits of this, Martin's
approach strikes a reasonable compromise so I withdraw my objections.
Ok. I was out of town and so could not respond to most of the latest
dis
On 3/20/2012 4:49 PM, Mark Hammond wrote:
So I'm assuming that:
* The executable (and DLL) are moved to a "bin" directory in an
installed Python.
* distutils etc will change to install all "scripts" (or executables
generated from scripts) into that same directory. IOW, "Scripts"
would die.
*
On 20 March 2012 22:00, VanL wrote:
> On 3/20/2012 4:49 PM, Mark Hammond wrote:
>>
>> So I'm assuming that:
>> * The executable (and DLL) are moved to a "bin" directory in an installed
>> Python.
>> * distutils etc will change to install all "scripts" (or executables
>> generated from scripts) int
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
On 13 March 2012 20:43, VanL wrote:
Following up on conversations at PyCon, I want to bring up one of my
personal hobby horses for change in 3.3: Fix install layout on Windows, with
a side order of making the PATH work better.
As this is being co
Hi all,
recently I've grown a bit tired of seeing our default Sphinx theme,
especially as so many other projects use it. I decided to play around
with something "clean" this time, and this is the result:
http://www.python.org/~gbrandl/build/html/
The corresponding sandbox repo is at
http:/
Nice and clean, but looks too similar to newer Google properties...
Also I see that (like Google) you're falling for the fallacy of using
less contrast. From an accessibility perspective that's questionable
-- and I don't mean the legally blind, just people like myself whose
eyes are getting a bit
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond
wrote:
> On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
> > I asked a question about this on IRC, to which the response was that
> > there were two main reasons to install python in c:\pythonxy:
> >
> > 1 - issues due to spaces ('Program Files') or
On Tue, Mar 20, 2012 at 6:38 PM, Georg Brandl wrote:
> recently I've grown a bit tired of seeing our default Sphinx theme,
> especially as so many other projects use it.
I think regardless of the chosen style, giving the Python 3 docs a
different look and feel also has a psychological benefit tha
On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl wrote:
> Hi all,
>
> recently I've grown a bit tired of seeing our default Sphinx theme,
> especially as so many other projects use it. I decided to play around
> with something "clean" this time, and this is the result:
>
> http://www.python.o
On 21/03/2012 9:45 AM, R. David Murray wrote:
On Wed, 21 Mar 2012 09:09:38 +1100, Mark Hammond
wrote:
On 21/03/2012 5:50 AM, Merlijn van Deen wrote:
I asked a question about this on IRC, to which the response was that
there were two main reasons to install python in c:\pythonxy:
1 - issues d
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,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/20/2012 06:45 PM, Guido van Rossum wrote:
> Nice and clean, but looks too similar to newer Google properties...
> Also I see that (like Google) you're falling for the fallacy of using
> less contrast. From an accessibility perspective that's qu
Hi Georg,
On Tue, 20 Mar 2012 23:38:53 +0100
Georg Brandl wrote:
> Hi all,
>
> recently I've grown a bit tired of seeing our default Sphinx theme,
> especially as so many other projects use it. I decided to play around
> with something "clean" this time, and this is the result:
>
> http://w
On 20Mar2012 15:45, Guido van Rossum wrote:
| Nice and clean, but looks too similar to newer Google properties...
| Also I see that (like Google) you're falling for the fallacy of using
| less contrast. From an accessibility perspective that's questionable
| -- and I don't mean the legally blind,
On Mar 20, 2012, at 5:37 PM, Antoine Pitrou wrote:
> Georg Brandl wrote:
>> Hi all,
>>
>> recently I've grown a bit tired of seeing our default Sphinx theme,
>> especially as so many other projects use it. I decided to play around
>> with something "clean" this time, and this is the result:
>>
On 3/20/2012 6:38 PM, Georg Brandl wrote:
The current green on the front page is too heavy. Otherwise I prefer the
old. I like the color on the index chart of the builtin-functions page.
You un-bolded most (not all) of the entries and then are definitely too
thin now. You unbolded the blue els
On Tuesday, March 20, 2012 at 5:07 PM, Paul Moore wrote:
> It's worth remembering Éric's point - distutils is frozen and changes
> are in theory not allowed. This part of the proposal is not possible
> without an exception to that ruling. Personally, I don't see how
> making this change could be a
On 3/20/2012 6:38 PM, Georg Brandl wrote:
Let me know what you think, or play around and send some improvements.
(The collapsible sidebar is not adapted to it yet, but will definitely
be integrated before I consider applying a new theme to the real docs.)
Not to add to the chorus of tweakers, but
Hi,
Le 20/03/2012 21:40, VanL a écrit :
> On Tuesday, March 20, 2012 at 5:07 PM, Paul Moore wrote:
>> It's worth remembering Éric's point - distutils is frozen and changes
>> are in theory not allowed. This part of the proposal is not possible
>> without an exception to that ruling. Personally, I
R. David Murray wrote:
My understanding, though, is that Python
does make a distinction between a system install of Python and
a per-user one, so I don't think your objection really applies.
Seems to me that for Python at least, the important distinction
is not so much where the files are place
On 20.03.2012 23:45, Guido van Rossum wrote:
> Nice and clean, but looks too similar to newer Google properties...
> Also I see that (like Google) you're falling for the fallacy of using
> less contrast. From an accessibility perspective that's questionable
> -- and I don't mean the legally blind,
On 21.03.2012 00:17, R. David Murray wrote:
> On Tue, 20 Mar 2012 23:38:53 +0100, Georg Brandl wrote:
>> Hi all,
>>
>> recently I've grown a bit tired of seeing our default Sphinx theme,
>> especially as so many other projects use it. I decided to play around
>> with something "clean" this time,
On 21.03.2012 01:57, Raymond Hettinger wrote:
>
> On Mar 20, 2012, at 5:37 PM, Antoine Pitrou wrote:
>
>> Georg Brandl mailto:g.bra...@gmx.net>> wrote:
>>> Hi all,
>>>
>>> recently I've grown a bit tired of seeing our default Sphinx theme,
>>> especially as so many other projects use it. I decid
58 matches
Mail list logo
