Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 3

[Martin v. Löwis]

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 
lists including numbers. I think readers are very capable

of filtering this kind of information.

As for presenting highlights: the PEPs *are* the highlights of a new 
release. The numerous bug fixes and minor enhancements don't get listed

at all.

Regards,
Martin
___
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

Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 3

[Mark Shannon]

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 to grasp long itemized 
lists including numbers. I think readers are very capable

of filtering this kind of information.


Just because readers are capable of filtering a long list of PEPs in an 
arbitrary order does not mean that they should have to.
Many readers will just skim the list, but would probably read a summary 
in full.




As for presenting highlights: the PEPs *are* the highlights of a new 
release. The numerous bug fixes and minor enhancements don't get listed

at all.


But PEPs can have very different purposes.
It would be useful to summarize the language changes (with links to the 
relevant PEPs) separately to library extensions and optimizations.


If the reader is interested in new features, then information about
optimisations are just clutter. And vice-versa.

Cheers,
Mark.
___
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

Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 3

[Nick Coghlan]

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 notes written
by everyone else for Raymond's benefit (and, of course, for the
benefit of anyone checking out the alpha and beta releases).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] [RELEASED] Python 3.3.0 alpha 3

[Georg Brandl]

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 good
>>> idea.
>> 
>> You seem to assume that Python users are not able to grasp long itemized 
>> lists including numbers. I think readers are very capable
>> of filtering this kind of information.
> 
> Just because readers are capable of filtering a long list of PEPs in an 
> arbitrary order does not mean that they should have to.
> Many readers will just skim the list, but would probably read a summary 
> in full.
> 
>> 
>> As for presenting highlights: the PEPs *are* the highlights of a new 
>> release. The numerous bug fixes and minor enhancements don't get listed
>> at all.
> 
> But PEPs can have very different purposes.
> It would be useful to summarize the language changes (with links to the 
> relevant PEPs) separately to library extensions and optimizations.
> 
> If the reader is interested in new features, then information about
> optimisations are just clutter. And vice-versa.

Sorry, I think that's tough luck then.  The list isn't nearly long enough
to warrant splitting up.  The announcement should stay compact.  And as Nick
said, the "What's New" will be there for those who want a longer overview
by topics.

Georg

___
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

Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades

[Martin v. Löwis]

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 Python interpreter binary that is
normally used. For each target system, a solution should be defined that
allows in-place updates of Python that also update all venvs automatically.

For example, for Windows, it would be sufficient to just have the 
executable in bin/, as the update will only affect pythonXY.dll.

That executable may be different from the regular python.exe, and
it might be necessary that it locates its Python installation first.
For Unix, symlinks sound fine. Not sure what the issue with OS X is.

Regards,
Martin

___
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

[Python-Dev] Adding types.build_class for 3.3

