Re: [Python-Dev] peps: Updates in response to Barry Warsaw's feedback

[Antoine Pitrou]

On Sun,  6 Jan 2013 08:25:44 +0100 (CET)
nick.coghlan  wrote:
> http://hg.python.org/peps/rev/3eb7e4b587da
> changeset:   4654:3eb7e4b587da
> user:Nick Coghlan 
> date:Sun Jan 06 17:22:45 2013 +1000
> summary:
>   Updates in response to Barry Warsaw's feedback
> 
> files:
>   pep-0432.txt |  217 ++
>   1 files changed, 146 insertions(+), 71 deletions(-)
> 
> 
> diff --git a/pep-0432.txt b/pep-0432.txt
> --- a/pep-0432.txt
> +++ b/pep-0432.txt
> @@ -40,19 +40,21 @@
>  well-defined phases during the startup sequence:
>  
>  * Pre-Initialization - no interpreter available
> -* Initialization - interpreter partially available
> -* Initialized - full interpreter available, __main__ related metadata
> +* Initializing - interpreter partially available
> +* Initialized - interpreter available, __main__ related metadata
>incomplete
> -* Main Execution - optional state, __main__ related metadata populated,
> -  bytecode executing in the __main__ module namespace
> +* Main Execution - __main__ related metadata populated, bytecode
> +  executing in the __main__ module namespace (embedding applications
> +  may choose not to use this phase)

Since we are here, I would bikeshed a little and point out that
"initializing" and "initialiazed" are states, not phases. Either way,
the nomenclature should be consistent.

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] peps: Updates in response to Barry Warsaw's feedback

[Nick Coghlan]

On Sun, Jan 6, 2013 at 10:26 PM, Antoine Pitrou  wrote:
> Since we are here, I would bikeshed a little and point out that
> "initializing" and "initialiazed" are states, not phases. Either way,
> the nomenclature should be consistent.

States and phases are generally the same thing (e.g. states of matter
vs phases of matter).

I've switched back and forth between state, stage and phase at various
times, though, so the PEP is currently internally inconsistent. If
there are any leftover "state" and "stage" references, it's just a
mistake since "phase" is the terminology I finally settled on.

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] Why no venv in existing directory?

[Christian Tismer]

Minor correction:

On 06.01.13 19:10, Christian Tismer wrote:
Yes, you can do the upgrade, but there are a few flaws which keep me 
from using this:


It is pretty common to use virtualenv inside a mercurial checkout.

With venv, installation with

python3 -m venv my-repos

complains that the directory is not empty.
With

python3 -m venv my-repos --clear

I was shocked, because that kills my repository :-(
After doing a new clone of my repos, I tried with

python3 -m venv my-repos --update



Sorry, I meant

python3 -m venv my-repos --upgrade


This works a little, but does not install the bin/activate source.



--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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] Why no venv in existing directory?

[Christian Tismer]

Yes, you can do the upgrade, but there are a few flaws which keep me 
from using this:


It is pretty common to use virtualenv inside a mercurial checkout.

With venv, installation with

python3 -m venv my-repos

complains that the directory is not empty.
With

python3 -m venv my-repos --clear

I was shocked, because that kills my repository :-(
After doing a new clone of my repos, I tried with

python3 -m venv my-repos --update

This works a little, but does not install the bin/activate source.

Finally, I reverted to using virtualenv instead, although I would love
to migrate. But this is not enough.

Anything I'm missing here?

cheers - chris

On 24.08.12 13:30, Andrew Svetlov wrote:

Looks like you can use for that
$ pyvenv . --upgrade


On Fri, Aug 24, 2012 at 12:19 PM, "Stefan H. Holek · Jarn"
 wrote:

FYI, I have created a tracker issue for this: http://bugs.python.org/issue15776

Stefan


On 23.07.2012, at 09:09, Stefan H. Holek wrote:


The feature certainly is on *my* wish-list but I might be alone here. ;-)


