The What's New document also starts with a long list of PEPs.
This seems to be the standard format as What's New for 3.2 follows the
same layout.
Perhaps adding an overview or highlights at the start would be a good
idea.
You seem to assume that Python users are not able to grasp long itemized
Martin v. Löwis wrote:
The What's New document also starts with a long list of PEPs.
This seems to be the standard format as What's New for 3.2 follows the
same layout.
Perhaps adding an overview or highlights at the start would be a good
idea.
You seem to assume that Python users are not able
Any such summary prose will be written by the What's New author
(Raymond Hettinger for the 3.x series). Such text definitely *won't*
be written until after feature freeze (which occurs with the first
beta, currently planned for late June).
Until that time, the draft What's New is primarily rough n
On 05/07/2012 11:00 AM, Mark Shannon wrote:
> Martin v. Löwis wrote:
>>> The What's New document also starts with a long list of PEPs.
>>> This seems to be the standard format as What's New for 3.2 follows the
>>> same layout.
>>>
>>> Perhaps adding an overview or highlights at the start would be a
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right solution to me. PEP 405 specifies that bin/python3
exists, but not that it is the actual
A while back I pointed out that there's no easy PEP 3115 compliant way
to dynamically create a class (finding the right metaclass, calling
__prepare__, etc).
I initially proposed providing this as operator.build_class, and
Daniel Urban created a patch that implements that API
(http://bugs.python.o
On 7 May, 2012, at 11:52, Martin v. Löwis wrote:
>> 3) Symlink the interpreter rather than copying. I include this here for
>> the sake of completeness, but it's already been rejected due to
>> significant problems on older Windows' and OS X.
>
> That sounds the right solution to me. PEP 405 spe
On Mon, May 7, 2012 at 12:08 PM, victor.stinner
wrote:
> http://hg.python.org/cpython/rev/ab500b297900
> changeset: 76821:ab500b297900
> user: Victor Stinner
> date: Mon May 07 13:02:44 2012 +0200
> summary:
> Issue #14716: Change integer overflow check in unicode_writer_prepare(
On 05/07/2012 01:10 PM, Nick Coghlan wrote:
> A while back I pointed out that there's no easy PEP 3115 compliant way
> to dynamically create a class (finding the right metaclass, calling
> __prepare__, etc).
>
> I initially proposed providing this as operator.build_class, and
> Daniel Urban create
2012/5/7 Nick Coghlan :
> A while back I pointed out that there's no easy PEP 3115 compliant way
> to dynamically create a class (finding the right metaclass, calling
> __prepare__, etc).
>
> I initially proposed providing this as operator.build_class, and
> Daniel Urban created a patch that implem
On Mon, May 7, 2012 at 12:35 PM, Mark Dickinson wrote:
> will almost always be one less than a power of 2 and powers of 2 are
> always congruent to 1, 2 or 4 modulo 5, we're safe.
Bah. That should have read "1, 2, 3 or 4 modulo 5".
___
Python-Dev maili
On Mon, May 7, 2012 at 9:54 PM, Georg Brandl wrote:
> As for build_class: at the moment the types module really only has types,
> and to add build_class there is just about as weird as in operator IMO.
Oh no, types is definitely less weird - at least it's related to the
type system, whereas the o
On 05/07/2012 02:15 PM, Nick Coghlan wrote:
> On Mon, May 7, 2012 at 9:54 PM, Georg Brandl wrote:
>> As for build_class: at the moment the types module really only has types,
>> and to add build_class there is just about as weird as in operator IMO.
>
> Oh no, types is definitely less weird - at
On 05/07/2012 02:15 PM, Nick Coghlan wrote:
Benjamin's suggestion of a class method on type may be a good one,
though. Then the invocation (using all arguments) would be:
mcl.build_class(name, bases, keywords, exec_body)
Works for me, so unless someone else can see a problem I've missed,
we'
On 05/07/2012 04:26 AM, Ronald Oussoren wrote:
On 7 May, 2012, at 11:52, Martin v. Löwis wrote:
3) Symlink the interpreter rather than copying. I include this
here for the sake of completeness, but it's already been rejected
due to significant problems on older Windows' and OS X.
That sounds t
07.05.12 14:35, Mark Dickinson написав(ла):
Hmm. Very clever, but it's not obvious that that overflow check is
mathematically sound.
My fault. Overflow will be at PY_SSIZE_T_MAX congruent to 4 modulo 5
(which is impossible if PY_SSIZE_T_MAX is one less than a power of 2).
Mathematically str
07.05.12 18:48, Serhiy Storchaka написав(ла):
My fault.
However, it's not my fault. I suggested `newlen < (PY_SSIZE_T_MAX -
PY_SSIZE_T_MAX / 5)` and not `newlen <= (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX
/ 5)`. In this case, there is no overflow.
___
Pyt
On 05/07/2012 03:52 AM, "Martin v. Löwis" wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right solution to me. PEP 405 specifies that
On Mon, 7 May 2012 12:35:27 +0100
Mark Dickinson wrote:
>
> Hmm. Very clever, but it's not obvious that that overflow check is
> mathematically sound. As it turns out, the maths works provided that
> PY_SSIZE_T_MAX isn't congruent to 4 modulo 5; since PY_SSIZE_T_MAX
> will almost always be one
Hello,
> http://www.python.org/psf/contrib/
I took care of the formalities.
I am not sure how to proceed further. Would python-dev want me to draft a PEP?
Regards,
--stefan
PS: Personally, I am not a 100pct convinced that having a PEP is a
good thing in this case, as it makes a perfectly trans
Hello,
I guess a long time ago, threading support in operating systems wasn't
very widespread, but these days all our supported platforms have it.
Is it still useful for production purposes to configure
--without-threads? Do people use this option for something else than
curiosity of mind?
Regar
On 05/07/2012 09:23 PM, stefan brunthaler wrote:
> Hello,
>
>> http://www.python.org/psf/contrib/
>
> I took care of the formalities.
>
> I am not sure how to proceed further. Would python-dev want me to draft a PEP?
>
> Regards,
> --stefan
>
> PS: Personally, I am not a 100pct convinced that
I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled
and installed Python 3.3.0 alpha 3 using "altinstall". Debian wheezy comes
with python3.2 (and 2.6 and 2.7). I installed the Debian package
python3-bs4 (BeautifulSoup). I also downloaded a "clone" developmental
copy of 3.
The bin/python3 executable in a framework is a small stub that
execv's the real interpreter that is stuffed in a Python.app bundle
inside the Python framework. That's done to ensure that GUI code can
work from the command-line, Apple's GUI framework refuse to work when
the executable is not in an
I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled
and installed Python 3.3.0 alpha 3 using "altinstall". Debian wheezy comes
with python3.2 (and 2.6 and 2.7). I installed the Debian package
python3-bs4 (BeautifulSoup4 for Python3). I also downloaded a "clone"
development
On 07.05.2012 18:35, Carl Meyer wrote:
On 05/07/2012 03:52 AM, "Martin v. Löwis" wrote:
3) Symlink the interpreter rather than copying. I include this here for
the sake of completeness, but it's already been rejected due to
significant problems on older Windows' and OS X.
That sounds the right
On 07.05.2012 21:23, stefan brunthaler wrote:
Hello,
http://www.python.org/psf/contrib/
I took care of the formalities.
I am not sure how to proceed further. Would python-dev want me to draft a PEP?
Submit a patch to the bug tracker, against default's head.
Regards,
Martin
___
Hello,
On Mon, 07 May 2012 16:42:50 -0400
"Edward C. Jones" wrote:
> I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled
> and installed Python 3.3.0 alpha 3 using "altinstall". Debian wheezy comes
> with python3.2 (and 2.6 and 2.7). I installed the Debian package
> pytho
On Mon, May 07, 2012 at 04:42:50PM -0400, "Edward C. Jones"
wrote:
> I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled
> and installed Python 3.3.0 alpha 3 using "altinstall". Debian wheezy comes
> with python3.2 (and 2.6 and 2.7). I installed the Debian package
> python
Ronald Oussoren mac.com> writes:
> Because of this trick pyvenv won't know which executable the user actually
> called and hence cannot find the pyvenv configuration file (which is next to
> the stub executable).
Ah, but the stub has been changed to set an environment variable,
__PYTHONV_LAUNCHE
On May 07, 2012, at 04:42 PM, Edward C. Jones wrote:
>I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled
>and installed Python 3.3.0 alpha 3 using "altinstall". Debian wheezy comes
>with python3.2 (and 2.6 and 2.7). I installed the Debian package
>python3-bs4 (BeautifulSou
> I think you'll find that we don't keep a lot of things secret about CPython
> and its implementation.
>
Yeah, I agree that this is in principal a good thing and what makes
CPython ideally suited for research. However, my optimizations make
use of unused opcodes, which might be used in the future
> However, it's not my fault. I suggested `newlen < (PY_SSIZE_T_MAX -
> PY_SSIZE_T_MAX / 5)` and not `newlen <= (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX /
> 5)`. In this case, there is no overflow.
Oh. I didn't understand why you replaced <= by <, and so I used <=.
Anyway, I reverted the change for all r
On 7 May 2012 21:55, "Martin v. Löwis" wrote:
>> This sounds to me like a level of complexity unwarranted by the severity
>> of the problem, especially when considering the additional burden it
>> imposes on alternative Python implementations.
>
>
> OTOH, it *significantly* reduces the burden on P
> I guess a long time ago, threading support in operating systems wasn't
> very widespread, but these days all our supported platforms have it.
> Is it still useful for production purposes to configure
> --without-threads? Do people use this option for something else than
> curiosity of mind?
At w
Nick Coghlan wrote:
Instead, I'm now thinking we should add a _types C extension module
and expose the new function as types.build_class(). I don't want to
add an entire new module just for this feature, and the types module
seems like an appropriate home for it.
Dunno. Currently the only thin
Mark Dickinson wrote:
Is the gain from this kind of micro-optimization really worth the cost
of replacing obviously correct code with code whose correctness needs
several minutes of thought?
The original code isn't all that obviously correct to me either.
I would need convincing that the arith
For those suggesting the operator module is actually a good choice, there's
no way to add this function without making major changes to the module
description (go read it - I only realised the problem when I went to add
the docs). It's a bad fit (*much* worse than types or a class method)
--
Sent
On Mon, May 7, 2012 at 6:15 AM, Nick Coghlan wrote:
> On Mon, May 7, 2012 at 9:54 PM, Georg Brandl wrote:
>> As for build_class: at the moment the types module really only has types,
>> and to add build_class there is just about as weird as in operator IMO.
>
> Oh no, types is definitely less wei
On Mon, May 7, 2012 at 11:42 PM, Hrvoje Niksic wrote:
> On 05/07/2012 02:15 PM, Nick Coghlan wrote:
>>
>> Benjamin's suggestion of a class method on type may be a good one,
>> though. Then the invocation (using all arguments) would be:
>>
>> mcl.build_class(name, bases, keywords, exec_body)
>>
>
Python Freakz ..,
Anyone of you interested to write a series of article regarding the great
python language ?..The series must be including a brief of python history,
applications , advantages, related topics and tutorials etc ...I hope it
will be a great experience for you to share,learn
Python Freakz ..,
Anyone of you interested to write a series of article regarding the great
python language ?..The series must be including a brief of python history,
applications , advantages, related topics and tutorials etc ...I hope it
will be a great experience for you to share,learn
On Mon, May 7, 2012 at 9:49 PM, Antoine Pitrou wrote:
> I guess a long time ago, threading support in operating systems wasn't
> very widespread, but these days all our supported platforms have it.
> Is it still useful for production purposes to configure
> --without-threads? Do people use this op
43 matches
Mail list logo