[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 implements that API
(http://bugs.python.org/issue14588).

However, in starting to write the documentation for the new API, I
realised that the operator module really isn't the right home for the
functionality.

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.

Thoughts?

Regards,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades

[Ronald Oussoren]

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 specifies that bin/python3
> exists, but not that it is the actual Python interpreter binary that is
> normally used. For each target system, a solution should be defined that
> allows in-place updates of Python that also update all venvs automatically.
> 
> For example, for Windows, it would be sufficient to just have the executable 
> in bin/, as the update will only affect pythonXY.dll.
> That executable may be different from the regular python.exe, and
> it might be necessary that it locates its Python installation first.
> For Unix, symlinks sound fine. Not sure what the issue with OS X is.

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 application bundle. 

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).

Ronald

smime.p7s
Description: S/MIME cryptographic signature
___
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

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

[Mark Dickinson]

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()
> to compute the limit at compile time instead of runtime. Patch writen by 
> Serhiy
> Storchaka.

>     if (newlen > PyUnicode_GET_LENGTH(writer->buffer)) {
> -        /* overallocate 25% to limit the number of resize */
> -        if (newlen <= (PY_SSIZE_T_MAX - newlen / 4))
> +        /* Overallocate 25% to limit the number of resize.
> +           Check for integer overflow:
> +           (newlen + newlen / 4) <= PY_SSIZE_T_MAX */
> +        if (newlen <= (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX / 5))
>             newlen += newlen / 4;

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 less than a power of 2 and powers of 2 are
always congruent to 1, 2 or 4 modulo 5, we're safe.

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?

Mark
___
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

Re: [Python-Dev] Adding types.build_class for 3.3

[Georg Brandl]

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 created a patch that implements that API
> (http://bugs.python.org/issue14588).
> 
> However, in starting to write the documentation for the new API, I
> realised that the operator module really isn't the right home for the
> functionality.
> 
> 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.

Yay for being able to get rid of the stupidities the types module goes
through to get at its types (i.e. if we start having a C module, the
whole contents can go there.)

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.

cheers,
Georg

___
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

Re: [Python-Dev] Adding types.build_class for 3.3

[Benjamin Peterson]

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 implements that API
> (http://bugs.python.org/issue14588).
>
> However, in starting to write the documentation for the new API, I
> realised that the operator module really isn't the right home for the
> functionality.
>
> 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.

Actually, there used to be a _types C module before we figured out
that all the types could be extracted in Python. :)

Maybe you could make it a static or class method of type?



-- 
Regards,
Benjamin
___
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

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

[Mark Dickinson]

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 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

Re: [Python-Dev] Adding types.build_class for 3.3

[Nick Coghlan]

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 operator module is about operator syntax
(attrgetter, itemgetter and index are at least related to the dot
operator and subscripting syntax)

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'll go with that.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Adding types.build_class for 3.3

[Georg Brandl]

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 least it's related to the
> type system, whereas the operator module is about operator syntax
> (attrgetter, itemgetter and index are at least related to the dot
> operator and subscripting syntax)
> 
> 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'll go with that.

Works for me.

Georg

___
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

Re: [Python-Dev] Adding types.build_class for 3.3

[Hrvoje Niksic]

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'll go with that.


Note that to call mcl.build_class, you have to find a metaclass that 
works for bases, which is the job of build_class.  Putting it as a 
function in the operator module seems like a better solution.

___
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

Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades

[Carl Meyer]

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 the right solution to me. PEP 405 specifies that
bin/python3 exists, but not that it is the actual Python
interpreter binary that is normally used. For each target system, a
solution should be defined that allows in-place updates of Python
that also update all venvs automatically.

For example, for Windows, it would be sufficient to just have the
executable in bin/, as the update will only affect pythonXY.dll.
That executable may be different from the regular python.exe, and
it might be necessary that it locates its Python installation
first. For Unix, symlinks sound fine. Not sure what the issue with
OS X is.


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 application bundle.

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).


It occurs to me, belatedly, that this also means that upgrades should be 
a non-issue with OS X framework builds (presuming the upgraded 
actual-Python-binary gets placed in the same location, and the 
previously copied stub will still exec it without trouble), in which 
case we can symlink on OS X non-framework builds and copy on OS X 
framework builds and be happy.


Carl
___
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

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

[Serhiy Storchaka]

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 strict limit must be
(PY_SSIZE_T_MAX - 1 - (PY_SSIZE_T_MAX - 4) / 5).

___
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

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

[Serhiy Storchaka]

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.


___
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

Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades

[Carl Meyer]

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 bin/python3
exists, but not that it is the actual Python interpreter binary that is
normally used. For each target system, a solution should be defined that
allows in-place updates of Python that also update all venvs automatically.


I propose that for Windows, that solution is to have a new enough 
version of Windows and the necessary privileges, and use the --symlink 
option to the pyvenv script, or else to manually update venvs using 
pyvenv --upgrade.



For example, for Windows, it would be sufficient to just have the
executable in bin/, as the update will only affect pythonXY.dll.
That executable may be different from the regular python.exe, and
it might be necessary that it locates its Python installation first.


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.


Carl
___
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

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

[Antoine Pitrou]

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 less than a power of 2 and powers of 2 are
> always congruent to 1, 2 or 4 modulo 5, we're safe.
> 
> 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?

Agreed that the original code is good enough. Dividing by 4 is fast,
and this particular line of code is followed by a memory reallocation.

In general, "clever" micro-optimizations that don't produce significant
performance improvements should be avoided, IMHO :-)

Regards

Antoine.


___
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

Re: [Python-Dev] Assigning copyright...

[stefan brunthaler]

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 transparent
optimization "visible." AFAIR Sun opted to keep their instruction
derivatives secret, i.e., the second edition of the JVM internals does
not even mention them anymore.
___
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

[Python-Dev] Point of building without threads?

[Antoine Pitrou]

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?

Regards

Antoine.


___
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

Re: [Python-Dev] Assigning copyright...

[Georg Brandl]

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 having a PEP is a
> good thing in this case, as it makes a perfectly transparent
> optimization "visible." AFAIR Sun opted to keep their instruction
> derivatives secret, i.e., the second edition of the JVM internals does
> not even mention them anymore.

I think you'll find that we don't keep a lot of things secret about CPython
and its implementation.

Although this is different when it comes to the community.  The PSU has

___
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

[Python-Dev] Python 3.3 cannot find BeautifulSoup but Python 3.2 can

[Edward C. Jones]

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.3.

Python3.3a3 cannot find module bs4.  Neither can the "clone".  Python3.2 
can find

the module.  Here is a session with the "clone":

> ./python
Python 3.3.0a3+ (default:10ccbb90a8e9, May  6 2012, 19:11:02)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import bs4
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 974, in _find_and_load
ImportError: No module named 'bs4'
[71413 refs]
>>>

What is the problem?


___
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

Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades

[Martin v. Löwis]

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 application bundle.

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).