--
Christian Tismer :^)   
Software Consulting  : Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121 :*Starship* http://starship.python.net/
14482 Potsdam: PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04   9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
  whom do you want to sponsor today?   http://www.stackless.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] More compact dictionaries with faster iteration

[Kristján Valur Jónsson]

The memory part is also why I am interested in this approach.
Another thing has been bothering me.  This is the fact that with the default 
implementation, the smll table is only ever populated up to a certain 
percentage, I cant recall, perhaps 50%.  Since the small table is small by 
definition, I think it ought to be worth investigating if we cannot allow it to 
fill to 100% before growing, even if it costs some collisions.  A linear lookup 
in a handful of slots can't be that much of a bother, it is only with larger 
number of entries that the O(1) property starts to matter.
K


Frá: Python-Dev [python-dev-bounces+kristjan=ccpgames@python.org] fyrir 
hönd Maciej Fijalkowski [fij...@gmail.com]
Sent: 5. janúar 2013 21:03
To: Antoine Pitrou
Cc: 
Efni: Re: [Python-Dev] More compact dictionaries with faster iteration

On Sat, Jan 5, 2013 at 1:34 AM, Antoine Pitrou  wrote:
> On Thu, 3 Jan 2013 12:22:27 +0200
> Maciej Fijalkowski  wrote:
>> Hello everyone.
>>
>> Thanks raymond for writing down a pure python version ;-)
>>
>> I did an initial port to RPython for experiments. The results (on
>> large dicts only) are inconclusive - it's either a bit faster or a bit
>> slower, depending what exactly you do. There is a possibility I messed
>> something up too (there is a branch rdict-experiments in PyPy, in a
>> very sorry state though).
>
> But what about the memory consumption? This seems to be the main point
> of Raymond's proposal.
>

Er. The memory consumption can be measured on pen and paper, you don't
actually need to see right?

After a lot more experimentation I came up with something that behaves
better for large dictionaries. This was for a long time a weak point
of PyPy, because of some GC details. So I guess I'll try to implement
it fully and see how it goes. Stay tuned, I'll keep you posted.

PS. PyPy does not have lots of small dictionaries because of maps (so
you don't have a dict per instance), hence their performance is not at
all that interesting for PyPy.

Cheers,
fijal
___
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/kristjan%40ccpgames.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] More compact dictionaries with faster iteration

[Raymond Hettinger]

On Jan 3, 2013, at 2:22 AM, Maciej Fijalkowski  wrote:

> Hello everyone.
> 
> Thanks raymond for writing down a pure python version ;-)

Thanks for running with it.

> 
> I did an initial port to RPython for experiments. The results (on
> large dicts only) are inconclusive - it's either a bit faster or a bit
> slower, depending what exactly you do. There is a possibility I messed
> something up too (there is a branch rdict-experiments in PyPy, in a
> very sorry state though).
> 
> One effect we did not think about is that besides extra indirection,
> there is an issue with data locality - having to look in two different
> large lists seems to be a hit.

In pure python, I didn't see a way to bring the hash/key/value entries
side-by-side as they currently are in CPython.   How does PyPy currently
handle this issue?  Is there a change I could make to the recipe that
would restore data locality?


Raymond___
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] More compact dictionaries with faster iteration

[Raymond Hettinger]

On Jan 6, 2013, at 1:40 PM, Kristján Valur Jónsson  
wrote:

> The memory part is also why I am interested in this approach.
> Another thing has been bothering me.  This is the fact that with the default 
> implementation, the smll table is only ever populated up to a certain 
> percentage, I cant recall, perhaps 50%.  

Dicts resize when the table is over two-thirds full.   Small dicts contain zero 
to five keys.

> Since the small table is small by definition, I think it ought to be worth 
> investigating if we cannot allow it to fill to 100% before growing, even if 
> it costs some collisions.  A linear lookup in a handful of slots can't be 
> that much of a bother, it is only with larger number of entries that the O(1) 
> property starts to matter.

I looked at this a few years ago and found that it hurt performance 
considerably.   Uncle Timmy (and others) had done a darned fine job of tuning 
dictionaries. 


Raymond

___
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