Re: [Python-Dev] Computed Goto dispatch for Python 2

[Xavier Combelle]

> +1. The new embeddable Python distribution for Windows is a great step
> forward for this. It's not single-file, but it's easy to produce a
> single-directory self-contained application with it. I don't know if
> there's anything equivalent for Linux/OSX - maybe it's something we
> should look at for them as well (although the whole "static binaries"
> concept seems to be fairly frowned on in the Unix world, from what
> I've seen).
>
> Just curious What is "the new embeddable Python distribution for Windows" ?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 492 documentation

[Xavier Combelle]

Shouldn't at least ayncio doc
https://docs.python.org/3.5/library/asyncio.html be updated accordingly ?
for example
https://docs.python.org/3.5/search.html?q=await&check_keywords=yes&area=default
doesn't mention https://docs.python.org/3.5/library/asyncio.html

2015-08-02 16:21 GMT+02:00 Yury Selivanov :

> Nikolaus,
>
> Strange.  PEP 492 changes are fully documented since b3.
>
> Here are just few examples:
>
>
> https://docs.python.org/3.5/whatsnew/3.5.html#pep-492-coroutines-with-async-and-await-syntax
> https://docs.python.org/3.5/reference/datamodel.html#coroutines
> https://docs.python.org/3.5/reference/compound_stmts.html#coroutines
>
> Perhaps, it's a browser cache issue?
>
> Yury
>
> On 2015-08-02 12:38 AM, Nikolaus Rath wrote:
>
>> Hello,
>>
>> Looking at the language reference for 3.5.0b4, I noticed that it
>> mentions neither async nor await.
>>
>> Is this still going to get updated, or will the only documentation
>> consist of the PEP itself? I think having a Python release recognize
>> keywords that are not mentioned in the language reference would be quite
>> unfortunate (even if they're treated specially to preserve backwards
>> compatibility).
>>
>> Best,
>> -Nikolaus
>>
>>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/xavier.combelle%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Profile Guided Optimization active by-default

[Xavier Combelle]

Pardon me if I'm not in the right place to ask the following naive
question. (say me if it's the case)

Does Profile Guided Optimization performance improvements are specific to
the chip where the built is done or the performance is better on a larger
set of chips?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Review request: issue 27350, compact ordered dict

[Xavier Combelle]

On 10/08/2016 17:06, Maciej Fijalkowski wrote:
> * there are nice speedups
>
in this blog post
https://morepypy.blogspot.fr/2015/01/faster-more-memory-efficient-and-more.html
it is mentioned big speedup only on microbenchmark and small speedups on
pypy benchmark. is it what you call nice speedups or does there is other
things ?

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Someons's put a "Python 2.8" on GitHub

[Xavier Combelle]

> I believe that this 'derived work' is both a trademark and a license
> violation.  Clause 7 of the PSF License V. 2, as displayed by '>>>
> license()', explicitly denies permission to make derivative works that
> violate PSF Trademarks.  Perhaps Github and Infoworld should be
> informed also, but our lawyer can decide.
>
> "This License Agreement does not grant permission to use PSF
> trademarks ..."
>
> Perhaps that document should mention somewhere at the top that
> "Python" is a PSF Trademark for computer languages.
I am not a lawyer, but to my understanding, violating the trademark is
not a violation of the license. The fact that the license mention it
doesn't grant permission to use PSF trademarks doesn't mean that by
violating the trademark you also violate the license.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecate `from __future__ import unicode_literals`?

[Xavier Combelle]

I personally used it when I was forced to use python 2 and working
mainly with unicode processing (It is particularly handy when working
with json for example)


Le 16/12/2016 à 20:24, Guido van Rossum a écrit :
> I am beginning to think that `from __future__ import unicode_literals`
> does more harm than good. I don't recall exactly why we introduced it,
> but with the restoration of u"" literals in Python 3.3 we have a much
> better story for writing straddling code that is unicode-correct.
>
> The problem is that the future import does both too much and not
> enough -- it does too much because it changes literals to unicode even
> in contexts where there is no benefit (e.g. the argument to getattr()
> -- I still hear of code that breaks due to this occasionally) and at
> the same time it doesn't do anything for strings that you read from
> files, receive from the network, or even from other files that don't
> use the future import.
>
> I wonder if we can add an official note to the 2.7 docs recommending
> against it? (And maybe even to the 3.x docs if it's mentioned there at
> all.)
>
> -- 
> --Guido van Rossum (python.org/~guido )
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/xavier.combelle%40gmail.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP or formal description of Python module structure

[Xavier Combelle]

Le 15/10/2012 09:43, anatoly techtonik a écrit :

Hi,

I am trying to figure out what Python module is internally (WIP
http://wiki.python.org/moin/techtonik)? Is there already a good piece
of documentation that I missed that can answer all these questions
already?

...what properties do you get in empty Python module (__doc__, __name__, ...)?
...what of those properties are set by the language standard
(required) and what are just optional helpers from/for the
interpreter?
...what is the proper way to inspect modules and access their
properties at runtime?
...what optional properties are defined by language standard that can
you set implicitly?
...how each internal property is used by the interpreter and when it appeared?
...what is the proper way to create module namespace at run-time?

I'd like to see some kind of reference of properties with
classification required/optional, purpose, when set, who uses, how to
approach etc. in one place.

--
anatoly t.
___
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/xavier.combelle%40free.fr

from http://docs.python.org/reference/datamodel.html


Modules

   Modules are imported by the import
   
   statement (see section /The import statement/
   ). A
   module object has a namespace implemented by a dictionary object
   (this is the dictionary referenced by the func_globals attribute of
   functions defined in the module). Attribute references are
   translated to lookups in this dictionary, e.g., m.x is equivalent to
   m.__dict__["x"]. A module object does not contain the code object
   used to initialize the module (since it isn't needed once the
   initialization is done).

   Attribute assignment updates the module's namespace dictionary,
   e.g., m.x = 1 is equivalent to m.__dict__["x"] = 1.

   Special read-only attribute: __dict__ is the module's namespace as a
   dictionary object.

   *CPython implementation detail:* Because of the way CPython clears
   module dictionaries, the module dictionary will be cleared when the
   module falls out of scope even if the dictionary still has live
   references. To avoid this, copy the dictionary or keep the module
   around while using its dictionary directly.

   Predefined (writable) attributes: __name__ is the module's name;
   __doc__ is the module's documentation string, or None if
   unavailable; __file__ is the pathname of the file from which the
   module was loaded, if it was loaded from a file. The __file__
   attribute is not present for C modules that are statically linked
   into the interpreter; for extension modules loaded dynamically from
   a shared library, it is the pathname of the shared library file.


___
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