I don't understand. The "executable that the user actually called":
does that refer to

a) the stub (which the user *actually* called) or
b) the eventual binary (which is what gets *actually* run).

If a), then I think argv[0] just needs to continue to refer to the
stub, which is easy to achieve in execv.

If b), I wonder why the code needs to know the location to the binary
inside the bundle. But if this is needed to know, I suggest that some
environment variable is passed from the stub to the actual binary
(akin PYTHONHOME). How does the stub normally find out where the
framework is located?

Regards,
Martin
___
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

[Python-Dev] Python 3.3 cannot import BeautifulSoup but Python 3.2 can

[Edward C. Jones]

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"
developmental copy of 3.3.

Python3.3a3 cannot find module bs4.  Neither can the "clone".  Python3.2 can
find the module.  Here is a session with the "clone":

> ./python
Python 3.3.0a3+ (default:10ccbb90a8e9, May  6 2012, 19:11:02)
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import bs4
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 974, in _find_and_load
ImportError: No module named 'bs4'
[71413 refs]
>>>

What is the problem?

___
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

Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades

[Martin v. Löwis]

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 solution to me. PEP 405 specifies that bin/python3
exists, but not that it is the actual Python interpreter binary that is
normally used. For each target system, a solution should be defined that
allows in-place updates of Python that also update all venvs
automatically.


I propose that for Windows, that solution is to have a new enough
version of Windows and the necessary privileges, and use the --symlink
option to the pyvenv script, or else to manually update venvs using
pyvenv --upgrade.


Sounds fine to me as well.


For example, for Windows, it would be sufficient to just have the
executable in bin/, as the update will only affect pythonXY.dll.
That executable may be different from the regular python.exe, and
it might be necessary that it locates its Python installation first.


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 Python end users, for
whom creation of a venv under a privileged account is a significant
hassle.

This being free software, anybody needs to scratch her own itches, of
course.

Regards,
Martin
___
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

Re: [Python-Dev] Assigning copyright...

[Martin v. Löwis]

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
___
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

Re: [Python-Dev] Python 3.3 cannot import BeautifulSoup but Python 3.2 can

[Antoine Pitrou]

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
> python3-bs4 (BeautifulSoup4 for Python3).  I also downloaded a "clone"
> developmental copy of 3.3.
> 
> Python3.3a3 cannot find module bs4.  Neither can the "clone".  Python3.2 can
> find the module.  Here is a session with the "clone":

python-dev is for development *of* Python. For general Python
questions, you should ask on python-list:
http://mail.python.org/mailman/listinfo/python-list

(quick answer: you must install BeautifulSoup specifically for your
compiled interpreter. Python does not share libraries accross
different interpreter versions)

Regards

Antoine.


___
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

Re: [Python-Dev] Python 3.3 cannot import BeautifulSoup but Python 3.2 can

[Oleg Broytman]

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
> python3-bs4 (BeautifulSoup4 for Python3).  I also downloaded a "clone"
> developmental copy of 3.3.
> 
> Python3.3a3 cannot find module bs4.

   Could it be bs4 is installed in python3.2-specific path and hence it's
not in python3.3 sys.path?

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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

Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades

[Vinay Sajip]

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_LAUNCHER__, which points to itself, before it execs the real Python.
On OS X, Python code checks for this, rather than sys.executable, to determine
the location of the pyvenv.cfg file. This seems to work for me (Ned Deily is
looking into it more closely, I believe).

Regards,

Vinay Sajip

___
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

Re: [Python-Dev] Python 3.3 cannot import BeautifulSoup but Python 3.2 can

[Barry Warsaw]

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 (BeautifulSoup4 for Python3).  I also downloaded a "clone"
>developmental copy of 3.3.
>
>Python3.3a3 cannot find module bs4.  Neither can the "clone".  Python3.2 can
>find the module.  Here is a session with the "clone":

