On 19/01/2012 17:46, Ethan Furman wrote:
Guido van Rossum wrote:
> We should not encourage people to write code that works with a certain
> bugfix release but not with the previous bugfix release of the same
> feature release.
Then what's the point of a bug-fix release? If 3.2.1 had broken
thr
to be that way, but it's fine by me as
>> both ways work fine.
>
> I am not sure, that was just try and worked for me, with first option
> suggested by you was throwing same compile error then I tried with this that
> worked :)
The problems compiling Python 3 on th
On 22 Jan 2012, at 17:43, Łukasz Langa wrote:
> Wiadomość napisana przez Michael Foord w dniu 22 sty 2012, o godz. 14:14:
>
>> ./configure CC=gcc-4.2 --prefix=/dev/null --with-pydebug
>
> Why the phony prefix?
Heh, it's what I've always done - I think copied
On 27/01/2012 14:37, Philippe Fremy wrote:
Hi,
A small comment from a user perspective.
Since a package in preview is strongly linked to a given version of
Python, any program taking advantage of it becomes strongly specific to
a given version of Python.
Such programs will of course break for
On 27/01/2012 15:09, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 15:21:33 +0200
Eli Bendersky wrote:
Following an earlier discussion on python-ideas [1], we would like to
propose the following PEP for review. Discussion is welcome. The PEP
can also be viewed in HTML form at
http://www.python.org/
On 27/01/2012 15:34, Benjamin Peterson wrote:
2012/1/27 Eli Bendersky:
Criteria for "graduation"
-
I think you also need "Criteria for being placed in __preview__". Do
we just toss everything someone suggests in?
And given that permanently deleting something from __pre
On 27/01/2012 15:35, Matt Joiner wrote:
A more normal incantation, as is often the way for packages that became
parts of the standard library after first being a third party library
(sometimes under a different name, e.g. simplejson -> json):
try:
from __preview__ import thing
except Import
view__ adds nothing to the
process.
Sure. __preview__ is for things that *need* previewing.
All the best,
Michael Foord
Even when there are candidates for inclusion with relatively stable
APIs, like regex, we should *assume* that there will be API
differences between __preview__.regex and
On 27/01/2012 20:48, Steven D'Aprano wrote:
Eli Bendersky wrote:
try:
from __preview__ import thing
except ImportError:
import thing
So no need to target a very specific version of Python.
Yep, this is what I had in mind. And it appeared too trivial to place
it in the PEP.
Trivial a
On 28/01/2012 13:04, Paul Moore wrote:
On 28 January 2012 09:18, Nick Coghlan wrote:
It's basically us saying to Python users "We're explicitly flagging
this PyPI module for inclusion in the next major Python release. We've
integrated it into our build process, test suite and binary releases,
On 27/01/2012 22:54, Barry Warsaw wrote:
On Jan 27, 2012, at 10:48 PM, Antoine Pitrou wrote:
On Fri, 27 Jan 2012 16:10:51 -0500
Barry Warsaw wrote:
I'm -1 on this as well. It just feels like the completely wrong way to
stabilize an API, and I think despite the caveats that are explicit in
__
On 28/01/2012 05:09, Scott Dial wrote:
On 1/27/2012 8:48 PM, Barry Warsaw wrote:
The thinking goes like this: if you would normally use an __preview__ module
because you can't get approval to download some random package from PyPI, well
then your distro probably could or should provide it, so ge
ard
library is distributed or versioned.
A separate proposal about standard library versioning has been floated
but is *much* more controversial and therefore much less likely to
happen. So I wouldn't hold your breath on it...
All the best,
Michael Foord
___
On 28/01/2012 04:44, Stephen J. Turnbull wrote:
Michael Foord writes:
> >> Assuming the module is then promoted to the the standard library
proper in
> >> release ``3.X+1``, it will be moved to a permanent location in the
library::
> >>
e for
instances, which may be overridden by an instance attribute on *some*
instances.
All the best,
Michael Foord
Chris
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you giv
On 08/02/2012 15:16, Mark Shannon wrote:
Hi,
Version 2 is now available.
Version 2 makes as few changes to tunable constants as possible, and
generally does not change iteration order (so repr() is unchanged).
All tests pass (the only changes to tests are for sys.getsizeof() ).
Repository: h
Hey folks,
When we do security only releases of Python we regularly get emails to
webmas...@python.org asking where to find binary builds. If you want to find
the most recent binary builds of Python 2.5 & 2.6, it used to involve clicking
through quite a few links.
I've added links to the lates
On 26 Feb 2012, at 17:45, Antoine Pitrou wrote:
>
> Hi,
>
> On Sat, 25 Feb 2012 20:23:39 +
> Armin Ronacher wrote:
>>
>> I just uploaded PEP 414 which proposes am optional 'u' prefix for string
>> literals for Python 3.
>>
>> You can read the PEP online: http://www.python.org/dev/peps/pe
Hello all,
At the Python Language Summit adding the "mock" library to the Python Standard
Library was discussed and agreed. Here is a very brief PEP covering the
decision and rationale.
All the best,
Michael Foord
PEP: 417
Title: Including mock in the Standard Library
Version:
s a context manager). Beyond
that the api is stable. A bunch of Python 2 compatibility code can also be
removed in the standard library version.
All the best,
Michael Foord
> Good luck!
>
> --Guido
>
> On Mon, Mar 12, 2012 at 4:01 PM, Gregory P. Smith wrote:
>&g
thon2 'unicode'
> python3 'bytes' -> python2 '__builtins__.bytes object'
>
It does seem unfortunate that by default it is impossible for a developer to
"do the right thing" as regards pickling / unpickling here. Binary data on
Python 2 being unpickl
On 13 Mar 2012, at 16:57, Victor Stinner wrote:
> Hi,
>
> I added two functions to the time module in Python 3.3: wallclock()
> and monotonic(). I'm unable to explain the difference between these
> two functions, even if I wrote them :-) wallclock() is suppose to be
> more accurate than time() b
or pointing it out.
I'm maintaining a "clean" (no Python 2 compatibility code) version in the
standard library. I'll be maintaining mock, so I'd like to be assigned any
issues on it and at least talked to before changes are made. I am maintaining a
backport still, but th
On 14 Mar 2012, at 12:33, Georg Brandl wrote:
> On 14.03.2012 20:25, michael.foord wrote:
>> http://hg.python.org/cpython/rev/2fda048ee32a
>> changeset: 75632:2fda048ee32a
>> user:Michael Foord
>> date:Wed Mar 14 12:24:34 2012 -0700
>&
On 14 Mar 2012, at 13:46, Terry Reedy wrote:
> On 3/14/2012 4:22 PM, Michael Foord wrote:
>>
>> On 14 Mar 2012, at 13:08, Terry Reedy wrote:
>>
>>> On 3/14/2012 3:25 PM, michael.foord wrote:
>>>> +# mock.py +# Test tools for mocking and patching
On 17 Mar 2012, at 08:49, Georg Brandl wrote:
> On 03/15/2012 01:17 AM, victor.stinner wrote:
>> http://hg.python.org/cpython/rev/27441e0d6a75
>> changeset: 75672:27441e0d6a75
>> user:Victor Stinner
>> date:Thu Mar 15 01:17:09 2012 +0100
>> summary:
>> Issue #10278: Add an opt
On 17 Mar 2012, at 15:04, Georg Brandl wrote:
> On 03/17/2012 09:47 PM, Michael Foord wrote:
>>
>> On 17 Mar 2012, at 08:49, Georg Brandl wrote:
>>
>>> On 03/15/2012 01:17 AM, victor.stinner wrote:
>>>> http://hg.python.org/cpython/rev/27441e0d6a
On 16 Mar 2012, at 11:54, Nick Coghlan wrote:
> On Thu, Mar 15, 2012 at 6:27 AM, Michael Foord
> wrote:
>> On the topic of docs mock documentation is about eight pages long. My
>> intention was to strip this down to just the api documentation, along with a
>> lin
On 26 Mar 2012, at 08:11, Georg Brandl wrote:
> On 26.03.2012 00:13, michael.foord wrote:
>> http://hg.python.org/cpython/rev/adc1fc2dc872
>> changeset: 75938:adc1fc2dc872
>> user:Michael Foord
>> date:Sun Mar 25 23:12:55 2012 +0100
>>
On 27/03/2012 18:45, Victor Stinner wrote:
[snip...]
Straying from that is only going to create confusion. Besides that, the
one use case for "time.steady()" that you give (benchmarking) is better
served by a clock that follows the C++0x definition.
I added a time.hires() clock to the PEP for t
On 31 Mar 2012, at 07:32, Lennart Regebro wrote:
> On Fri, Mar 30, 2012 at 12:38, Serhiy Storchaka wrote:
>> I don't understand why Python may not include the pytz. The Olson tz
>> database is not part of pytz.
>
> Yes it is.
>
>> Python can depend on a system tz database
>
> That works on Un
On 2 May 2012, at 16:55, Terry Reedy wrote:
> On 5/2/2012 10:16 AM, Carl Meyer wrote:
>> Hi all,
>>
>> Are the download pages for older Python versions supposed to be kept up
>> to date at all? I just noticed that the 2.4.6 download page
>> (http://www.python.org/download/releases/2.4.6/) says t
On 2 May 2012, at 18:06, Ezio Melotti wrote:
> On 02/05/2012 19.33, Michael Foord wrote:
>> On 2 May 2012, at 16:55, Terry Reedy wrote:
>>> I would send the above to webmas...@python.org (should be at the bottom of
>>> pages). We develop CPython but do not directly
On 4 May 2012, at 09:44, Vinay Sajip wrote:
> IIUC, the program name of the Python executable is set to whatever argv[0] is.
> Is there a reason for this, rather than using one of the various OS-specific
> APIs [1] for getting the name of the running executable? The reason I ask is
> that in a vi
On 4 Jun 2012, at 16:10, Barry Warsaw wrote:
> [snip...]
>>> + However, for a structured record type use
>>> :func:`~collections.namedtuple`
>>>
>>
>> What's with the ~?
>
> I'm not sure, but it seems to result in a cross-reference, and I see tildes
> used elsewhere, so I guess it's some reS
On 5 Jun 2012, at 09:34, Mark Shannon wrote:
> Steven D'Aprano wrote:
>> On Tue, Jun 05, 2012 at 10:20:58AM +0300, Eli Bendersky wrote:
>>> Still, instance of type()" is a bit too cryptic for mere mortals, IMHO.
>> I think that if somebody finds "instance of type" too cryptic, they won't
>> have
On 5 Jun 2012, at 08:53, Nick Coghlan wrote:
> [snip...]
>
> Now, one minor annoyance with current class decorators is that they're
> *not* inherited. This is sometimes what you want, but sometimes you
> would prefer to automatically decorate all subclasses as well.
> Currently, that means writi
On 6 Jun 2012, at 18:28, Yury Selivanov wrote:
> On 2012-06-06, at 1:13 PM, Alexandre Zani wrote:
>> A question regarding the name. I have often seen the following pattern
>> in decorators:
>>
>> def decor(f):
>> def some_func(a,b):
>> do_stuff using f
>> some_func.__name__ = f.__name_
On 17 Jul 2012, at 23:04, mar...@v.loewis.de wrote:
>> [snip...]
>
>> I would like to use a JIT to generate specialized functions for a
>> combinaison of arguments types.
>
> I think history has moved past specializing JITs. Tracing JITs are the
> status quo; they provide specialization as a si
On 20 Jul 2012, at 17:50, Maciej Fijalkowski wrote:
> On Fri, Jul 20, 2012 at 2:55 PM, Michael Foord
> wrote:
>
> On 17 Jul 2012, at 23:04, mar...@v.loewis.de wrote:
>
> >> [snip...]
> >
> >> I would like to use a JIT to generate specialized functi
On 23 Jul 2012, at 19:49, Serhiy Storchaka wrote:
> On 23.07.12 19:38, Jesus Cea wrote:
>> The problem is that if we do ">=", then an unpatched python
>> interpreter could pass the test too. So we are not actually testing
>> the feature.
>>
>> If the repeat counters are going to be optimized, th
On 24 Jul 2012, at 10:30, Terry Reedy wrote:
> On 7/24/2012 12:44 AM, anatoly techtonik wrote:
>
>> Python 3 check explicitly tells the reader that 2to3 should only be
>> used in Python 3. Otherwise everybody need to guess when this *_2to3
>> tools are triggered. As for me, I see no technical li
On 24 Jul 2012, at 11:52, Devin Jeanpierre wrote:
> On Tue, Jul 24, 2012 at 6:07 AM, Michael Foord
> wrote:
>>> This is not an ideal world and 2to3 is not good enough to convert files
>>> without further intervention and testing.
>>
>> It is if you design
On 9 Nov 2012, at 09:57, Chris Withers wrote:
> Hi All,
>
> I wanted to run the unit tests before checking in the patch for
> http://bugs.python.org/issue16441, even though it's a trivial change, so I
> was trying to follow the instructions at:
>
> http://docs.python.org/devguide/
>
> I'm o
There's a problem with the instructions for using Active TCL with Python for
the Mac.
Michael
Begin forwarded message:
> From: "Dr. Anthony G. Francis, Jr."
> Subject: Broken links on
> http://www.python.org/download/mac/tcltk/#activetcl-8-5-11
> Date: 19 December 2012 22:08:02 GMT
> To: web
Hey folks,
Likely the wrong place to report this, but I couldn't work out the best place
and figured this is only as bad as anywhere else.
A user has reported to webmaster that hgweb is misconfigured (or at least the
server configuration is interfering with hgweb).
The symptom is that this url
ferent to the google link feature, which only shows links to a
specific URL I believe.)
http://www.alltheweb.com/search?cat=web&cs=utf8&q=link%3Adocs.python.org&rys=0&itag=crv&_sb_lang=pref
It's where I link to as well. Be a shame to lose it. ;-)
Michael Foord
> On
es/decodes that happen in Python. Life is confusing enough
already.
Michael Foord
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Guido van Rossum wrote:
> On 2/13/06, Michael Foord <[EMAIL PROTECTED]> wrote:
>
>> Phillip J. Eby wrote:
>> [snip..]
>>
>>> In fact, the 'encoding' argument seems useless in the case of str objects,
>>> and it seems i
also the following cookbook recipe that uses an heuristic to
guess encoding :
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/163743
XML, HTML, or other text streams may also contain additional information
about their encoding - which be unreliable. :-)
All the best,
Micha
r so when I
> feel like it and have them submitted to buildbot?
>
>
Has a machine been volunteered ?
I have a spare machine and an always on connection. Would the 'right'
development tools be needed ? (In the case of Microsoft they are a touch
expensive I believe.)
All the
Martin v. Löwis wrote:
> Michael Foord wrote:
>
>> Has a machine been volunteered ?
>>
>
> Not yet.
>
>
>> I have a spare machine and an always on connection. Would the 'right'
>> development tools be needed ? (In the case o
ery rare
and *would* be interested in seeing real code that does break.
Especially if that code cannot be trivially rewritten to use the first
example.
All the best,
Michael Foord
>
> Analysis Script
>
> from collections import deque
> from UserList import UserList
>
ws 98. But I guess if noone is
volunteering to maintain the code...
Michael Foord
> Georg
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubs
Hello all,
I'm working on a parser for part of the Python language (expressions but
not statements basically). I'm using PLY to generate the parser and it's
mostly done.
I've hit on what looks like a fundamental ambiguity in the Python
grammar which is difficult to get round with PLY; and I'm won
Hello all,
I'm working on a parser for part of the Python language (expressions but
not statements basically). I'm using PLY to generate the parser and it's
mostly done.
I've hit on what looks like a fundamental ambiguity in the Python
grammar which is difficult to get round with PLY; and I'm
expression_list there)
reflects the current state of the parser.
First of all the grammar in SVN also has expression_list there *and* the
following does successfully parse to an ast (but fails when you compile
the ast) :
[x for x + 1 in y]
All the best,
Michael Foord
> On 4/24/
in ?
print parser.compileast(ast)
SyntaxError: can't assign to literal
The syntax error is thrown at the compile stage, not the parse stage.
Having list_for being defined in terms of something like varlist makes
more sense, but isn't how the grammar is done currently.
Michael
tion); but the current
> approach allows more code sharing in the code generator.
>
> I suggest you go ahead and write the second form for your own parser.
> Coming up with the correct rules for varlist is not hard.
>
>
We've already done that, I was just checking there was
a good rule of thumb (especially for a tutorial) was :
Either define ``__cmp__`` *or*
define the rich comparison operators.
Doing both is a recipe for confusion.
Michael Foord
> A bientot,
>
> Armin.
> ___
> Python-Dev mailing list
>
I will probably need to refer
to the following pages :
http://docs.python.org/ref/sequence-types.html
http://docs.python.org/lib/typesmapping.html
http://docs.python.org/ref/customization.html
Michael Foord
> (Or are the two goals --
ack and
``repr(expression)`` is clearer. If backticks were documented as a
hackish shortcut for repr then great. :-)
Michael Foord
> http://docs.python.org/ref/string-conversions.html
>
> any suggestions for a better term ? should backticks be deprecated,
>
hange, the error messages that report the wrong line can be
very confusing.
Michael Foord
>
> Please post your patches to SourceForge, then post links back to the
> list.
>
___
Python-Dev mailing list
Python-Dev@python.org
http://m
ls are not easily available.
>
> Does anybody find this idea interesting?
> Does anybody think it could go into stdlib before the feature freeze for 2.5?
>
>
+1
Michael Foord
> The module consists of only one file. It imports only sys, zlib,
> struct (maybe re for testing).
>
-so" rather
> than the alias. I don't sign my email "BDFL" either. :-) Since there
> are many Michaels, signing just "Michael" doesn't really help. I'm too
> old fogey to get used to using IRC handles to ref
Guido van Rossum wrote:
>
> On 1/30/06, Michael Foord <[EMAIL PROTECTED]> wrote:
>
>> But like it or not, configuration files are often used to store data
>> about what a program does - not just the UI options. Storing this in a
>> human readable and edit
Guido van Rossum wrote:
> On 1/30/06, Michael Foord <[EMAIL PROTECTED]> wrote:
>
>> I have a feeling that for many complex applications the developer is the
>> user. Agreed that giving complex configuration data along with program
>> data to the end-user is not
Paul Moore wrote:
> On 1/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>> Aha. I am beginning to understand. When people say "ConfigParser is
>> hopeless" they mean ".INI files are hopeless". I happen to disagree.
>> (There's also a meme that says that every aspect of an app should be
>>
t;
>
This one however does, and if it does what it says on the box - is
definitely worth accepting.
All the best,
Michael Foord
http://www.voidspace.org.uk/python/index.shtml
> =Tony.Meyer
> ___
> Python-Dev mailing list
> Python
1001 - 1069 of 1069 matches
Mail list logo