Remember that Debian installs its system packages into dist-packages not
site-packages.  This is a Debian delta from upstream.

http://wiki.debian.org/Python

Cheers,
-Barry

___
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

Re: [Python-Dev] Assigning copyright...

[stefan brunthaler]

> 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 by actual
CPython instructions (e.g., from my previous patch to the new one the
YIELD_FROM instruction has been added.)
I'd say the situation is similar to the threaded code/computed goto's issue.


> Although this is different when it comes to the community.  The PSU has
>
?

I am going to file a patch like Martin von Loewis suggested.

Thanks,
--stefan
___
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

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

[Victor Stinner]

> 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 reasons listed in this thread.

Victor
___
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

Re: [Python-Dev] PEP 405 (pyvenv) and system Python upgrades

[Paul Moore]

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 Python end users, for
> whom creation of a venv under a privileged account is a significant
> hassle.

Personally, I would find a venv which required being run as an admin
account to be essentially unusable on Windows (particularly Windows 7,
where this means creating venvs in an "elevated" console window).

Allowing for symlinks as an option is fine, I guess, but I'd be -1 on
it being the default.

Paul.
___
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

Re: [Python-Dev] Point of building without threads?

[Victor Stinner]

> 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 work, I'm working on embedded systems (television set top boxes)
with a Linux kernel with the GNU C library, and we do use threads!

I'm not sure that Python runs on slower/smaller systems because they
have other constrains like having very few memory, maybe no MMU and
not using the glibc but µlibc for example.

There is the "python-on-a-chip" project. It is written from scratch
and is very different from CPython. I don't think that it uses
threads.
http://code.google.com/p/python-on-a-chip/

Victor
___
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

Re: [Python-Dev] Adding types.build_class for 3.3

[Greg Ewing]

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 thing the types module contains is
types. A function would seem a bit out of place there.

I don't think there's too much wrong with putting it in the
operators module -- it's a function doing something that is
otherwise expressed by special syntax.

--
Greg
___
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

Re: [Python-Dev] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()

[Greg Ewing]

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 arithmetic being used to check
for overflow can't itself suffer from overflow. At least that
much is obvious from the new version.

--
Greg
___
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

Re: [Python-Dev] Adding types.build_class for 3.3

[Nick Coghlan]

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 from my phone, thus the relative brevity :)
On May 8, 2012 9:01 AM, "Greg Ewing"  wrote:

> 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 thing the types module contains is
> types. A function would seem a bit out of place there.
>
> I don't think there's too much wrong with putting it in the
> operators module -- it's a function doing something that is
> otherwise expressed by special syntax.
>
> --
> Greg
> __**_
> 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/**
> ncoghlan%40gmail.com
>
___
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

Re: [Python-Dev] Adding types.build_class for 3.3

[Eric Snow]

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 weird - at least it's related to the
> type system, whereas the operator module is about operator syntax
> (attrgetter, itemgetter and index are at least related to the dot
> operator and subscripting syntax)
>
> 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'll go with that.

+1

-eric
___
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

Re: [Python-Dev] Adding types.build_class for 3.3

[Nick Coghlan]

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)
>>
>> Works for me, so unless someone else can see a problem I've missed,
>> we'll go with that.
>
>
> Note that to call mcl.build_class, you have to find a metaclass that works
> for bases, which is the job of build_class.  Putting it as a function in the
> operator module seems like a better solution.

No, the "mcl" in the call is just the designated metaclass - the
*actual* metaclass of the resulting class definition may be something
different. That's why this is a separate method from mcl.__new__.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

[Python-Dev] Spread Python

[Josemon Maliakal]

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 and spread python for
all.The article will be published in www.texplod.com. If any one interested
please send me a private message
-- 
*Regards*
*
*
Cre@tivmindz
www.texplod.com
ra
___
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

[Python-Dev] Spread Python

[Josemon Maliakal]

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 and spread python for
all.The article will be published in www.texplod.com. If any one interested
please send me a private message
-- 
*Regards*
*
*
Cre@tivmindz
www.texplod.com
ra



-- 
*Regards*
*
*
Cre@tivmindz
www.texplod.com
___
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

Re: [Python-Dev] Point of building without threads?

[Dirkjan Ochtman]

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 option for something else than
> curiosity of mind?

Gentoo (of course) allows users to build Python without threads; I'm
not aware of anyone depending on that, but I sent out a quick question
to gentoo-dev.

Cheers,

Dirkjan
___
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