Re: P2P text chat engine

[Kirill]

On 7 май, 21:23, "Diez B. Roggisch"  wrote:
> Navanjo schrieb:
>
> > If you have the source code of a p2p text chat engine please send to me
>
> I found that & a pot of gold under my bed. Care to give me your address
> so that I can send it to you?
>
> SCNR,
> Diez

Hello, can you sent it to me ?
ave...@gmail.com
Many thanks!!!
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: The best, friendly and easy use Python Editor.

[Kirill Pekarov]

> I think PyCharm is ideal for you.
> http://www.jetbrains.com/pycharm/

+1 for PyCharm. 
I used many editors, and PyCharm (IDEA) is just perfect. 

-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.10: YAML parser and emitter for Python

[Kirill Simonov]

 Announcing PyYAML-3.10


A new bug fix release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML


Changes
===

* Do not try to build LibYAML bindings on platforms other than CPython
  (Thank to olt(at)bogosoft(dot)com).
* Clear cyclic references in the parser and the emitter
  (Thank to kristjan(at)ccpgames(dot)com).
* LibYAML bindings are rebuilt with the latest version of Cython.
* Dropped support for Python 2.3 and 2.4; currently supported versions
  are 2.5 to 3.2.


Resources
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.10.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.10.zip
Windows installers:
http://pyyaml.org/download/pyyaml/PyYAML-3.10.win32-py2.5.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.10.win32-py2.6.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.10.win32-py2.7.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.10.win32-py3.0.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.10.win32-py3.1.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.10.win32-py3.2.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: 
http://lists.sourceforge.net/lists/listinfo/yaml-core



About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Copyright
=

The PyYAML module is written by Kirill Simonov .

PyYAML is released under the MIT license.
--
http://mail.python.org/mailman/listinfo/python-list

Performance of map vs starmap.

[Kirill Balunov]

Sometime ago I asked this question at SO [1], and among the responses
received was paragraph:

 - `zip` re-uses the returned `tuple` if it has a reference count of 1 when
the `__next__` call is made.
 - `map` build a new `tuple` that is passed to the mapped function every
time a `__next__` call is made.

Why can not `map` use the same approach as `zip`?

Also it turns out that a faster solution looks not reasonable, since it
requires additional calculations..

[1] https://stackoverflow.com/questions/46172018/perfomance-
of-map-vs-starmap

Thanks,
- gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

What is the future of the PEP 467?

[Kirill Balunov]

What is the future of the PEP 467 ("Minor API improvements for binary
sequences")? It was not accepted and was not rejected, although there was a
rather active discussion.

In addition to what is stated in the PEP, I would like to know your opinion
on the additional issue:
At present, the repr() and str() of bytes return the same thing - which
looks  more as "binary string". May be it is better if the repr() will
return "binary sequence" -> only escaped hex values. While the str()
representation would return the same thing as now (some ascii analogue)?

- with kind regards, gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Using the variable type annotation syntax as a placeholder in a nonlocal scope?

[Kirill Balunov]

I've asked the same question on StackOverflow, but it seems to me that it
is opinion based and will be ignored. So I ask for advice here:

Since PEP 526 -- Syntax for Variable Annotations
  was approved, in Python 3.6+
it is possible to provide type hint information in the form *x: int*, also
the PEP says "However, annotating a local variable will cause the
interpreter to always make it local to the scope and leaves the variable
uninitialized". Therefore in Python 3.6+ it is syntactically legal to
write:

def outer():
x: int
def inner():
nonlocal x
x = 10
inner()
print(x)

while the above snippet is semantically more equivalent to:

def outer():
#x
def inner():
nonlocal x
x = 10
inner()
print(x)

Which is obviously a *SyntaxError: no binding for nonlocal 'x' found`*,
sorry for the pun. Also there is nothing said about this style in PEP 8 and
Python 3.6 docs. So should I consider this as a bug, or an implementation
detail (side effect), or a wart, or a feature?

To clarify the purpose of the question - we can not come to a consensus and
I would like to hear your opinion and possible pitfalls, if any, if we
choose to use this form in our codebase.

With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Fwd: property decorator?

[Kirill Balunov]

2017-12-21 2:56 GMT+03:00 Irv Kalb :

> My questions about this are really historical.  From my reading, it looks
> like using an @property decorator is a reference to an older approach using
> a built in "property" function.  But here goes:
>
> 1) Why were these decorator names chosen?  These two names @property and
> @.setter don't seem to be very clear to me.  At a minimum, they don't
> match.  Wouldn't decorator names like @.getter and @.setter
> have been better - more explicit?
>
> 2)  Alternatively, if the getter was going to use the @property decorator,
> then it would seem complimentary  to have the decorator name for the
> associated setter function to have the word "property" in its also,
> something like @propertySetter.
>
> 3)  If I create a method with the @property decorator, is there anything
> else that is implied about the name of the method other than you can now
> refer to the . - which calls the appropriate method?  My
> guess/understanding is that in my example above, "salary" is considered the
> property name, which is how you would refer to it outside of the object.
> Inside the class, you use the property name as the name of both the setter
> and the getter methods.  Is that the right way to think about it?
>

There are nothing special with decorators, the are simply functions which
take at least one argument (of course they can be implemented as classes,
but lets make things simple), and *`@decorator*` is a syntactic sugar
for *`func
= decorator(func)`*. As I see it, the primary idea to introduce them in
Python was readability, and possibility for special syntax highlighting and
nothing more. To sum it up, while* `property*` is often used as a
decorator, the `*property`* built-in is actually a class. So it is not "*an
older approach using a built in "property" function*" but in reality it is
the same class as it was but can be applied with new decorator syntax. And
defined in stdlib as *`class property(fget=None, fset=None, fdel=None,
doc=None)`*.


Finally, it seems very odd to me that when you use the @property decorator
> and the @.setter, that both of the methods that are decorated
> need to have the same name (but of course different set of parameters.)  As
> a teacher, this seems like it would be an extremely difficult concept to
> get across to students, as this does not work the same way as other Python
> functions (and methods).  Without a decorator, the second function of the
> same name overrides an earlier function of the same name, as in this simple
> example:
>


This is not true, actually they all work the same way following *descriptor
protocol* - the mechanism behind properties, methods, static methods, and
others. It is not simple topic, but it essential, I will provide some
references which can help you to grasp:

Descriptor HowTo Guide 
brilliant tutorial by Raymond Hettinger, which is a part of official
documentation. It is very well written, but if you need more on this topic
this books helped me a lot:

"*Python in a Nutshell, 2E by Alex Martelli*" while this book covers Python
2.5, the key idea of descriptors was introduced as a part of new style
classes in Python 2.2.

"*Python Cookbook, 3E by David Beazley and Brian K. Jones*" covers Python 3
with a lot of practical examples.

"*Fluent Python by Luciano Ramalho*" especially Chapter 20, but my advise
to read the book sequentially.

With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with assignment. Python error or mine?

[Kirill Balunov]

2017-12-21 22:06 GMT+03:00 John Ladasky :

> On Thursday, December 21, 2017 at 7:37:39 AM UTC-8, MRAB wrote:
>
> > Python never makes a copy unless you ask it to.
> >
> > What x1=X does is make the name x1 refer to the same object that X
> > refers to. No copying.
>
> Well, except with very simple, mutable data types like scalars... compare
> this:
>

No copy means no copy, it is the rule! What you see is really new binding
operation under the hood.
'x=1; x += 1', means calculate x+1 and bind it to the same name. Compare it
to this example:


>>> tpl = ((1,2),(3,4))
>>> tpl += ((1,2),)
>>> tpl

((1, 2), (3, 4), (1, 2))


No copy, new binding to the same name :)


With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Using the variable type annotation syntax as a placeholder in a nonlocal scope?

[Kirill Balunov]

Any suggestions? Thank you.

With kind regards, -gdg

On Dec 20, 2017 22:43, "Kirill Balunov"  wrote:

> I've asked the same question on StackOverflow, but it seems to me that it
> is opinion based and will be ignored. So I ask for advice here:
>
> Since PEP 526 -- Syntax for Variable Annotations
> <https://www.python.org/dev/peps/pep-0526/>  was approved, in Python 3.6+
> it is possible to provide type hint information in the form *x: int*,
> also the PEP says "However, annotating a local variable will cause the
> interpreter to always make it local to the scope and leaves the variable
> uninitialized". Therefore in Python 3.6+ it is syntactically legal to
> write:
>
> def outer():
> x: int
> def inner():
> nonlocal x
> x = 10
> inner()
> print(x)
>
> while the above snippet is semantically more equivalent to:
>
> def outer():
> #x
> def inner():
> nonlocal x
> x = 10
> inner()
> print(x)
>
> Which is obviously a *SyntaxError: no binding for nonlocal 'x' found`*,
> sorry for the pun. Also there is nothing said about this style in PEP 8 and
> Python 3.6 docs. So should I consider this as a bug, or an implementation
> detail (side effect), or a wart, or a feature?
>
> To clarify the purpose of the question - we can not come to a consensus
> and I would like to hear your opinion and possible pitfalls, if any, if we
> choose to use this form in our codebase.
>
> With kind regards, -gdg
>
>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Default annotations for variables

[Kirill Balunov]

Will there be any implications (or is it possible) if all variables will
have an attribute *something like* `__type__` which by default will be
initialized to *something like* `AnyType`. So in the case `x = 12` will be
equivalent to `x: AnyType = 12`.

x: int
x = 12
x.__type__ # int

a, b = 11, 12
a.__type__  # AnyType
b.__type__  # AnyType

And also in this case:

class Dummy:
a: int
b: float
c = []

Dummy.__annotations__  # will be {'a': int, 'b': float, 'c': AnyType}


While I ask purely out of curiosity, I think this is not an off-topic for
python-list.

With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Default annotations for variables

[Kirill Balunov]

2017-12-27 13:54 GMT+03:00 Chris Angelico :

> This won't work. When you say "a.__type__", it means "take the *value*
> referenced by a, and look up its __type__ attribute". So it's
> equivalent to writing:
>
> (11).__type__
> (12).__type__
>

Thank you for clarification, I understand that names don't have attributes
:). But I did not find the right words to describe the idea.


> To query something about the *variable*, you have to look at its
> enclosing namespace. If these are at top level, you'd be looking at
> the module-level __annotations__ dictionary. That's also where
> x.__type__ would be - it's actually stored in __annotations__["x"].
>

Here I was a bit knocked down by the IPython console. Strangely, but the `
__annotations__` is not initialized to a an empty dict when you start it,
while in Python console it is.


> There is definitely room to ask the question "can we get default
> annotations for any global or class-level name that gets assigned to
> without an annotation?". I fully expect that thread to be one of those
> gigantic ones, but have fun :)
>

Yes this is exactly what I was about to ask :)

With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Default annotations for variables

[Kirill Balunov]

2017-12-27 14:19 GMT+03:00 Kirill Balunov :

> Here I was a bit knocked down by the IPython console. Strangely, but the `
> __annotations__` is not initialized to a an empty dict when you start it,
> while in Python console it is.
>

In addition, there are some imbalance without IPython. Since modules and
classes define namespaces it is strange that:

empty `module` -> has `__annotations__` defined to {}.
empty `class` -> does not have `__annotations__` raises AttributeError.

With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Creation of a metaclass for dataclass.

[Kirill Balunov]

I'm studying the meta-programming topic in Python, and as an exercise I'm
trying to make a somewhat simplified version of dataclass. My goal in this
exercise is to make the difference between annotated variables and usual
ones to be as much transparent as possible. So I come with this code to
obtain initial fields. It does not catch corner cases and as much as
possible undressed to be short. So my question is there any visible
pitfalls or am I doing something wrong from the early beginning?

Two helpful functions not to clutter `__annotations__`:

from typing import Any
AnyType = Any

def _is_not_dunder(name):
return not ((len(name) > 4) and (name[:2] == name[-2:] == '__'))

def _is_not_descriptor(obj):
return not (hasattr(obj, '__get__') or
hasattr(obj, '__set__') or
hasattr(obj, '__delete__'))

The special dict (class namespace) to inject usual variables in `
__annotations__` with default typehint - `AnyType`, and also keep their
ordered appearance in the class body.

class SpecialDict(dict):
def __init__(self):
super().__init__()
super().__setitem__('__annotations__', {})

def __setitem__(self, key, value):
if not (key in self) and _is_not_dunder(key) and
_is_not_descriptor(value):
self['__annotations__'][key] = AnyType
super().__setitem__(key, value)

Data meta-class which defines `__fields` from `__annotations__`:

class DataMeta(type):
@classmethod
def __prepare__(metacls, cls, bases, **kwargs):
_dict = SpecialDict()
return _dict

def __init__(cls, *args , **kwargs):
super().__init__(*args)

def __new__(metacls, cls, bases, clsdict):
clsdict['__fields'] = tuple(clsdict['__annotations__'].items())
_cls = type.__new__(metacls, cls, bases, clsdict)
return _cls

And test class:

class MyClass(metaclass=DataMeta):
a: float
barattr: int = 2
jik = 12
bzik: int =14

def foo(self, param):
pass

data = MyClass()

a.__fields   # (('a', float), ('barattr', int), ('jik', typing.Any),
('bzik', int))


Thank you!

With kind regards, -gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: python to C code generator

[Kirill Balunov]

You can look at SymPy code generator
http://docs.sympy.org/latest/modules/utilities/codegen.html
Perhaps this is exactly what you need.

With kind regards,
-gdg

2018-01-23 17:00 GMT+03:00 Ned Batchelder :

> On 1/23/18 8:48 AM, kushal bhattacharya wrote:
>
>> On Tuesday, January 23, 2018 at 7:05:02 PM UTC+5:30, bartc wrote:
>>
>>> On 23/01/2018 13:23, kushal bhattacharya wrote:
>>>
 On Wednesday, January 17, 2018 at 4:34:23 PM UTC+5:30, kushal
 bhattacharya wrote:

> Hi,
> Is there any python framework or any tool as  which can generate C
> code from python code as it is .
>
> Thanks,
> Kushal
>
 yes i have but it generates a complex C code with python dependencies.I
 want to call the generated function from another C code but i Cant figure
 out how to do that

>>> Because the translation isn't simply defined.
>>>
>>> I've just tried nuitka on the Python code 'a=b+c', and it generates 2400
>>> lines of C. The main purpose seems to be to generate a self-contained
>>> executable corresponding to the Python, but generating first a C
>>> equivalent then using a C compiler and linker.
>>>
>>> This equivalent code may just contain all the bits in CPython needed to
>>> do the job, but bypassing all the stuff to do with executing actual
>>> byte-code. But it also seems to do some optimisations (in the generated
>>> C before it uses C compiler optimisations), so that if static types can
>>> be inferred it might make use of that info.
>>>
>>> Perhaps you simply want to use Python syntax to write C code? That would
>>> be a different kind of translator. And a simpler one, as 'a=b+c'
>>> translates to 'a+b+c;' in C.
>>>
>>> --
>>> bartc
>>>
>>
>> This is exactly what i meant to say.My goal is to translate the python
>> code into its C equivalent with function name as it is.
>>
>
> The best way to do that is to read the Python code, understand what it
> does, and re-write it in C.  You won't find an automatic tool that can do
> the job you want.  The semantics of Python and C are too different.
>
> --Ned.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python on Android?

[Kirill Balunov]

To mention another way to use Python on Android is Termux project
.  From their site - Termux is an *Android terminal
emulator and Linux environment app* that works directly with no rooting or
setup required and Python is a side-effect. There are still some
restrictions but in general you can install everything you want. I even ran
Jupyter notebook, but on the phone it is certainly a mockery :)

With kine regards,
-gdg

2018-02-18 19:57 GMT+03:00 Johannes Findeisen :

> On Sun, 18 Feb 2018 20:57:02 +1100
> Chris Angelico wrote:
>
> > Does anyone have experience with running Python scripts on Android
> > phones? I have a brother (honestly! I'm not actually using a phone
> > myself!) who's trying to run one of my scripts in QPython, which
> > claims to be version 3.2.2. I think that really truly is a Python 3.2
> > implementation - probing for newer features suggests that it actually
> > doesn't even support the u"..." syntax that came (back) in with Python
> > 3.3. So... does anyone know of a Python interpreter that's compatible
> > with 3.4 or better and runs on Android?
> >
>
> There is an App for Android called "Pydroid 3". You can find it in
> the Google Play Store [0]. It provides a Python interpreter in version
> 3.6.2 in its current release.
>
> The Python binary is installed under
>
> /data/user/0/ru.iiec.pydroid3/files/arm-linux-androideabi/bin/python
>
> but I can not access it in a normal terminal without being user "root"
> but it is usable from within the terminal included in the Pydroid App.
>
> I do only execute some basic Python stuff for fun and learning when
> traveling but that should work as you can open and save your code from
> the integrated editor.
>
> Johannes
>
> [0] https://play.google.com/store/apps/details?id=ru.iiec.pydroid3
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Questions about `locals` builtin

[Kirill Balunov]

Hi,

I am a little bit confused with `locals` builtin in these moments:

1. The documentation says that _free varaibles_ are returned, which seems
incorrect description. In my mind the term free variable refers to
variables used in a function that are not local variables nor parameters of
that function.

In docs: "Update and return a dictionary representing the current local
symbol table. Free variables are returned by `locals()` when it is called
in function blocks, but not in class blocks."

>>> def func():

b = 12

print(locals(), ' : ', id(locals))

c = 13

print(locals(), ' : ', id(locals))


>>> print("Free variables: ", func.__code__.co_names)
>>> print("Local variables: ", func.__code__.co_varnames)

Free variables: ('print', 'locals', 'id')
Local variables: ('b', 'c')


2. The documentation has a note that "The contents of this dictionary
should not be modified". Which implies that it is a read only mapping. So
the question why it is `dict` instead of `types.MappingProxyType`?

3. There is one more moment: local variables had been determined when
function was compiled. But `locals` returns _some_ current runtime copy. I
find this also confusing:


>>> def func1():

loc = locals()

b = 12

return loc


>>> def func2():

b = 12

loc = locals()

return loc


>>> func1()
{ }
>>> func2()
{'b': 12}


With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Implicit conversion to str in str.join method?

[Kirill Balunov]

Currently `str.join` raises `TypeError` if there are any non-string values
in iterable, including `bytes` objects. Is it an awful idea to implicitly
_cast_ elements in iterable to their `str` or `repr` representation? Was
this question adressed before?

As for me there are two valid points: On one hand "Explicit is beter than
implicit" and on the other "Practicality beats purity". May be I'm the only
one who finds that it is rather boring to write somehting like:

", ".join(str(i) for i in iterable)

when iterable contains non-string values, instead of:

", ".join(iterable)

I don't know how much overhead will yield for the case when iterable
contains only strings...and if it is possible to optimize this case. This
change is backward compatible, but as I wrote above, it can be perceived
badly and yield a huge overhead for general case that it is not even worth
discussing. What do you think?

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Implicit conversion to str in str.join method?

[Kirill Balunov]

>
> print(*iterable, sep=", ")


Thanks, I apologize :-) and why I always manage to find complicated ways...

With kind regards,
-gdg

2018-02-26 22:43 GMT+03:00 Chris Angelico :

> On Tue, Feb 27, 2018 at 6:38 AM, Kirill Balunov 
> wrote:
> > Currently `str.join` raises `TypeError` if there are any non-string
> values
> > in iterable, including `bytes` objects. Is it an awful idea to implicitly
> > _cast_ elements in iterable to their `str` or `repr` representation? Was
> > this question adressed before?
> >
> > As for me there are two valid points: On one hand "Explicit is beter than
> > implicit" and on the other "Practicality beats purity". May be I'm the
> only
> > one who finds that it is rather boring to write somehting like:
> >
> > ", ".join(str(i) for i in iterable)
> >
> > when iterable contains non-string values, instead of:
> >
> > ", ".join(iterable)
> >
> > I don't know how much overhead will yield for the case when iterable
> > contains only strings...and if it is possible to optimize this case. This
> > change is backward compatible, but as I wrote above, it can be perceived
> > badly and yield a huge overhead for general case that it is not even
> worth
> > discussing. What do you think?
>
> This would be a perfect job for map.
>
> ", ".join(map(str, iterable))
>
> If this is for display, you could also just print the values directly:
>
> print(*iterable, sep=", ")
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Questions about `locals` builtin

[Kirill Balunov]

 2018-02-27 2:57 GMT+03:00 Terry Reedy :

> The point of point 3 is that terminology and details would likely be
> different if Python were freshly designed more or less as it is today, and
> some things only make more or less sense in historical context. Learn what
> you need to know to write code that works.
>

Thank you, I'm fairly familiar with the scope and namespace concepts in
Python 3, and they are also very well described in the "Execution model"
https://docs.python.org/3/reference/executionmodel.html#execution-model,
for this special thanks to the person who wrote it ;-)

I started using Python with СPython 3.5 and I'm not familiar with the
Python 2 features. But since Python 2 got into our discussion, I still have
a question:

a.  Is this restriction for locals desirable in the implementation of
CPython in Python 3?
b.  Or is it the result of temporary fixes for Python 2?

Personally, I find the convenient functionality to update the local symbol
table inside a function, similar to `globals`. Of course, I do not have the
full picture and the difficulties with the flaws in implementing such
functionality in CPython3. On the other hand, I understand that this
additional dynamism as a whole may not be beneficial, and that local and
global variables are determined at function compilation time. At this
point, I only know one way to achieve this: `exec ('% s =% s'% (var_name,
var_val))`, which I find clumsy enough. Funny, contradictory thoughts in my
head :)

Calling surrounding function local names collectively 'nonlocals' is the
> result of months of bikeshedding.
>

Yes `nonlocals` is a cool fix in Python3.

  2018-02-27 3:25 GMT+03:00 Steven D'Aprano :

> Mostly because locals() predates MappingProxyType by many years, and also
> because that restriction doesn't apply to other implementations of Python
> such as Jython and IronPython.
>
> In CPython, the dict returned by locals() is a copy of the local
> namespace, so modifying the dict doesn't modify the real local variables.
>
> (Well, sometimes it does, but not always. The story in Python 2 is really
> complex.)

Yes, I understand all the more the documentation specifies *New in version
3.3: class.MappingProxyType.* I'm not saying that this should be a standard
for the Python language, especially in the context of what I wrote above.
But the Python documentation already contains links to the features of the
CPython implementation, (`id` for example). If the answer to the previous
question is "Yes, such a restriction is desirable in CPython because,
because, because ... and thereafter it is not planned to be changed." Then
I do not see why it can not be made more explicit by changing `dict` to`
types.MappingProxyType`. With the following change in the documentation:

"Note
The contents of this dictionary should be perceived as read-only mapping
and should not be modified; The returned mapping type is
implementation-dependent: changes may not affect the values of local
variables used by the interpreter or the returned object may not support
item assignment.

CPython implementation detail: The returned object is
`types.MappingProxyType` a read-only proxy of the current local symbol
table."

p.s.: Steven, this question was somewhat inspired by yours "Is there are
good DRY fix for this painful design pattern?"

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Questions about `locals` builtin

[Kirill Balunov]

 2018-02-27 14:59 GMT+03:00 Ned Batchelder :

> On 2/27/18 3:52 AM, Kirill Balunov wrote:
>
>> a.  Is this restriction for locals desirable in the implementation of
>> CPython in Python 3?
>> b.  Or is it the result of temporary fixes for Python 2?
>>
>
> My understanding is that the behavior of locals() is determined mostly by
> what is convenient for the implementors, so that they can keep regular code
> running as quickly as possible.  The answer to the question, "why can't we
> make locals() work more like I expect?" is, "because that would make things
> slower."
>

Ok, but I in this case what is the benefit in Python 3.3+ in returning a
copy of dict instead of MappingProxy?

Personally, I find the convenient functionality to update the local symbol
>> table inside a function, similar to `globals`.
>>
>
> Can you show us an example of why you would want to update locals through
> locals()?  There might be more natural ways to solve your problem.
>
>
The example from "Is there are good DRY fix for this painful design
pattern?" https://mail.python.org/pipermail/python-list/2018-
February/731218.html

class Foo:
def __init__(self, bashful, doc, dopey, grumpy,
   happy, sleepy, sneezy):
self.bashful = bashful  # etc

def spam(self, bashful=None, doc=None, dopey=None,
   grumpy=None, happy=None, sleepy=None,
   sneezy=None):
if bashful is None:
bashful = self.bashful
if doc is None:
doc = self.doc
if dopey is None:
dopey = self.dopey
if grumpy is None:
grumpy = self.grumpy
if happy is None:
happy = self.happy
if sleepy is None:
sleepy = self.sleepy
if sneezy is None:
sneezy = self.sneezy
# now do the real work...

def eggs(self, bashful=None, # etc...
   ):
if bashful is None:
bashful = self.bashful
# and so on

and with the possibility to update  `locals` the `spam` can be rewritten
with:

def spam(self, bashful=None, doc=None, dopey=None,
   grumpy=None, happy=None, sleepy=None,
   sneezy=None):
loc = locals()
for key, val in loc.items():
if val is None:
loc[key] = getattr(self, key)

In fact, I do not have a strict opinion on this matter. And I'd rather be
glad that Pнthon was less dynamic in some moments in favor of some
optimizations.


With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there are good DRY fix for this painful design pattern?

[Kirill Balunov]

This validation can be also done with the use of annotations, while I find
it super awful, I put this for one more example:

from functools import wraps
def validate(func):
@wraps(func)
def _wrap(self, *args, **kwargs):
variables = func.__annotations__.keys()
kwargs.update(zip(variables, args))
for var in variables - kwargs.keys():
kwargs[var] = getattr(self, var)
return func(self, **kwargs)
return _wrap


class Foo:
def __init__(self, bashful, doc, dopey, grumpy,
   happy, sleepy, sneezy):
self.bashful = bashful
self.doc = doc
self.dopey = dopey
self.grumpy = grumpy
self.happy = happy
self.sleepy = sleepy
self.sneezy = sneezy

@validate
def spam(self, bashful:'Any'=None, doc:'Any'=None, dopey:'Any'=None,
   grumpy:'Any'=None, happy:'Any'=None, sleepy:'Any'=None,
   sneezy:'Any'=None):

return bashful, doc, dopey, grumpy, happy, sleepy, sneezy


a = Foo(1,2,3,4,5,6,7)

a.spam(grumpy='Hello')

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is there are good DRY fix for this painful design pattern?

[Kirill Balunov]

Of course you can do the same without annotations, but with the
introduction of private attribute while your API it is under active
development:

from functools import wraps
def validate(func):
@wraps(func)
def _wrap(self, *args, **kwargs):
variables = self._vars   # Here
kwargs.update(zip(variables, args))
for var in variables - kwargs.keys():
kwargs[var] = getattr(self, var)
return func(self, **kwargs)
return _wrap

class Foo:
def __init__(self, bashful, doc, dopey, grumpy,
   happy, sleepy, sneezy):
self.bashful = bashful
self.doc = doc
self.dopey = dopey
self.grumpy = grumpy
self.happy = happy
self.sleepy = sleepy
self.sneezy = sneezy
self._vars = set(v for v in self.__dict__ if not
v.startswith('_'))   # should be deleted when finish

@validate
def spam(self, bashful=None, doc=None, dopey=None,
   grumpy=None, happy=None, sleepy=None,
   sneezy=None):

return bashful, doc, dopey, grumpy, happy, sleepy, sneezy

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Ways to make a free variable local to a function?

[Kirill Balunov]

Hi,

At the moment, in order to slightly speed up the function in Python, free
variables are passed as local variables to the function, thereby getting
rid of extra look ups. For example, for the following function, I
especially do not use list comprehension) and therefore maybe it's not the
best example:

def func(numb):
res = []
for i in range(numb):
res.append(int(i) + float(i))
return res

You can get rid of additional look ups, in the following ways:


# 1. By passing through local variable's default values

def func_local_1(numb, _int = int, _float = float, _range = range):
res = []
for i in _range(numb):
res.append(_int(i) + _float(i))
return res


# 2. Through importing them into the function scope

def func_local_2(numb):
from builtins import int, float, range
res = []
for i in range(numb):
res.append(int(i) + float(i))
return res


# 3. With the help of various types of closures, version 1

def func_closure_1(numb):
_int = int
_float = float
_range = range
def inner(numb):
res = []
for i in _range(numb):
res.append(_int(i) + _float(i))
return res
return inner(numb)


# 4. With the help of various types of closures, version 2

def func_closure_2(numb):
from builtins import int, float, range
def inner(numb):
res = []
for i in range(numb):
res.append(int(i) + float(i))
return res
return inner(numb)

Option 1 allows you to achieve the maximum result for both small and a
large `numb` values. Option 2 yields a significant overhead, when it is
required to call function many times with a small number of iterations. For
option 3 and 4, notes are the same, but since they are implemented through
closures they give additional small overhead. In case of big `numb` (many
iterations, many look ups) these options give a gain of ~10%.

Option 1 and 3 I do not like because:
 - syntax highlighting stops working
 - the signature function is greatly distorted
 - additional typing (especially with type annotations)

I like options 2 and 4, but they yield a significant overhead, for a small
number of iterations.

Actually, I have the following question:

1. Is there any other way to make the variable local to the function?
 a. When you compile (define) a function...
 b. Inject into an already existing function through decorator...(is it
possible?)

p.s.:

I had the following idea, maybe it was already discussed, the possibility
of setting _static_ variables for functions, with the following syntax:

def func(numb):
static int, float, range
res = []
for i in range(numb):
res.append(int(i) + float(i))
return res

Where identifiers for `static` should correspond to free variables for a
function, they must be defined at compile time (like for default arguments)
and can not be changed inside the function scope.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Do not promote `None` as the first argument to `filter` in documentation.

[Kirill Balunov]

This thought occurred to me several times, but I could not decide to write.
And since `filter` is a builtin, I think this change should be discussed
here, before opening an issue on bug tracker.

I propose to delete all references in the `filter` documentation that the
first argument can be `None`, with possible depreciation of `None` as the
the first argument - FutureWarning in Python 3.8+ and deleting this option
in Python 4. Personally, regarding the last point - depreciation, I do not
see this as a great necessity, but I do not find that the option with `None`
should be offered and suggested through the documentation. Instead, it is
better to show an example with using `filter(bool, iterable)` which is
absolutely
equivalent, more readable, but a little bit slower.

%timeit [*filter(None, range(10))]
503 ns ± 0.259 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)

%timeit [*filter(bool, range(10))]
512 ns ± 1.09 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)

Currently documentation for `None` case uses `identity function is
assumed`, what is this `identity` and how it is consistent with
truthfulness?

In addition, this change makes the perception of `map` and `filter` more
consistent,with the rule that first argument must be `callable`.

I see only one moment with `None`, since `None` is a keyword, the behavior
of `filter(None, iterable)` is alsways guaranteed, but with `bool` it is
not. Nevertheless, we are all adults here.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ways to make a free variable local to a function?

[Kirill Balunov]

2018-03-05 17:34 GMT+03:00 Chris Angelico :

> In theory, the CPython bytecode compiler (don't know about other
> Python implementations) could just add these as constants. They'd then
> be bound at either compile time or function definition time (by
> default the former, I think, but the latter would be more useful), and
> be looked up as quickly as locals. I'm not sure how useful this would
> be, though.
>

With some assumptions, It will be useful for every function call:-)

If PEP 572 [1] were to be accepted, you could do something like this:
>
> def func(numb):
> if ((int as int), (float as float)):
> res = []
> for i in range(numb):
> res.append(int(i) + float(i))
> return res
>
> Syntactically a bit clunky, but keeps everything inside the function,
> and DOES create local variables. Not sure it's better than your other
> options, but it is another option.
>

While I'm +0.5 on yours PEP 572 idea, especially in `while` and `if`
statements, this example is an overuse of the proposed syntax ;-) Also it
will add an overhead on every function call, and as you said  -
"Syntactically a bit clunky".

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Ways to make a free variable local to a function?

[Kirill Balunov]

 2018-03-05 21:44 GMT+03:00 Terry Reedy :

> Yes, what we really want for this sort of thing are unrebindable local
> constants.  A simple syntax change could do it.
>
>  def func_local_1(numb; int = int, float = float, range = range):
>
> The binding after ';' belong in the header because they should be done
> once.
>
> They'd then
>> be bound at either compile time or function definition time (by
>> default the former, I think, but the latter would be more useful), and
>> be looked up as quickly as locals. I'm not sure how useful this would
>> be, though.
>>
>
> I believe that the occasional practice of re-binding built-in names to
> locals can be shown to speed up loops run enough times.


Yes "_unrebindable local constants_" it is what I was thinking about. But I
do not agree that they must be passed through arguments, because they
should be somewhat static for a function, and could not be changed by any
means after function is compiled.
Alternative option, more dynamic - to allow injecting local variables into
the function via some interface. Currently, there is no such _feature_ in
Python, at least I do not know. There was _somewhat_ related discussion
about how to change the locals of a frame (https://bugs.python.org/
issue1654367) by making `frame.f_locals` writable, but it seems that it is
dead.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: using OpenGL on windows 11

[Kirill Ratkin]

Hi!

Your machine remembers but you probably use different virtual envs.

PyCharm, as I remember, creates its own venv (per project maybe).

It's better to remove python interpreter installed from MS application 
market and download python installer from python.org.


Install it as user or system. If you install python as user the 
interpreter files and standard libs will be in your profile 
(%USERPROFILE%\AppData\Local\Programs\...)


Then add path to python.exe to system or user PATH environment variable 
(using Windows GUI or thru CMD (command setx)).


(as I remember installer can do this task for you)

Now you have python interpreter installed and visible from command line 
(btw it's better to install visual studio build tools as well).


Open CMD or PowerShell and try command 'python'. If it works - Ok.

Then create virtual environment somewhere (for example in your home 
profile (%USERPROFILE%)): python -m venv venv


The directory C:\Users\\venv appears.

From CMD or PowerShell do: venv\Scripts\activate

You see command prompt changed and python virtual environment activated.

Now you can install any python stuff using pip. All new packages will be 
in 'venv\Lib\site-packages' but not in standard Lib folder.


Start PyCharm, select recently created venv (unfortunately I can't help 
you with menu path of python interpreter settings inside PyCharm because 
don't use it now).


But as for me VS Code is better. Try it. :)


// BR (KR)

31.12.2021 2:23, vrg bls пишет:

   Hi! I am very new to Python admittedly, but did try several options
regarding troubleshooting to get OpenGL to run with Python. I am using
PyCharm as my interface, did try installing setup tools and have
reinstalled using pip install function a few times. I did notice my machine
seems to be having trouble remembering that I did install python and keeps
prompting me to install from MS app store. I did try to do this but again
did not register the installation of Python. I am able to open a window in
PyCharm and get other functions to work but then get the Module not
Installed error for OpenGL. I even tried the setuptools install and
easy_install never popped up as an option. is this a windows 11 issue? does
anything about this sound familiar?
Thank you, and sorry if this has already been answered in a forum
somewhere, I did look and could not find it



--
https://mail.python.org/mailman/listinfo/python-list

Re: How to make a type of a C extension compatible with mypy

[Kirill Ratkin]

Hi Marco,

It seems issue is about file py.typed and PEP-561. As I understand 
issue's description you don't need to do it in C but some work in Python 
files need to done. Maybe this link helps 
(https://blog.whtsky.me/tech/2021/dont-forget-py.typed-for-your-typed-python-package/)


// BR (KR)

01.01.2022 21:49, Marco Sulla пишет:

I created a type in a C extension, that is an immutable dict. If I do:

a: mydict[str, str]

it works. But it doesn't work with mypy, as signalled to me by an user:

https://github.com/Marco-Sulla/python-frozendict/issues/39

How can I make it work? I don't know what he means with annotating
methods, and furthermore I suppose I can't do this in C.

--
https://mail.python.org/mailman/listinfo/python-list

RE: Gunicorn - HTTP and HTTPS in the same instance?

[Kirill Ratkin]

Hi.
You probably can solve issue on Gunicorn side. But afaik better solution is to 
use http proxy before Gunicorn. This proxy accepts https connection and proxy 
requests to Gunicorn instances as plain http.

This approach gives you:
a) Monitoring on network layer (tcpdump/wireshark shows you req/res on Gunicorn 
instance)
b) Scalability (proxy can spread traffic on several Gunicorn instances)
c) Maintenance (you can gracefully shutdown/restart Gunicorn instances one by 
one) 
d) Security (For example SSL certificate is configured in proxy only. There are 
another useful features which such proxy can do: simple authentication, 
ddos/fail2ban and so on)

Quite often NGINX is better choice for such proxy. But apache is good as well.

Best regards.
Kirill

От: Skip Montanaro
Отправлено: 7 января 2022 г. в 21:54
Кому: Python
Тема: Gunicorn - HTTP and HTTPS in the same instance?

Hopefully some Pythonistas are also Gunicornistas. I've had little success
finding help with a small dilemma in the docs or in other more specific
sources.

I'm testing out a new, small website. It is just Gunicorn+Flask. I'd like
to both listen for HTTP and HTTPS connections. Accordingly, in my config, I
have the Gunicorn process bind to both ports 80 and 443 if running as root:

if IAM_ROOT:
bind = [
'0.0.0.0:443',
'0.0.0.0:80',
]
else:
bind = [
'0.0.0.0:8080',
]

Gunicorn listens on both ports, but insists on SSL/TLS chit chat over port
80, not just port 443 (which seems to work okay). Is there some magic
incantation to get it to just talk HTTP on port 80, or will I need to spin
up two instances? (The non-root config works fine - plain old HTTP over
port 8080.)

Thx,

Skip
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Script profiling details

[Kirill Ratkin]

   Hi Joseph,
   **
   Did you try scalene profiler?
   Recently I solved a similar problem and scalene really helped me.
   **
   It creates a well-formed HTML report, and you can optionally
   enable/disable report about
   a code outside your project, for example - standard library.
   **
   Here it is - [1]https://pypi.org/project/scalene/
   **
   10.01.2022, 22:28, "Joseph L. Casale" :

 I am trying to track down a slow script startup time. I have executed
 the
 script using `python -m cProfile -o profile /path/script.py` and read
 through
 the results, but the largest culprit only shows various built-ins.

 I expected this given the implementation, but I was hoping to get some
 finer details so I can track down the specific module or at least the
 specific
 file so I have a place to start reviewing code for optimizations.

 Is there something I can use to analyze the existing profile output or
 to generate
 it with more feedback?

 Thanks,
 jlc

 --
 [2]https://mail.python.org/mailman/listinfo/python-list

References

   Visible links
   1. https://pypi.org/project/scalene/
   2. https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: symlinks with python3 http.server.CGIHTTPRequestHandler

[Kirill Ratkin]

Hi

Maybe you have some restrictions on file system level. Some selinux for 
example.



I try similar steps on my local 'linux mint' and ... linked script is 
called my http.server without errors.



Here is my 'tree':

├── cgi-bin
│   └── test.py -> ../orig.py
└── orig.py

All files are executable and test.py is link to orig.py which is in one 
directory level up:


$ ls -Rla
.:
total 16
drwxrwxr-x  3 kirill kirill 4096 Jan 11 14:04 .
drwxrwxrwt 23 root   root   4096 Jan 11 14:11 ..
drwxrwxr-x  2 kirill kirill 4096 Jan 11 14:03 cgi-bin
-rwxrwxr-x  1 kirill kirill   31 Jan 11 14:04 orig.py

./cgi-bin:
total 8
drwxrwxr-x 2 kirill kirill 4096 Jan 11 14:03 .
drwxrwxr-x 3 kirill kirill 4096 Jan 11 14:04 ..
lrwxrwxrwx 1 kirill kirill   10 Jan 11 14:03 test.py -> ../orig.py

I do 'curl' request:

curl -v http://0.0.0.0:8000/cgi-bin/test.py

And http.server get log:

$ python3 -m http.server --cgi 8000
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...
127.0.0.1 - - [11/Jan/2022 14:40:19] "GET /cgi-bin/test.py HTTP/1.1" 200 -


On 1/10/22 22:10, Nat Taylor wrote:

python3 -m http.server --cgi 8090

--
https://mail.python.org/mailman/listinfo/python-list

Re: About Python Compressed Archive or Binaries

[Kirill Ratkin]

Hi,

Yes, this is good question for Windows users.

Of course, you can download installer exe-file -> do installation -> 
pack directory with python interpreter to zip (for example, or 7z) -> 
copy archive file to another place/computer and unpack.


But it will not work out of box because original installer modifies 
resources in MZ file and path to stdlib is there.


So just to use interpreter from that archive file you need to open 
python.exe file and fix it (in any binary/hex editor).


This simple procedure but ... anyway ... I agree with Sina.

It would be nice to have just zip file with python interpreter (not 
executable installer), unpack it anywhere, add path  to this 'anywhere' 
to PATH, and use it.


Java/DotNet/Go have this option. But python - not.

And question is - why?


On 1/17/22 18:37, Sina Mobasheri wrote:

Java offers download JDK as Compressed Archive or NodeJS offers download Node 
as Binaries both give us a compressed file for Linux and windows that we can 
just unzipped it and put in a custom directory and set some environment 
variables and start working


I'm aware that Python also have something called Embedded Zip for Windows and 
nothing like that for Linux as far as I know, and I think this Embedded Zip is 
not something that the user wants to work with that directly it's for embedding 
in a C++ application, so it's not the same as options that Java and NodeJS 
offering


My question is why is Python haven't an option for downloading as Compressed 
Archive?
Is it's due to a technical issue? political reasons? or is it just simply 
because nobody has thought of doing it?


--
https://mail.python.org/mailman/listinfo/python-list

Re: Why There Is No Python Compressed Archive or Binaries ?

[Kirill Ratkin]

Hi Grant

Hmmm...  definitly you are right in particular solution.

But Ok, let me show example.


I often use Go in parallel with Python and sometimes I switch between 
Windows/Linux also. On both systems I just download Go toolset as 
tarball/zip file and unpack in place where I like.


The point here is Go toolset officially distributed as tarball/zip for 
all supported operating system. This is not PortableGo or WinGo or some 
anther third party Go distribution. This is one of supported way do get 
Go toolset.


On Windows I put toolset on separate drive 'D:\Go' and on linux - 
$HOME/.local/go


And I set up several environment variables (doing 'setx' on Windows and 
edit .profile on linux): GOPATH, GOROOT, GOCACHE, ... and modify my PATH.


Now I can build any Go project. I don't care about which Go compiler was 
set on OS (Linux or Windows) before. I just unpack tarball/zip in place 
where I have permissions and use it.



I take Go just for example. In same way you can unpack and use Java SDK 
and DotNet SDK. All these toolsets have option (provided by vendor) to 
be downloaded as compressed file.



You are absolutely right. It's easy to google and find something like 
winpython. But I'm sure there are reasons why www.python.org doesn't 
provide this.



On 1/18/22 00:13, Grant Edwards wrote:

On 2022-01-17, Sina Mobasheri  wrote:


Yes sure, actually I can continue working and developing with python
without this feature no problem but it's something that I like and
I'm just curious about it, about why Python doesn't implement this
kind of installation

You talk about "Python" implementing something. Python is a language.

If what you want hasn't been implmented, it's because there haven't
been any _people_ who have wanted it enough to do it. I spent 90
seconds googling and found that what you wanted has been implemented a
couple times for Windows. There was "Portable Python," which appears
to have been abandonded.

There's also WinPython  which seems to be
active.  AFAICT, you just unzip it and run it (nothing needs to be
"installed"). It says you can even move that directory to another
machine and run it there if you want.

Both of those were for Windows.

It's probably never been done for Linux because Linux distros pretty
much all come with Python already installed by default, and it's
usually trivial to install alternative versions as well (and keep them
all updated) via whatever package manager the Distro uses.

--
Grant

--
https://mail.python.org/mailman/listinfo/python-list

Re: Unpacking lists in a f string

[Kirill Ratkin]

Hi.

Try this:

f"foo {','.join([f'{a} {b}' for a,b in list(zip(l1,l2))])} bar"

09.02.2022 21:13, Paulo da Silva пишет:

Às 02:17 de 09/02/22, Paulo da Silva escreveu:

Hi!

Let's say I have two lists of equal length but with a variable number 
of elements. For ex.:


l1=['a','b','c']
l2=['j','k','l']

I want to build a string like this
"foo a j, b k, c l bar"

Is it possible to achieve this with f strings or any other 
simple/efficient way?


Thanks for any help/comments.


Thank you for your responses.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Long running process - how to speed up?

[Kirill Ratkin]

Hi,

How I understand your script starts another script and should wait until 
second one completes its job. Right?


If so you have several options depend on how your first script is written.

If your script is async then ... there is good asyncio option

proc = await asyncio.create_subprocess_shell(
f"{execcmd}{execargs}", stdin=None, stdout=None
)
await proc.wait() In this way you can starn many workers and you don't neet to 
wait then in sync manner.


Anyway, just please give more info about what problem you face.

19.02.2022 14:28, Shaozhong SHI пишет:

I have a cvs file of 932956 row and have to have time.sleep in a Python
script.  It takes a long time to process.

How can I speed up the processing?  Can I do multi-processing?

Regards,

David

--
https://mail.python.org/mailman/listinfo/python-list

Re: virtualenv and make DESTDIR=

[Kirill Ratkin]

Hi,

As far I know there is tool rpmvenv 
(https://github.com/kevinconway/rpmvenv).


Try it, maybe ot helps.

04.03.2022 16:03, Hartmut Goebel wrote:

Hi,

How can I make installing a virtual environment honor DESTDIR? How can 
I install a virtual environment in $(DESTDIR)$(PREFIX), which behaves 
as being set-up in $(PREFIX)? (Of course, this virtual environment can 
not be used. My aim is to ship it as part of a rpm package)


In Makefiles is good practice to honor DESTDIR in the "install" 
target, like this


install:
    install -t $(DESTDIR)$(PREFIX)/bin build/bin/my-tool

Now when running

    python3 -m venv $(DESTDIR)$(PREFIX)

all paths in this virtual environment refer to $(DESTDIR)$(PREFIX) 
instead of just $$(PREFIX)


Any ideas?


Background:

More about DESTDIR: 
https://www.gnu.org/prep/standards/html_node/DESTDIR.html


Following Redhat's commendations, I want to install my (somewhat 
complex) software into /opt/my-software. To make it easier for users 
to use the software, my idea was to setup a virtual environment in 
/opt/my-software. Thus users can easily use 
/opt/my-software/bin/python and have the library provided by 
my-software available. My Software also includes some scripts, which 
will also reside in /opt/my-software/bin and refer to 
/opt/my-software/bin/python. This will avoid to require users to set 
up PYTHONPATH when thy want to use MY Software.




--
https://mail.python.org/mailman/listinfo/python-list

Re: Do not promote `None` as the first argument to `filter` in documentation.

[Kirill Balunov]

2018-03-06 14:17 GMT+03:00 Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info>:

> On Tue, 06 Mar 2018 11:52:22 +0300, Kirill Balunov wrote:
>
> > I propose to delete all references in the `filter` documentation that
> > the first argument can be `None`, with possible depreciation of `None`
> > as the the first argument - FutureWarning in Python 3.8+ and deleting
> > this option in Python 4.
>
> Even if we agreed that it is unfortunate that filter accepts None as an
> argument, since it does (and has done since Python 1.0) there is nothing
> to be gained by deprecating and removing it.
>
> Deprecating and removing it will break code that currently works, for no
> good reason; removing the documentation is unacceptable, as that makes it
> too difficult for people to find out what `filter(None, values)` does.
>

As I wrote, __possible depreciation__, I also do not see the point of just
breaking someone's code. But I didn't see any benefit to explicitly promote
`filter(None, iterable)` form in the documentation as a good style.


> > Instead, it is better to show an example with using
> > `filter(bool, iterable)` which is absolutely
> > equivalent, more readable, but a little bit slower.
>
> So long as `filter(None, ...)` is still documented, I don't mind what
> example is given.
>
> But the idiom `filter(None, ...)` is an old, common idiom, very familiar
> to many people who have a background in functional programming.
>

While this form familiar and common idiom for those who are familiar with
Python from versions < 2.3, before `bool` type was introduced. It looks
kinky for newcomers and not obvious at a glance. In functional programming
we use a predicate, and `None` does not match predicate definition, while
`bool` does!


> It is unfortunate that filter takes the arguments in the order it does.
> Perhaps it would have been better to write it like this:
>
> def filter(iterable, predicate=None):
> ...
>
>
> Then `filter(values, None)` would be a standard Python idiom, explicitly
> saying to use the default predicate function. There is no difference to
> `filter(None, values)` except the order is (sadly) reversed.
>

If such a form was in Python, I probably would agree with you. Although in
its present form I like it a lot more and find it more intuitive.

> Currently documentation for `None` case uses `identity function is
> > assumed`, what is this `identity` and how it is consistent with
> > truthfulness?
>
> The identity function is a mathematical term for a function that returns
> its argument unchanged:
>
> def identity(x):
> return x
>
> So `filter(func, values)` filters according to func(x); using None
> instead filters according to x alone, without the expense of calling a do-
> nothing function:
>
> # slow because it has to call the lambda function each time;
> filter(lambda x: x, values)
>
> # fast because filter takes an optimized path
> filter(None, values)
>


> Since filter filters according to the truthy or falsey value of x, it
> isn't actually necessary to call bool(x). In Python, all values are
> automatically considered either truthy or falsey. The reason to call
> bool() is to ensure you have a canonical True/False value, and there's no
> need for that here.


I went over a bit with the question what is identity function :) But I have
a feeling that I perceive all of the above quite the contrary in the
context of a `filter` function. And since filter filters according to the
truthy or falsey value of x. `None` and `bool` should behave totally
equivalent under the hood and I'm 99% sure that it is so.


> So the identity function should be preferred to bool,
> for those who understand two things:
>
> - the identity function (using None as the predicate function)
>   returns x unchanged;
>

Sorry, but how does the above relates to the `filter` discussion?


>
> - and that x, like all values, automatically has a truthy value in a
>   boolean context (which includes filter).
>
>
Yes, and that is why there is no point to `None` since they will do the
same thing in context of `filter` function.


> > In addition, this change makes the perception of `map` and `filter` more
> > consistent,with the rule that first argument must be `callable`.
>
> I consider that a flaw in map. map should also accept None as the
> identity function, so that map(None, iterable) returns the values of
> iterable unchanged.
>
> def map(function=None, *iterables):
> if len(iterables) == 0:
> raise TypeError("map() must have at least two arguments.")
> if function is None:
> if len(iterables) > 1:
> return zip(*iterables)
> 

Re: Do not promote `None` as the first argument to `filter` in documentation.

[Kirill Balunov]

2018-03-06 13:18 GMT+03:00 Chris Angelico :

> The identity function is:
>
> filter(lambda x: x, range(10))
>
> How is it consistent with truthiness? Exactly the same way the
> underlying object is. There's no requirement for the predicate
> function to return True or False - it's perfectly acceptable, for
> instance, to do this:
>
> filter(lambda x: x % 3, range(10))
>
> to eliminate all multiples of three.
>

Yes there is no reason to return True and False, but in the case of `None`
and `bool` under the hood there will be no difference and the form with
`bool` is much more readable.


>
> That said, though, any use of filter() that involves a lambda function
> should probably become list comps or genexps, so filter itself should
> only be used when there really IS a pre-existing function that does
> the job.


Filter is generally faster than list comprehension or generators.

%timeit [*filter(lambda x: x % 3, range(1000))]
100 µs ± 16.4 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)

f = lambda x: x % 3

%timeit [*(f(i) for i in range(1000))]
132 µs ± 73.5 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)

%timeit [f(i) for i in range(1000)]
107 µs ± 179 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)


> So, for instance, you could strip out every occurrence of the
> string "0" with:
>
> filter(int, list_of_strings)
>
> And that still depends on the normal Python rules for boolification.
> If that's valid, then it should be just as viable to say
> "filter(identity-function, ...)", which is spelled "filter(None,
> ...)".
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Do not promote `None` as the first argument to `filter` in documentation.

[Kirill Balunov]

2018-03-06 16:51 GMT+03:00 Chris Angelico :

> On Wed, Mar 7, 2018 at 12:23 AM, Kirill Balunov 
> wrote:
> > Filter is generally faster than list comprehension or generators.
> >
> > %timeit [*filter(lambda x: x % 3, range(1000))]
> > 100 µs ± 16.4 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)
> >
> > f = lambda x: x % 3
> >
> > %timeit [*(f(i) for i in range(1000))]
> > 132 µs ± 73.5 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)
> >
> > %timeit [f(i) for i in range(1000)]
> > 107 µs ± 179 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)
> >
>
> These don't do the same thing, though. A more comparable comprehension is:
>
> [i for i in range(1000) if i % 3]
>
> rosuav@sikorsky:~$ python3 -m timeit '[i for i in range(1000) if i % 3]'
> 1 loops, best of 5: 34.5 usec per loop
> rosuav@sikorsky:~$ python3 -m timeit '[*filter(lambda x: x % 3,
> range(1000))]'
> 5000 loops, best of 5: 81.1 usec per loop
>
> And my point about comprehensions was that you do NOT use a pointless
> function for them - you just have inline code. If there is a
> pre-existing function, sure! Use it. But when you use filter or map
> with a lambda function, you should probably use a comprehension
> instead.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Thank you, I did not understand you at first, now everything is clear. In
this sense of `x % 3`, I fully agree with you.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Do not promote `None` as the first argument to `filter` in documentation.

[Kirill Balunov]

2018-03-06 16:35 GMT+03:00 Chris Green :

> It's 'deprecation', depreciation is something quite different.  People
> replying have spelt it correctly so you might possibly have noticed I
> thought/hoped.
>
> ... and it does matter a bit because it's not just a mis-spelling, the
> word you are using has its own meaning and could thus cause confusion.
>
> ... and, yes, I know it's a very common and easily made mistake. :-)
>
>
I did not ;) Thank you!

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Do not promote `None` as the first argument to `filter` in documentation.

[Kirill Balunov]

2018-03-06 16:58 GMT+03:00 Jason Friedman :

>
> as a ordinary Python user I'd be interested in improvements to the
> documentation, including suggestions on real-world usage.
>

I'm just an ordinary user, just like you :)


> Kirill, taking deprecation/removal off the table, what changes would you
> recommend to the documentation?
>

My English is about basic level, so you may need to fix the spelling. But I
would write as follows:


filter(function, iterable)
Construct an iterator from those elements of iterable for which function
returns truthy values. iterable may be either a sequence, a container which
supports iteration, or an iterator.

Note that filter(function, iterable) is equivalent to the generator
expression (item for item in iterable if function(item)). In cases when
function corresponds to a simple lambda function a generator expression
should be preferred. For example, when it is necessary to eliminate all
multiples of three (x for x in range(100) if x % 3) should be used, instead
of filter(lambda x: x % 3, range(100))

See itertools.filterfalse() for the complementary function that returns
elements of iterable for which function returns false.

Note: For some historical reasons as the first argument you can use None
instead of function, in this case the identity function is assumed. That
is, all elements of iterable that are false are removed which is equivalent
to (item for item in iterable if item). Currently, for the same purpose the
preferred form is `filter(bool, iterable)`.

p.s.:
maybe _function_ should be changed to _callable_.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Do not promote `None` as the first argument to `filter` in documentation.

[Kirill Balunov]

2018-03-06 17:55 GMT+03:00 Chris Angelico :

> On Wed, Mar 7, 2018 at 1:48 AM, Kirill Balunov 
> wrote:
> > Note: For some historical reasons as the first argument you can use None
> > instead of function, in this case the identity function is assumed. That
> > is, all elements of iterable that are false are removed which is
> equivalent
> > to (item for item in iterable if item). Currently, for the same purpose
> the
> > preferred form is `filter(bool, iterable)`.
> >
>
> I'd prefer to word it something like:
>
> If the first argument is None, the identity function is assumed. That
> is, all elements of the iterable that are false are removed; it is
> equivalent to (item for item in iterable if item). It is approximately
> equivalent to (but faster than) filter(bool, iterable).
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>

I do not want to seem rude and stubborn, but how much faster is it to
highlight or emphasize it:

from random import randint
for i in [1, 10, 100, 1000, 1, 10]:
ls = [randint(0,1) for _ in range(i)]
%timeit [*filter(None, ls)]
%timeit [*filter(bool, ls)]
print()

272 ns ± 0.0346 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
282 ns ± 0.0714 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)

283 ns ± 0.0645 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
296 ns ± 0.116 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)

1.4 µs ± 1.32 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)
1.41 µs ± 4.05 ns per loop (mean ± std. dev. of 7 runs, 100 loops each)

14.7 µs ± 40.1 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)
14.7 µs ± 23.2 ns per loop (mean ± std. dev. of 7 runs, 10 loops each)

137 µs ± 186 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)
137 µs ± 24.7 ns per loop (mean ± std. dev. of 7 runs, 1 loops each)

1.32 ms ± 285 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)
1.32 ms ± 908 ns per loop (mean ± std. dev. of 7 runs, 1000 loops each)

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Do not promote `None` as the first argument to `filter` in documentation.

[Kirill Balunov]

2018-03-06 17:55 GMT+03:00 Chris Angelico :

> If the first argument is None, the identity function is assumed. That
> is, all elements of the iterable that are false are removed; it is
> equivalent to (item for item in iterable if item). It is approximately
> equivalent to (but faster than) filter(bool, iterable).
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>

If you look in C source for `filter_next`
https://github.com/python/cpython/blob/5d92647102fac9e116b98ab8bbc632eeed501c34/Python/bltinmodule.c#L593,
there is a line:

int checktrue = lz->func == Py_None || lz->func == (PyObject
*)&PyBool_Type;

So the only difference between `filter(None, ls`) and `filter(bool, ls)` is
LOAD_NAME vs LOAD_CONST and that `None` is checked before than `bool`.


With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: check if bytes is all nulls

[Kirill Balunov]

2018-04-01 20:55 GMT+03:00 Arkadiusz Bulski :

> What would be the most performance efficient way of checking if a bytes is
> all zeros?


Try `not any(key)` ;)

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: check if bytes is all nulls

[Kirill Balunov]

2018-04-01 22:03 GMT+03:00 Kirill Balunov :

>
>
> 2018-04-01 20:55 GMT+03:00 Arkadiusz Bulski :
>
>> What would be the most performance efficient way of checking if a bytes is
>> all zeros?
>
>
> Try `not any(key)` ;)
>
>
Sorry, I don't timed it before I posted. In reality, it is far from the
fastest, it is 10 times slower than `==`, but I like it:)

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Python aliases under Windows?

[Kirill Balunov]

Perhaps this is a silly question but still...There is PEP 394 "The "python"
Command on Unix-Like Systems" which I find very reasonable, no matter how
it is respected. Why was not _somewhat_ the same done for Windows?

Sometimes I use, especially in IPython, to run externally:
! python3 -m dis 
! python3 -m timeit ...
! python3 -m pip install ...

And to make this work the same under Windows, the first step which I do
after installation is to copy `python.exe` and rename it to `python3.exe`
(for python 2.7 copy `python.exe` and rename it to `python2.exe`). May be
there is a better way to do this under Windows, I would like to know?  This
copy-rename works for me, but it will not work for someone who does not
have administrative rights.

p.s.: I know there is a `py` launcher under Windows, but is does not help
in this situation.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python aliases under Windows?

[Kirill Balunov]

2018-04-03 12:27 GMT+03:00 Chris Angelico :

>
> Why doesn't it? That's what its job is.
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Because it affects my workflow under Windows and Linux. I have two options:
1. To wriie a shell script for `py` under Linux.
2. To copy-rename to python3 under Windows.

Both are easy, but a little bit strange to do.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python aliases under Windows?

[Kirill Balunov]

2018-04-03 16:15 GMT+03:00 Ian Kelly :

> Creating python2.bat and python3.bat instead would take up less
> additional disk space and would not need to be modified every time you
> reinstall a new release of the same minor version.
>
>
Thank you!


> > This
> > copy-rename works for me, but it will not work for someone who does not
> > have administrative rights.
>
> They could put them under their user folder and add the folder to
> their path, although that's creeping into power user territory. Then
> again, they *are* using IPython...
>
> > p.s.: I know there is a `py` launcher under Windows, but is does not help
> > in this situation.
>
> I don't understand. Is 'py -3' that much harder to type than 'python3'
> when running in Windows?
>

IPython is  only one of the examples, instead you can substitute Jupyter,
subprocess. As I wrote before:


> I have two options:
> 1. To wriie a shell script for `py` under Linux.
> 2. To copy-rename to python3 under Windows.
> Both are easy, but a little bit strange to do.
>

which seems unnecessary. There is already `pip.exe`, `pip3.exe`,
`pip3.6.exe` in Scripts sub-folder which in my opinion solve the same
problem.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python aliases under Windows?

[Kirill Balunov]

2018-04-03 16:45 GMT+03:00 Paul Moore :

> On 3 April 2018 at 10:24, Kirill Balunov  wrote:
> > Perhaps this is a silly question but still...There is PEP 394 "The
> "python"
> > Command on Unix-Like Systems" which I find very reasonable, no matter how
> > it is respected. Why was not _somewhat_ the same done for Windows?
>
> History, mainly. Plus the fact that the Unix convention is *not* that
> reasonable. Why should a system with only Python 3 installed (very
> common on Windows) not use "python" for that interpreter? The
> requirement that "python" must always refer to Python 2 comes from
> historical constraints on how Linux distributions chose to write their
> system scripts, AIUI.
>

I understand that general rules are not possible among the various OSs. If
just `python` suits for Windows it is OK. But I have the same question, why
should a system with Python 3 installed not use both "python" and "python3"
for that interpreter? This `python3` will allow to slightly unify the
workflow on different OSs, while it will be done almost for free. I want to
add that there are plenty of tutorials which use `python3 ...` without
reference to UNIX world, why are these mental overhead with `python3` or
`py -3` necessary?

In fact, I do not really understand why the _py launcher_ way is easier or
better than `python3` or `python3.6` way even on Windows. There are already
`pip.exe`, `pip3.exe`, `pip3.6.exe` which solve the same problem,  but they
are all redundant, when it is better to use `python3.6 -m pip ... ` or
currently `py -3.6 -m pip install ...`.

But debating why things are the way they are isn't that productive.
> It's the reality, so we need to deal with it.
>
> > p.s.: I know there is a `py` launcher under Windows, but is does not help
> > in this situation.
>
> Could you not use an alias?
>
> In [1]: import sys
>...: if sys.platform.startswith('win'):
>...: %alias python3 py -3
>...: else:
>...: %alias python3 python3
>...:
>...: ver = %python3 --version
>...: ver
>...:
> Python 3.6.2


Thank you this works for me!

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python aliases under Windows?

[Kirill Balunov]

2018-04-03 22:04 GMT+03:00 eryk sun :

> On Tue, Apr 3, 2018 at 3:43 PM, Ian Kelly  wrote:
> >
> > Because py.exe is really meant to solve a slightly different problem.
> > On Unix if you have a .py script and you run it directly, without
> > specifying which interpreter to use, the convention is to start the
> > script with a shebang line, and the kernel will transparently use the
> > interpreter specified there. Windows, however, doesn't respect shebang
> > lines and instead associates programs with files by file extension.
> >
> > Here's the problem: Python 2 files have a .py extension. Python 3
> > files also have a .py extension. Windows doesn't allow both Python
> > binaries to be associated with the same extension. So how can we set
> > things up so that launching a Python file will invoke the correct
> > Python version? To solve this, Python ships with py.exe and associates
> > *that* with the .py extension. py.exe knows what Python versions are
> > installed, and it inspects the shebang line to decide which one to run
> > for this particular script.
> >
> > The fact that py.exe can also intelligently select versions from
> > command line arguments is just an added bonus.
>

Thank you Ian, Terry, Eryk! Now I understand the purpose of py launcher in
general. I don't have Windows near, will `py -3.6 ...` work if Python36 is
not on the Path? If not, it seems to me, that if `python3.exe` and
`python3.6.exe` were provided they would be equivalent, and together they
will complement together and unify UNIX and Windows workflow. Am I missing
something?


> Alternatively, there's the Windows Script Host (WSH) framework
> (cscript.exe console, wscript.exe GUI), which supports a generic WSF
> file extension that allows mixing multiple languages in a single
> script, and integrates with COM, ASP, and native debuggers. PyWin32
> supports WSH. This could have been adapted to support Python 3 as a
> separate Windows scripting engine.
>
> That said, for general use, the py launcher's registration+shebang
> support is more flexible than the WSH registration-only approach. The
> launcher supports virtual Unix shebangs for cross-platform scripts and
> arbitrary executable paths for scripts that depend on virtual
> environments. I use it for the .py[w] file association and creating
> virtual environments. I still prefer `python` on the command line.
> Even on Linux I don't frequently use `python3` or `python3.X`. I do
> very little with the system Python.
>
> If you really miss typing "python3.6", I suggest using relative
> symbolic links (e.g. CMD's `mklink` command) created in the same
> directory as python[w].exe. Using relative symlinks requires
> installing Python on a NTFS volume that supports them, so it's not a
> viable solution for external drives that use FAT32 or exFAT. In the
> latter case, an alternative to batch scripts is to create a
> "python[w]3.6.lnk" shell shortcut to "python[w].exe". Leave the "start
> in" folder empty, so it will inherit the parent's working directory,
> and add .LNK to the system PATHEXT environment variable. One caveat is
> that, unlike symlinks or batch scripts, executing shell shortcuts
> requires ShellExecute[Ex] (called from Explorer, CMD, PowerShell,
> etc). CreateProcess (e.g. subprocess.Popen with shell=False) doesn't
> know anything about .LNK files.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

Thank you for your detailed advice, I'll try to understand. Why under
Windows everything is so complicated... Concerning dealing with `python` vs
`python3` it is a matter of habit, and I find the latter option more
reliable and missing it under Windows.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: [OT] master/slave debate in Python

[Kirill Balunov]

пн, 24 сент. 2018 г. в 22:46, Chris Angelico :

>
> The trouble is that making changes like this with a view to
> eliminating the words "master" and "slave" from all docs and comments
> (rather than making them to improve clarity and accuracy) opens up the
> leverage that SJWs need. "Hey, you changed that because we hate
> slavery - now you'd better eliminate all references to 'black' because
> we hate racism". So clear boundaries need to be set.
>
>
It seems to me that the word "black" has immunity in the next two Python
releases ;)  So do not worry so much!

But honestly, it's not pleasant to see how such holy things spread into the
world of OSS, and this is apparently only the beginning.

With kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to achieve pyc only deployment for module in python3.6

[Kirill Balunov]

On Tue, Oct 2, 2018, 08:42 Chris Angelico  wrote:

> On Tue, Oct 2, 2018 at 12:01 PM Chandana Pattanayak
>  wrote:
> >
> > Hi,
> >
> > I have a requirement to provide basic code protection for a module in our
> > product suite. With python 3.6 the .pyc files are created under pycache ,
> > so if i remove the py file the module is not found anymore.
>
> If you want code protection, the ONLY reliable way to do it is to not
> provide the code *at all*, in any form.
>

I think Cython is a rather reliable way to do it. There is a nice post to
start with “Protecting Python Sources With Cython” @2parrots
https://medium.com/@xpl/protecting-python-sources-using-cython-dcd940bb188e

With kind regards,
-gdg

>
-- 
https://mail.python.org/mailman/listinfo/python-list

Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

 Hi all! It is expected that:
```
>>> import os
>>> from pathlib import Path
>>> dummy = " "   # or "" or " "
>>> os.path.isdir(dummy)
False
>>> Path(dummy).is_dir()
True
```

or was it overlooked?

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 20:28, eryk sun :

> On 7/25/19, Kirill Balunov  wrote:
> >
> >>>> import os
> >>>> from pathlib import Path
> >>>> dummy = " "   # or "" or " "
> >>>> os.path.isdir(dummy)
> > False
> >>>> Path(dummy).is_dir()
> > True
>
> I can't reproduce the above result in either Linux or Windows. The
> results should only be different for an empty path string, since
> Path('') is the same as Path('.'). The results should be the same for
> Path(" "), depending on whether a directory named " " exists (normally
> not allowed in Windows, but Linux allows it).
>
>
Heh, something fishy is going on. I also can't reproduce that behavior
(with " " and "   ") at home comp on Windows 10 Python 3.7.4. Tomorrow I'll
check again at work and let you know. I apologize in advance. The main
problem arose огые with an empty line, but then I checked with " " and
apparently made a mistake somewhere.

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 19:16, Chris Angelico :

> On Fri, Jul 26, 2019 at 1:30 AM Kirill Balunov 
> wrote:
> >
> >  Hi all! It is expected that:
> > ```
> > >>> import os
> > >>> from pathlib import Path
> > >>> dummy = " "   # or "" or " "
> > >>> os.path.isdir(dummy)
> > False
> > >>> Path(dummy).is_dir()
> > True
> > ```
> >
> > or was it overlooked?
> >
> []
> I'm not sure if this is considered an important enough bug to actually
> fix, or
> if it's merely a curiosity that occurs when you trigger undocumented
> behaviour.
>
>
No, it's not just because of curiosity. I will try to tell the background,
and maybe I went the wrong way initially. There is a very cool project
https://github.com/3b1b/manim, it allows you to visualize math (I don’t
know how to describe it better you can see some examples here
https://www.3blue1brown.com) and it works lovely on Linux. For some reason,
I need to use it on Windows. Problems began to arise when I tried my
scripts were some latex was included in the animation.
So I installed TexLive, but it didn't produce any output :) In `manim` it
is invoked through a system call
https://github.com/3b1b/manim/blob/master/manimlib/utils/tex_file_writing.py#L40
like this:

$ latex -interaction=batchmode -halt-on-error -output-directory=...
input.tex > /dev/null

For some reason TexLive does not understand Windows relative paths of this
form -output-directory =".\Output" and  ".\Input\file.tex", but it
understands the absolute paths in Windows form like
"C:\path\to\the\input\file.tex".
I read that Windows allows also to provide paths in the usual form
"./Input/file.tex"
(maybe I'm wrong with my understanding what does it mean on Windows), I've
tested and this worked. But the problem is that Python always inserts '\'
as path separators on Windows and there is no control to set it up. I
decided to rewrite all this stuff with the help of `pathlib` module and to
use `Path`  and `.as_posix` method everywhere. Paths are set here
https://github.com/3b1b/manim/blob/c7e6d9d4742ec47098bd86a9bbb4212cc637206b/manimlib/constants.py#L10
and the author uses  `MEDIA_DIR = ""` as a default unset value, and then
checks  `if not os.path.isdir(MEDIA_DIR)`. The documentation states that
`os.path.isdir(...)` is equivalent to `Path(...).is_dir()` but it is not
true. So I wrote here.

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 22:58, Chris Angelico :

> On Fri, Jul 26, 2019 at 5:52 AM Kirill Balunov 
> wrote:
> [...]
> > No, it's not just because of curiosity. I will try to tell the
> background, and maybe I went the wrong way initially. There is a very cool
> project https://github.com/3b1b/manim, it allows you to visualize math (I
> don’t know how to describe it better you can see some examples here
> https://www.3blue1brown.com) and it works lovely on Linux. For some
> reason, I need to use it on Windows. Problems began to arise when I tried
> my scripts were some latex was included in the animation.
> >
>
> Ah, I love 3b1b! Great videos. I toyed with manim once (wanting to
> create new Fourier visualizations), but the open source parts weren't
> enough for what I was trying to do. Very cool though.
>
>
If you can tell, what parts did you miss?

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

чт, 25 июл. 2019 г. в 20:28, eryk sun :

> On 7/25/19, Kirill Balunov  wrote:
> >
> >>>> import os
> >>>> from pathlib import Path
> >>>> dummy = " "   # or "" or " "
> >>>> os.path.isdir(dummy)
> > False
> >>>> Path(dummy).is_dir()
> > True
>
> I can't reproduce the above result in either Linux or Windows. The
> results should only be different for an empty path string, since
> Path('') is the same as Path('.'). The results should be the same for
> Path(" "), depending on whether a directory named " " exists (normally
> not allowed in Windows, but Linux allows it).
>
>
I need to confirm that it was my fault and for non-empty strings (`" "` or `"
"`), both `os.path.isdir(...)` and `Path(...).is_dir()` produce the same
results.So sorry for the noise.

Concerning the case with empty path string, I will open a ticket at the bug
tracker (but for some reason it is blocked in my country :(
https://isitblockedinrussia.com/?host=https%3A%2F%2Fbugs.python.org%2F).
Obviously
these are not equivalent forms, so either this should be noted in the
documentation or corrected in the code.

with kind regards,
-gdg
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Difference between os.path.isdir and Path.is_dir

[Kirill Balunov]

Yeah it is True, for the last two weeks or so I can access bugs.python.org
in normal way. But I totally agree with the site that the best description
of this situation is "Yet".

with kind regards,
-gdg

сб, 14 дек. 2019 г. в 19:46, Terry Reedy :

> On 7/26/2019 3:12 AM, Kirill Balunov wrote:
> > чт, 25 июл. 2019 г. в 20:28, eryk sun :
> >
> >> On 7/25/19, Kirill Balunov  wrote:
> >>>
> >>>>>> import os
> >>>>>> from pathlib import Path
> >>>>>> dummy = " "   # or "" or " "
> >>>>>> os.path.isdir(dummy)
> >>> False
> >>>>>> Path(dummy).is_dir()
> >>> True
> >>
> >> I can't reproduce the above result in either Linux or Windows. The
> >> results should only be different for an empty path string, since
> >> Path('') is the same as Path('.'). The results should be the same for
> >> Path(" "), depending on whether a directory named " " exists (normally
> >> not allowed in Windows, but Linux allows it).
> >>
> >>
> > I need to confirm that it was my fault and for non-empty strings (`" "`
> or `"
> > "`), both `os.path.isdir(...)` and `Path(...).is_dir()` produce the same
> > results.So sorry for the noise.
> >
> > Concerning the case with empty path string, I will open a ticket at the
> bug
> > tracker (but for some reason it is blocked in my country :(
> > https://isitblockedinrussia.com/?host=https%3A%2F%2Fbugs.python.org%2F).
>
> For me, this now returns 'No, https://bugs.python.org is probably not
> blocked in Russia. Yet.'.
>
> > Obviously
> > these are not equivalent forms, so either this should be noted in the
> > documentation or corrected in the code.
>
> --
> Terry Jan Reedy
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

pyopengl and py2exe

[Kirill Kuvaldin]

Hello All!

My program in python uses PyOpenGL and I need to convert it to a
standalone windows executable file.

Following to these instructions 
(http://pyopengl.sourceforge.net/documentation/py2exe.html) I've put
PyOpenGL package to a directory where my program was placed.
and run the script:
 setup.py py2exe --excludes=OpenGL

but it prints such error messages:
...
*** copy extensions ***
copying C:\Python23\DLLs\_sre.pyd -> C:\cg\dist
*** copy dlls ***
copying C:\Python23\w9xpopen.exe -> C:\cg\dist
copying C:\WINNT\system32\python23.dll -> C:\cg\dist
setting sys.winver for 'C:\cg\dist\python23.dll' to 'py2exe samples'
copying C:\Python23\lib\site-packages\py2exe\run.exe -> C:\cg\dist\hello.exe
The following modules appear to be missing
['OpenGL.GL', 'OpenGL.GLE', 'OpenGL.GLUT']

?

-- 
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] LibYAML-0.0.1: The initial release

[Kirill Simonov]

I'd like to announce the initial release of LibYAML, a YAML parser and
emitter library written in C.

LibYAML homepage:   http://pyyaml.org/wiki/LibYAML
TAR.GZ package: http://pyyaml.org/download/libyaml/yaml-0.0.1.tar.gz
SVN repository: http://svn.pyyaml.org/libyaml
Bug tracker:http://pyyaml.org/newticket?component=libyaml

The library is functionally complete, but the documentation is scarce
and the API is subject to change.  For more information, you may check
the project homepage, the doxygen-generated documentation in the `doc`
directory of the source distribution, and the examples
`tests/example-reformatter.c` and `tests/example-deconstructor.c`.

There are preliminary Python bindings for LibYAML in the PyYAML SVN
repository.

LibYAML is written by Kirill Simonov <[EMAIL PROTECTED]>.  It is released
under the MIT license.  See the file LICENSE for more details.

This project is developed for Python Software Foundation as a part of
the Google Summer of Code program under the mentorship of Clark C. Evans.

-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.04: YAML parser and emitter for Python

[Kirill Simonov]

 Announcing PyYAML-3.04


A new release of PyYAML, featuring LibYAML bindings and support for
recursive structures, is now available:

http://pyyaml.org/wiki/PyYAML


Changes
===

* Include experimental LibYAML bindings.
* Fully support recursive structures.
* Fix a number of bugs and annoyances
  (see http://pyyaml.org/wiki/PyYAML#History for more details).


Resources
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.04.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.04.zip
Windows installer:
http://pyyaml.org/download/pyyaml/PyYAML-3.04.win32-py2.3.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.04.win32-py2.4.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml
>>> print yaml.load("""
... &A {
... direct self reference: *A,
... indirect self references: [*A, *A, *A]
... }
... """)
{'direct self reference': {...},
'indirect self references': [{...}, {...}, {...}]}


Copyright
=

The PyYAML module is written by Kirill Simonov <[EMAIL PROTECTED]>.

PyYAML is released under the MIT license.

This release is developed with the support of the Google Summer of Code
program under the mentorship of Clark Evans.

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: help on pickle tool

[Kirill Simonov]

Hi,

I'm somewhat late to this discussion, but as the author of PyYAML, I'd
like to put my 2c in.


On Thu, Oct 05, 2006 at 09:52:56PM -0700, virg wrote:
> Is it possible to deserialize the data by java  which serialized by
> Python or is there any compatibility issue. Is there any equivalent
> pickle tool on java which supports this operation. so that i can use
> across languages.

You may serialize/deserialize your data to YAML using PyYAML
(http://pyyaml.org/wiki/PyYAML) on the Python side and jvyaml
(https://jvyaml.dev.java.net/) on the Java side.  You may also check
JSON (http://json.org/) as other posters suggested.


On Thu, Oct 05, 2006 at 10:54:46PM -0700, MonkeeSage wrote:
> hanumizzle wrote:
> > Why a subset?
>
> I don't think JSON is a subset of YAML.

It is.


On Fri, Oct 06, 2006 at 08:36:07AM +0200, Fredrik Lundh wrote:
> JSON is almost identical to Python's expression syntax, of course,
> while YAML isn't even close.

A valid Python list/dict expression is likely to be a valid YAML
expression.  For instance

{ "odd": [1, 3, 5, 7, 9], "even": [2, 4, 6, 8] }

is both valid Python and valid YAML.


On Fri, Oct 06, 2006 at 08:28:29AM +0200, Fredrik Lundh wrote:
> than JavaScript's expression syntax?  are you sure you're not
> confusing libraries with standards here?  (has anyone even managed to
> write a YAML library that's small and simple enough to be "obviously
> correct"?)

I've written a complete YAML parser and I must admit it hasn't been
extremely difficult.  The YAML syntax is very close to Python and I just
needed to rewrite YAML grammar using Python as a model.  The PyYAML
parser is LL(1), which is as simple as it could be.


-- 
xi
-- 
http://mail.python.org/mailman/listinfo/python-list

distutils: optionally build C bindings to an external library

[Kirill Simonov]

Hi,

I've written a pure Python module, which could optionally use an
external C library. The external library is not required to be on the
user computer however, so I'd like not to build the bindings by default,
but allow a user to turn the build on by specifying some parameter to
`setup.py`. Basically, it should work like
./configure --with-some-lib[=/path]

Unfortunately I'm not quite sure how to implement this and I'm already
lost in the distutils internals. Could someone point me to the correct
direction, perhaps giving me a reference to an existing distutils
script?

-- 
xi
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.03: YAML parser and emitter for Python

[Kirill Simonov]

 Announcing PyYAML-3.03


A new bug-fix release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML


Changes
===

* Fix Python 2.5 compatibility issues.
* Fix numerous bugs in the float handling.
* Fix scanning some ill-formed documents.
* Other minor fixes.


Resources
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.03.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.03.zip
Windows installer: http://pyyaml.org/download/pyyaml/PyYAML-3.03.win32.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Copyright
=

The PyYAML module is written by Kirill Simonov <[EMAIL PROTECTED]>.

PyYAML is released under the MIT license.

-- 
http://mail.python.org/mailman/listinfo/python-list

A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

Hi,

Could anyone suggest me a simple IDE suitable for teaching Python as a
first programming language to high school students?  It is necessary
that it has a good support for input/output in Cyrillic.

Unfortunately, most IDEs I tried failed miserably in this respect.  My
test was simple: I've run the code
name = raw_input("What's your name? ")  # written in Russian
print "Hello, %s!" % name   # in Russian as well
both from the shell and as a standalone script. This either caused a
UnicodeError or just printed invalid characters.

For the record, I've checked IDLE, PythonWin, Eric, DrPython, SPE, and
WingIDE.  The only ones that worked are WingIDE and IDLE (under Linux,
but not under Windows).


Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sat, Nov 18, 2006 at 10:08:22PM +0300, Oleg Broytmann wrote:
> On Sat, Nov 18, 2006 at 09:01:04PM +0200, Kirill Simonov wrote:
> > Could anyone suggest me a simple IDE suitable for teaching Python as a
> > first programming language to high school students?
> 
>Does it have to be an IDE? Wouldn't it be better to use a simple text
> editor + command line?

Preferably.  I believe that using a editor + command line will only make
things worse because console and GUI have different encodings under
Windows.  So a student that have written a script in a GUI editor and saved
it in UTF-8 would see garbage in console.


Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Zopyrus] A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sat, Nov 18, 2006 at 07:20:49PM +, tom wrote:
> Oleg Broytmann wrote:
> > On Sat, Nov 18, 2006 at 09:01:04PM +0200, Kirill Simonov wrote:
> >   
> >> Could anyone suggest me a simple IDE suitable for teaching Python as a
> >> first programming language to high school students
> >> 
> which operating system would this concern?  IDLE which you might find 

MS Windows is a must, but having Linux support would be nice too.

Unfortunately, IDLE does not work well with non-ASCII input/output.

> I personally use pida (http://pida.berlios.de).  It is perhaps not a 

Thanks for the suggestion, I'll check it.


Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Zopyrus] A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sat, Nov 18, 2006 at 10:52:35PM +0300, Oleg Broytmann wrote:
> On Sat, Nov 18, 2006 at 09:22:48PM +0200, Kirill Simonov wrote:
> > Preferably.  I believe that using a editor + command line will only make
> > things worse because console and GUI have different encodings under
> > Windows.
> 
>Ouch! I am always forgetting about it, 'cause I seldom use Windows, and

Yeah, that's what Freud called displacement ;)

> even in Windows my editor is gvim. (-:

Me too.  Still it would be harsh to force students that might see a PC at
the first time to use it. ;)


Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re:A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sat, Nov 18, 2006 at 01:22:44PM -0600, Larry Bates wrote:
> Oleg Broytmann wrote:
> > On Sat, Nov 18, 2006 at 09:01:04PM +0200, Kirill Simonov wrote:
> >> Could anyone suggest me a simple IDE suitable for teaching Python as a
> >> first programming language to high school students?
> > 
> >Does it have to be an IDE? Wouldn't it be better to use a simple text
> > editor + command line?
> > 
> > Oleg.
> Not sure about cyrillic and I don't mean if you are looking for Windows
> IDE, but I'm impressed with Pyscripter:
> 
> http://mmm-experts.com/Products.aspx?ProductId=4

PyScripter does, indeed, look nice, but unfortunately it appeared to
have similar issues with cyrillic support. Thank you anyway for the
suggestion.


Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: [Zopyrus] A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sun, Nov 19, 2006 at 02:49:43AM +0600, Gleb Kulikov wrote:
> В сообщении от Воскресенье 19 Ноябрь 2006 01:01 Kirill Simonov написал:
> 
> > first programming language to high school students?  It is necessary
>
> > Unfortunately, most IDEs I tried failed miserably in this respect.  My
>
> > For the record, I've checked IDLE, PythonWin, Eric, DrPython, SPE, and
> 
> Pardon, eric (eric-3.9.0-alt1 is in use), "speak" Russian quite well.
> We are trying to teach schoolers with a Python in an advanced elementary 
> school (9th - 11th). Yes, there is a problem with Cyrillic in eric's built-in 
> interpreter window (KOI8 locale is used) and *only* in the built-in 
> interpreter window, but there is short workaround for it: if avoid "# -*- 
> coding..." declaration, Cyrillic is painted well.

Hmm... Perhaps, you are right.  I remember quite well seeing
UnicodeDecodeError in eric, but now I couldn't reproduce it.
Still it would be good if eric could automatically add the BOM mark to
files containing non-ASCII characters (for UTF-8). That way the
deprecation warning about PEP 263 would be avoided.

There is a bigger problem though: it is difficult (if possible) to
install it under Windows.


Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sun, Nov 19, 2006 at 12:33:39PM +0100, Alan Franzoni wrote:
> Kirill Simonov  si è divertito a scrivere:
> 
> > Unfortunately, most IDEs I tried failed miserably in this respect.  My
> > test was simple: I've run the code
> > name = raw_input("What's your name? ")  # written in Russian
> > print "Hello, %s!" % name   # in Russian as well
> > both from the shell and as a standalone script. This either caused a
> > UnicodeError or just printed invalid characters.
> 
> I highly dislike asking stupid questions, and this might be stupid
> indeed... but did you write
> 
> # -*- coding: iso-8859-5 -*-
> 
> or
> 
> # -*- coding: koi8_r -*-
> 
> (they both seem suited to the Russian language, but I don't know the
> difference)

They are different encodings for the same character set. The latter is
mostly used under Unices, and the former is not used anywhere as far as
I know. There are two more cyrillic encodings: cp866 and cp1251 - for
DOS and Windows correspondingly.
 
> as the first line in your .py file?

No, I would prefer the editor to save the .py files with non-ASCII
characters in UTF-8 encoding adding the BOM at the beginning of the
file. This will allow the interpreted to detect the file encoding
correctly and would save a teacher from explaining what an encoding is
and why it is needed.

> Personally, I use Eclipse+Pydev (a bit steep to learn at the beginning, and
> quite memory and cpu hogging since it's a java-based ide; don't use it on
> old/slow computers with less than 512MB RAM, and don't use version < 3.2
> either) and it uses that very line to recognize the actual character set
> employed. You may check with other encodings as well.

Unfortunately, the Eclipse CPU/memory requirements are extremely high
for a high school, so I haven't even tried it.


-- 
xi
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sun, Nov 19, 2006 at 03:27:32AM -0800, Leo Kislov wrote:
> IDLE on Windows works fine for your example in interactive console:
> 
> >>> name = raw_input("What's your name? ")

Have you tried to use cyrillic characters in a Python string in
interactive console? When I do it, I get the "Unsupported characters in
input" error. For instance,

>>> print "Привет"  # That's "Hi" in Russian.
Unsupported characters in input

>>>

> And another question: are you aware of the fact that recommended way to
> handle non-ascii characters is to use unicode type? Most of IDEs should
> work fine with unicode. 

Usually using unicode type gives you much more headache than benefits
unless you are careful enough to never mix unicode and str objects.

Anyway, I just want the interactive console of an IDE to behave like a
real Python console under a UTF-8 terminal (with sys.stdout.encoding ==
'utf-8').


Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sun, Nov 19, 2006 at 03:13:30PM +0100, Alan Franzoni wrote:
> Kirill Simonov  si è divertito a scrivere:
> 
> > On Sun, Nov 19, 2006 at 12:33:39PM +0100, Alan Franzoni wrote:
>  
> > No, I would prefer the editor to save the .py files with non-ASCII
> > characters in UTF-8 encoding adding the BOM at the beginning of the
> > file. This will allow the interpreted to detect the file encoding
> > correctly and would save a teacher from explaining what an encoding is
> > and why it is needed.
> 
> You'll run into encoding problems anyway in your programmer's life. I don't
> think it's a workaround, try this article:
> 
> http://www.joelonsoftware.com/articles/Unicode.html
> 
> I think it's highly useful, you could tell that to your students.

Please remember that most of the students will not become professional
programmers.  Personally I think that encoding problems are nightmare in
general, and in Python in particular, and would like to avoid explaining
it as longer as possible.  Besides, it won't be me, it will be a teacher
who will explain it, and the teacher themself might have a vague notion
about this topic.

> Eclipse+Pydev seems to work with that. I'm not able to check with other
> editors right now, but it seems you're experiencing a simple encoding
> problem; your editor doesn't know which encoding you'd like to use, so it
> defaults to ascii or iso-8859-1 leading to such problems.

No, my problem is that the emulation of sys.stdin/sys.stdout under
an IDE's interactive console doesn't work like the real
sys.stdin/sys.stdout under a real terminal.


Thanks,
Kirill.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Re:A python IDE for teaching that supports cyrillic i/o

[Kirill Simonov]

On Sat, Nov 18, 2006 at 06:11:48PM -0800, PyScripter wrote:
> Kirill Simonov wrote:
> > PyScripter does, indeed, look nice, but unfortunately it appeared to
> > have similar issues with cyrillic support. Thank you anyway for the
> > suggestion.
> 
> 
> What are the issues?  PyScripter offers full support for utf-8 encoded
> files and PEP-263.  The editor internally is unicode based.Please
> read the PyScripter help topic "Encoded Python Source Files", paying
> special attention to the last paragraph, and if you follow the
> guidelines you should have no problem with cyrillic or other encodings.
>  If you have problems email [EMAIL PROTECTED] for support.

The issues are related to the emulation of sys.stdin and sys.stdout in
the interactive console (which is called Python Interpreter in
PyScripter).

In PyScripter,
>>> print "...some cyrillic characters..."
produces output as if an UTF-8 string is displayed in latin1.
On the other hand,
>>> print u"...some cyrillic characters..."
works correctly in PyScripter.  Both above examples works correctly in a
real console when sys.stdout.encoding is set to 'utf-8'.

raw_input() doesn't work at all with non-ASCII characters in PyScripter.
>>> raw_input("...some cyrillic characters...")
displays the label in latin1 while
>>> raw_input(u"...some cyrillic characters...")
produces UnicodeDecodeError.

Moreover, if I enter some cyrillic characters to the input box of
raw_input(), it returns a line of '?'. This might be related to the fact
that I use WinXP ENG (not RUS), but still I believe it's possible to
make it work even in this environment.

I'd like the emulated sys.stdin and sys.stdout to behave like the real
sys.stdin and sys.stdout do under a UTF-8 terminal when
sys.stdout.encoding is set to 'utf-8'.

Python 2.5, PyScripter 1.7.2.0.


Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

PyGILState_Release + Python2.3 = Segmentation Fault

[Kirill Simonov]

Hi,

Could someone tell me why my extension module works under Python 2.4, but 
fails with Segmentation Fault under Python 2.3? Here is the stripped version:


#include 

static PyObject *
test_gil(PyObject *self)
{
PyGILState_STATE gs;

Py_BEGIN_ALLOW_THREADS

gs = PyGILState_Ensure();

PyGILState_Release(gs);

Py_END_ALLOW_THREADS

Py_INCREF(Py_None);
return Py_None;
}

static PyMethodDef test_gil_methods[] = {
{"test_gil", (PyCFunction)test_gil, METH_NOARGS},
{NULL}
};

PyMODINIT_FUNC
init_test_gil(void) {
(void)Py_InitModule("_test_gil", test_gil_methods);
}
===

I've tested it with Debian Sid and Ubuntu Breezy.

Thanks,
Kirill
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.05: YAML parser and emitter for Python

[Kirill Simonov]

 Announcing PyYAML-3.05


A new bug fix release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML


Changes
===

* Windows binary packages were built with LibYAML trunk.
* Fixed a bug that prevent processing a live stream of YAML documents in
  timely manner (Thanks edward(at)sweetbytes(dot)net).
* Fixed a bug when the path in add_path_resolver contains boolean values
  (Thanks jstroud(at)mbi(dot)ucla(dot)edu).
* Fixed loss of microsecond precision in timestamps
  (Thanks edemaine(at)mit(dot)edu).
* Fixed loading an empty YAML stream.
* A number of smaller fixes and improvements
  (see http://pyyaml.org/wiki/PyYAML#History for more details).


Resources
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.05.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.05.zip
Windows installer:
http://pyyaml.org/download/pyyaml/PyYAML-3.05.win32-py2.3.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.05.win32-py2.4.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.05.win32-py2.5.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Copyright
=

The PyYAML module is written by Kirill Simonov <[EMAIL PROTECTED]>.

PyYAML is released under the MIT license.
-- 
http://mail.python.org/mailman/listinfo/python-list

__reduce__(1) vs __reduce__(2)

[Kirill Simonov]

Could someone explain why __reduce__(2) works for files while
__reduce__(1) doesn't?

>>> f = file('/etc/passwd')
>>> f.__reduce__(1)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/copy_reg.py", line 69, in _reduce_ex
raise TypeError, "can't pickle %s objects" % base.__name__
TypeError: can't pickle file objects
>>> f.__reduce__(2)
(, (,), None, None, None)

What is a correct procedure of getting state and restoring Python objects?

-- 
xi
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.01: YAML parser and emitter for Python

[Kirill Simonov]

PyYAML: YAML parser and emitter for Python
==

I am pleased to announce the initial release of PyYAML.

YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.

You may download PyYAML from http://pyyaml.org/wiki/PyYAML.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... version: 3.01
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'version': 3.01, 'homepage': 'http://pyyaml.org/wiki/PyYAML',
'description': 'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
homepage: http://pyyaml.org/wiki/PyYAML
version: 3.01
name: PyYAML
keywords: [YAML, serialization, configuration, persistance, pickle]
description: YAML parser and emitter for Python


Links
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.01.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.01.zip
Windows installer: http://pyyaml.org/download/pyyaml/PyYAML-3.01.win32.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core


Changes
===

* Initial release.  The version number reflects the codename of the
  project (PyYAML 3000) and differenciates it from the abandoned PyYaml
  module.


Copyright
=

The PyYAML module is written by Kirill Simonov <[EMAIL PROTECTED]>.

PyYAML is released under the MIT license.


-- 
xi
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.02: YAML parser and emitter for Python

[Kirill Simonov]

 Announcing PyYAML-3.02


A new bug-fix release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML


Changes
===

* Fix win32 installer.  Apparently bdist_wininst does not work well under
  Linux.
* Fix a bug in add_path_resolver.
* Add the yaml-highlight example.  Try to run on a color terminal:
  `python yaml_hl.py http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.02.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.02.zip
Windows installer: http://pyyaml.org/download/pyyaml/PyYAML-3.02.win32.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: http://lists.sourceforge.net/lists/listinfo/yaml-core


About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Copyright
=

The PyYAML module is written by Kirill Simonov <[EMAIL PROTECTED]>.

PyYAML is released under the MIT license.


-- 
xi
-- 
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.07: YAML parser and emitter for Python

[Kirill Simonov]

 Announcing PyYAML-3.07


A new release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML


Changes
===

* The emitter learned to use an optional indentation indicator
  for block scalars; thus scalars with leading whitespaces
  could now be represented in a literal or folded style.
* The test suite is now included in the source distribution.
  To run the tests, type 'python setup.py test'.
* Refactored the test suite: dropped unittest in favor of
  a custom test appliance.
* Fixed the path resolver in the LibYAML-based dumper.
* Forced an explicit document end indicator when there is
  a possibility of parsing ambiguity.
* More setup.py improvements: the package should be usable
  when any combination of setuptools, Pyrex and LibYAML
  is installed.
* Windows binary packages are statically linked against
  LibYAML-0.1.2.
* Other minor fixes and improvements (Thank to Ingy dot Net
  and Andrey Somov).


Resources
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.07.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.07.zip
Windows installer:
http://pyyaml.org/download/pyyaml/PyYAML-3.07.win32-py2.3.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.07.win32-py2.4.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.07.win32-py2.5.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.07.win32-py2.6.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: 
http://lists.sourceforge.net/lists/listinfo/yaml-core



About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Copyright
=

The PyYAML module is written by Kirill Simonov .

PyYAML is released under the MIT license.
--
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.08: Now with Python 3 support

[Kirill Simonov]

 Announcing PyYAML-3.08


A new release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML

This release features complete support for Python 3.  For
compatibility notes between Python 2 and Python 3 versions,
please see

http://pyyaml.org/wiki/PyYAMLDocumentation#Python3support


Changes
===

* Python 3 support (Thank to Erick Tryzelaar).
* Use Cython instead of Pyrex to build LibYAML bindings.  Note
  that the source package is distributed with a pre-generated
  '_yaml.c' file so you don't need Cython installed to build
  LibYAML bindings.
* Refactored support for unicode and byte input/output streams.


Resources
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.08.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.08.zip
Windows installers:
http://pyyaml.org/download/pyyaml/PyYAML-3.08.win32-py2.3.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.08.win32-py2.4.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.08.win32-py2.5.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.08.win32-py2.6.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.08.win32-py3.0.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: 
http://lists.sourceforge.net/lists/listinfo/yaml-core



About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Copyright
=

The PyYAML module is written by Kirill Simonov .

PyYAML is released under the MIT license.
--
http://mail.python.org/mailman/listinfo/python-list

Re: creating yaml without tags using pyyaml

[Kirill Simonov]

Stephen Moore wrote:

I have come to the conclusion that this is the fault of the tags (for
example, !!python/tuple) as getting rid of them gets rid of the
errors.

So I'm wondering if there is an option to YAML.decode that will create
a yaml document without the tags?


Try yaml.safe_dump().

>>> import yaml

>>> print yaml.dump(())
!!python/tuple []

>>> print yaml.safe_dump(())
[]


Thanks,
Kirill
--
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.06: YAML parser and emitter for Python

[Kirill Simonov]

 Announcing PyYAML-3.06


A new bug fix release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML


Changes
===

* setup.py checks whether LibYAML is installed and if so, builds
  and installs LibYAML bindings.  To force or disable installation
  of LibYAML bindings, use '--with-libyaml' or '--without-libyaml'
  options respectively.
* Building LibYAML bindings no longer requires Pyrex installed.
* 'yaml.load()' raises an exception if the input stream contains
  more than one YAML document.
* Fixed exceptions produced by LibYAML bindings.
* Fixed a dot '.' character being recognized as !!float.
* Fixed Python 2.3 compatibility issue in constructing !!timestamp
  values.
* Windows binary packages are built against the LibYAML stable branch.
* Added attributes 'yaml.__version__' and  'yaml.__with_libyaml__'.


Resources
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.06.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.06.zip
Windows installer:
http://pyyaml.org/download/pyyaml/PyYAML-3.06.win32-py2.3.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.06.win32-py2.4.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.06.win32-py2.5.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.06.win32-py2.6.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: 
http://lists.sourceforge.net/lists/listinfo/yaml-core



About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Copyright
=

The PyYAML module is written by Kirill Simonov <[EMAIL PROTECTED]>.

PyYAML is released under the MIT license.
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Kirill Simonov]

Erik Max Francis wrote:

Daniel Fetchinson wrote:

it is my goal (which I may or may not be smart enough to reach) to
write a module that anybody would want to use;

But you are working on a solution in search of a problem.  The really
smart thing to do would be pick something more useful to work on.  We
don't need another configuration language.  I can't even say "yet
another" because there's already a "yet another" called yaml.


And in case you are new here let me assure you that Paul is saying
this with his full intention of being helpful to you. I also would
think that working on such a project might be fun and educational for
you but completely useless if you have users other than yourself in
mind. Again, I'm trying to be helpful here, so you can focus on a
project that is both fun/educational for you and also potentially
useful for others. This RSON business is not one of them.


Agreed.  Even YAML's acronym indicates that it is already a bridge too 
far; we don't need more.




Note that YA in the acronym doesn't mean Yet Another, YAML = YAML Ain't 
Markup Language.



Thanks,
Kirill
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Kirill Simonov]

Patrick Maupin wrote:

All:

Finding .ini configuration files too limiting, JSON and XML to hard to
manually edit, and YAML too complex to parse quickly, I have started
work on a new configuration file parser.


I'd like to note that with the optional libyaml bindings, the PyYAML 
parser is pretty fast.



I call the new format RSON (for "Readable Serial Object Notation"),
and it is designed to be a superset of JSON.

I would love for it to be considered valuable enough to be a part of
the standard library, but even if that does not come to pass, I would
be very interested in feedback to help me polish the specification,
and then possibly help for implementation and testing.

The documentation is in rst PEP form, at:

http://rson.googlecode.com/svn/trunk/doc/draftpep.txt


=== cut ===
Because YAML does allow for highly readable configuration files, it
is tempting to overlook its other flaws for the task.  But a fully
(or almost) compliant parser has to understand the whole YAML
specification, and this is apparently expensive.  Running the rst2pdf
testsuite, without sphinx or most of the other optional packages, in
"fast" mode (preloading all the modules, and then forking for every
test) generates 161 smallish PDF files, totaling around 2.5 MB.  On
one test system this process takes 22 seconds.  Disabling the _json C
scanner and reading the configuration files using the json pure Python
implementation adds about 0.3 seconds to the 22 seconds.  But using
pyyaml v. 3.09 instead of json adds 33 seconds to the 22 second process!
It might seem that this is an edge case, but it makes it unacceptable to
use YAML for this sort of testing, and taking 200 ms to read in 1000
lines of simple JSON will be unacceptable in many other application
domains as well.
=== cut ===

I'd question your testing methodology.  From your description, it looks 
like the _json speedup never was enabled.  Also PyYAML provides optional 
bindings to libyaml, which makes parsing and emitting yaml much faster. 
 In my tests, it parses a 10Mb file in 3 sec.


=== cut ===
RSON semantics are based on JSON.  Like JSON, an RSON document represents
either a single scalar object, or a DAG (Directed Acyclic Graph), which
may contain only a few simple data types.
=== cut ===

JSON doesn't represent a DAG, at least, not an arbitrary DAG since each 
node in the document has no more than one parent.  It would be more 
accurate to say that that it represents a tree-like structure.


=== cut ===
The YAML syntax for supporting back-references was considered and deemed
unsatisfactory. A human user who wants to put identical information in a
"ship to" and "bill to" address is much more likely to use cut and paste
than he is to understand and use backreferences, so the additional overhead
of supporting more complex document structures is unwarranted.

The concept of a "merge" in YAML, where two sub-trees of data can be
merged together (similar to a recursive Python dictionary update)
is quite useful, though, and will be copied.  This does not alter the
outcome that parsing a RSON file will result in a DAG, but does give
more flexibility in the syntax that can be used to achieve a particular
output DAG.
=== cut ===

This paragraph assumes the reader is familiar with intricate details of 
the YAML grammar and semantics.  I bet most of your audience are 
completely lost here.


=== cut ===
Enhanced example::

key1/key2a
key3a = Some random string
key3b = 42
key1/key2a
key3c
1
2
{}
key4a = anything
key4b = something else
[]
a
b
c
3
4
key1/key2b = [1, 2, 3, 4]
key5 = ""
   This is a multi-line string.  It is
  dedented to the farthest left
  column that is indented from
  the line containing "".
key6 = [""]
   This is an array of strings, one per line.
   Each string is dedented appropriately.
=== cut ===

Frankly, this is an example that only a mother could love.  I'd suggest 
you to add some real-world examples, make sure they look nice and put 
them to the introductory part of the document.  Examples is how the 
format will be evaluated by the readers, and yours don't stand a chance.


Seriously, the only reason YAML enjoys its moderate popularity despite 
its overcomplicated grammar, chronic lack of manpower and deficient 
implementations is because it's so cute.




Disclaimer: I'm the author of PyYAML and libyaml.

Thanks,
Kirill
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Kirill Simonov]

Patrick Maupin wrote:

Kirill:

Thank you for your constructive criticism.  This is the gem that made
it worthwhile to post my document.  I think all of your points are
spot-on, and I will be fixing the documentation.


You are welcome.  Despite what others have been saying, I don't think 
this area is closed to innovations.




I can well believe that the C implementation of YAML is much faster
than the Python one, but I am aiming for something that will be
reasonably quick in pure Python.  I will double-check the JSON C test
results, but something I probably did not make clear is that the 22
seconds is not spent parsing -- that is for the entire test, which
involves reading restructured text and generating some 160 separate
PDF files.


Yes, this makes more sense.  It's quite possible that the pure-Python 
PyYAML parser is much slower than the pure-Python JSON parser.


At the same time, semantically meaningful whitespaces will likely hinder 
the pure-Python performance.  To make it fast, you'll need to convert 
the inner loops of the parser to regexps, and it is hard to support 
variable-length indentation with static regular expressions.



Thanks,
Kirill
--
http://mail.python.org/mailman/listinfo/python-list

Re: Draft PEP on RSON configuration file format

[Kirill Simonov]

Patrick Maupin wrote:

On Mon, Mar 1, 2010 at 8:02 PM, Kirill Simonov  wrote:

BTW, congratulations on slogging through the YAML grammar to generate
such a good working C library!

That must have been a tremendous effort.


The trick was to completely ignore the grammar described in the 
specification.  In fact, the syntax of YAML is pretty close the Python 
syntax and, with some effort, the Python scanner and parser could be 
adapted to parsing YAML.  Once I realized it, I got a working parser in 
a week or so.


Thanks,
Kirill
--
http://mail.python.org/mailman/listinfo/python-list

Re: Needed: Real-world examples for Python's Cooperative Multiple Inheritance

[Kirill Simonov]

Hi Raymond,

We've been using cooperative inheritance to implement stacked utilities 
such as WSGI middleware or connecting to a database.


An example of a WSGI middleware stack:

# Declare the interface and provide the default implementation.
class WSGI(Utility):
def __call__(self, environ, start_response):
# The main WSGI application is implemented here.
start_response("200 OK", [('Content-Type', 'text/plain')])
return ["Hello World!"]

# GZip middleware (may be defined in a different module or a plugin)
class GZIP(WSGI):
# To indicate relative position in the middleware stack
weights(100)
def __call__(self, environ, start_response):
# Call the next middleware in the stack to generate data.
# Also, need to wrap start_response here...
generator = super(GZIP, self).__call__(environ, start_response)
# Pack the output...

# Error handling middleware (defined in a different module or a plugin)
class LogErrors(WSGI):
weights(1000)
def __call__(self, environ, start_response):
# Call the next middleware in the stack, catch any errors.
try:
generator = super(LogErrors, self).__call__(environ,
 start_response)
except:
# Log errors...

# Now glue them all together
def wsgi(environ, start_response):
wsgi = WSGI() # !!!
return wsgi(environ, start_response)

The trick here is that the constructor of `WSGI` (actually, 
`Utility.__new__()`) is overridden.  Instead of producing a new instance 
of `WSGI` , it does the following:

- use `__subclasses__()` to find all components of the utility;
- order the components by their weights;
- create a new class: `type(name, list_of_components, {})`;
- return an instance of the class.

Here is another example, database connection.

# The interface, no default implementation.
class Connect(Utility):
def __init__(self, host, port, user, password, database):
self.host = host
self.port = port
self.user = user
self.password = password
self.database = database
def __call__(self):
raise NotImplementedError()

# Public API
def connect(host, port, user, password, database):
# Same trick here.
connect = Connect(host, port, user, password, database)
return connect()

# PostgreSQL implementation (defined in a plugin)
import psycopg2
class PGSQLConnect(Connect):
def __call__(self):
return psycopg2.connect(...)

# Connection pooling (defined in a plugin)
class Pooling(Connect):
weights(100)
def __call__(self):
# Check if we could reuse an existing connection
# ...
# If no free connections available
connection = super(Pooling, self).__call__()
# Save it somewhere and return it...

Note that utility instances are short-lived so any persistent state must 
be kept elsewhere.



We also use the same pattern to implement Cecil/Diesel-style 
multimethods and general predicate dispatch, but that's probably outside 
the scope of your question.


A public version of the code lives here:
https://bitbucket.org/prometheus/htsql
Unfortunately it doesn't exactly match my examples above: connection 
pooling and most of the wsgi middleware are still to be ported, 
`weights()` is missing, etc.



Hope it helps.

Thanks,
Kirill

On 11/24/2010 03:08 PM, Raymond Hettinger wrote:

I'm writing-up more guidance on how to use super() and would like to
point at some real-world Python examples of cooperative multiple
inheritance.

Google searches take me to old papers for C++ and Eiffel, but that
don't seem to be relevant to most Python programmers (i.e. a
WalkingMenu example where a submenu is both a Entry in a Menu and a
Menu itself).  Another published example is in a graphic library where
some widgets inherit GraphicalFeature methods such as location, size
and NestingGroupingFeatures such as finding parents, siblings, and
children.  I don't find either of those examples compelling because
there is no particular reason that they would have to have overlapping
method names.

So far, the only situation I can find where method names necessarily
overlap is for the basics like __init__(), close(), flush(), and
save() where multiple parents need to have their own initialization
and finalization.

If you guys know of good examples, I would appreciate a link or a
recap.

Thanks,


Raymond


--
http://mail.python.org/mailman/listinfo/python-list

Re: Needed: Real-world examples for Python's Cooperative Multiple Inheritance

[Kirill Simonov]

Hi Raymond,

Another example: extensions in Mercurial.  Mercurial is a VCS with a 
typical command line syntax:


$ hg  

Mercurial has an extension mechanism for adding new and modifying 
existing commands.  A big chunk of Mercurial functionality is 
implemented in `ui` and `repo` classes and extensions often patch those 
to override the default behavior.  For instance, you could check the 
`color` extension, which patches `ui` to override `write*` methods:


http://selenic.com/hg/file/3790452d499b/hgext/color.py#l152


Thanks,
Kirill


On 11/24/2010 03:08 PM, Raymond Hettinger wrote:

I'm writing-up more guidance on how to use super() and would like to
point at some real-world Python examples of cooperative multiple
inheritance.

Google searches take me to old papers for C++ and Eiffel, but that
don't seem to be relevant to most Python programmers (i.e. a
WalkingMenu example where a submenu is both a Entry in a Menu and a
Menu itself).  Another published example is in a graphic library where
some widgets inherit GraphicalFeature methods such as location, size
and NestingGroupingFeatures such as finding parents, siblings, and
children.  I don't find either of those examples compelling because
there is no particular reason that they would have to have overlapping
method names.

So far, the only situation I can find where method names necessarily
overlap is for the basics like __init__(), close(), flush(), and
save() where multiple parents need to have their own initialization
and finalization.

If you guys know of good examples, I would appreciate a link or a
recap.

Thanks,


Raymond



--
http://mail.python.org/mailman/listinfo/python-list

Re: HTSQL 2.0 RC1 -- a Query Language for the Accidental Programmer

[Kirill Simonov]

On 01/22/2011 12:25 AM, rusi wrote:

On Jan 22, 2:45 am, "Clark C. Evans"  wrote:

Kirill Simonov and myself would like to introduce HTSQL, a novel
approach to relational database access which is neither an ORM nor raw SQL.

:

We're curious what you think.


Thanks -- looks interesting.

Given the claim htsql is higher level than sql I am interested in
bill-of-materials type (recursive) queries.


Currently HTSQL does not support recursive queries.  That said, it's 
certainly within the reach of HTSQL and I could sketch here how the 
support may look like:


We add an operator `closure()` that, given a self-referential link 
`link`, produces a transitive closure `closure(link)` of the link.


For example, take a table `program` with a link `program.part_of`.  Then 
`program.closure(part_of)` is a plural link mapping a program to its 
super-programs, which you can use just like a regular plural link, for 
instance, in aggregate expressions.


To return, for each program, a list of its super-programs:

/program{code, /closure(part_of){code}}

To return all sub-programs of a specific program 'xxx':

/program?exists(closure(part_of).code='xxx')

Compare that with

/program{code, part_of.code}
/program?part_of.code='xxx'

I think it would be a modest improvement over a SQL alternative.

I'm adding it to the roadmap right now, but don't hold your breath -- Q4 
this year or early next year is a realistic ETA.  I expect the 
implementation to be at least moderately painful and, obviously, it 
could only work with those backends that support WITH RECURSIVE.



Thanks,
Kirill
--
http://mail.python.org/mailman/listinfo/python-list

[ANN] PyYAML-3.09: YAML parser and emitter for Python

[Kirill Simonov]

 Announcing PyYAML-3.09


A new bug fix release of PyYAML is now available:

http://pyyaml.org/wiki/PyYAML

Note that PyYAML supports both Python 2 and Python 3.  For
compatibility notes, please see

http://pyyaml.org/wiki/PyYAMLDocumentation#Python3support


Changes
===

* Fixed compatibility issues with Python 3.1.
* Fixed use of uninitialized memory when emitting anchors with
  LibYAML bindings (Thank to cegner(at)yahoo-inc(dot)com).
* Fixed emitting incorrect BOM characters for UTF-16 (Thank to
  Valentin Nechayev)
* Fixed the emitter for folded scalars not respecting the preferred
  line width (Thank to Ingy).
* Fixed a subtle ordering issue with emitting '%TAG' directives
  (Thank to Andrey Somov).
* Fixed performance regression with LibYAML bindings.


Resources
=

PyYAML homepage: http://pyyaml.org/wiki/PyYAML
PyYAML documentation: http://pyyaml.org/wiki/PyYAMLDocumentation

TAR.GZ package: http://pyyaml.org/download/pyyaml/PyYAML-3.09.tar.gz
ZIP package: http://pyyaml.org/download/pyyaml/PyYAML-3.09.zip
Windows installers:
http://pyyaml.org/download/pyyaml/PyYAML-3.09.win32-py2.3.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.09.win32-py2.4.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.09.win32-py2.5.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.09.win32-py2.6.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.09.win32-py3.0.exe
http://pyyaml.org/download/pyyaml/PyYAML-3.09.win32-py3.1.exe

PyYAML SVN repository: http://svn.pyyaml.org/pyyaml
Submit a bug report: http://pyyaml.org/newticket?component=pyyaml

YAML homepage: http://yaml.org/
YAML-core mailing list: 
http://lists.sourceforge.net/lists/listinfo/yaml-core



About PyYAML


YAML is a data serialization format designed for human readability and
interaction with scripting languages.  PyYAML is a YAML parser and
emitter for Python.

PyYAML features a complete YAML 1.1 parser, Unicode support, pickle
support, capable extension API, and sensible error messages.  PyYAML
supports standard YAML tags and provides Python-specific tags that allow
to represent an arbitrary Python object.

PyYAML is applicable for a broad range of tasks from complex
configuration files to object serialization and persistance.


Example
===

>>> import yaml

>>> yaml.load("""
... name: PyYAML
... description: YAML parser and emitter for Python
... homepage: http://pyyaml.org/wiki/PyYAML
... keywords: [YAML, serialization, configuration, persistance, pickle]
... """)
{'keywords': ['YAML', 'serialization', 'configuration', 'persistance',
'pickle'], 'homepage': 'http://pyyaml.org/wiki/PyYAML', 'description':
'YAML parser and emitter for Python', 'name': 'PyYAML'}

>>> print yaml.dump(_)
name: PyYAML
homepage: http://pyyaml.org/wiki/PyYAML
description: YAML parser and emitter for Python
keywords: [YAML, serialization, configuration, persistance, pickle]


Copyright
=

The PyYAML module is written by Kirill Simonov .

PyYAML is released under the MIT license.
--
http://mail.python.org/mailman/listinfo/python-list

Fail 3.10.8 version installation on Windows 11 21H2

[Kirill Ratkin via Python-list]

Hi All,


Do anyone face issue like in log below?

I got last installer (3.10.8) and try to install it 'for all users' with 
downloading precompiled (pdb) files.


And installation fails saying permission error.

Installer says downloading error in the log.


I repeated it three times with same result



Just to test I got previous version (3.10.6) and it is installed without 
any errors with same installer settings.



 begin here  part of installer log file 
---


[183C:19E4][2022-10-12T12:01:23]e000: Error 0x80070005: Failed attempt 
to download URL: 
'https://www.python.org/ftp/python/3.10.8/amd64/core_pdb.msi' to: 
'C:\Users\Kirill\AppData\Local\Temp\{93FCA30B-7B82-4BF0-B911-5223F0E6A053}\core_AllUsers_pdb'
[183C:19E4][2022-10-12T12:01:23]w343: Prompt for source of package: 
core_AllUsers_pdb, payload: core_AllUsers_pdb, path: 
C:\Users\Kirill\Downloads\core_pdb.msi
[183C:19E4][2022-10-12T12:01:26]i338: Acquiring package: 
core_AllUsers_pdb, payload: core_AllUsers_pdb, download from: 
https://www.python.org/ftp/python/3.10.8/amd64/core_pdb.msi
[183C:19E4][2022-10-12T12:01:26]e000: Error 0x80070005: Failed attempt 
to download URL: 
'https://www.python.org/ftp/python/3.10.8/amd64/core_pdb.msi' to: 
'C:\Users\Kirill\AppData\Local\Temp\{93FCA30B-7B82-4BF0-B911-5223F0E6A053}\core_AllUsers_pdb'
[183C:19E4][2022-10-12T12:01:26]w343: Prompt for source of package: 
core_AllUsers_pdb, payload: core_AllUsers_pdb, path: 
C:\Users\Kirill\Downloads\core_pdb.msi
[183C:19E4][2022-10-12T12:01:29]i338: Acquiring package: 
core_AllUsers_pdb, payload: core_AllUsers_pdb, download from: 
https://www.python.org/ftp/python/3.10.8/amd64/core_pdb.msi
[183C:19E4][2022-10-12T12:01:29]e000: Error 0x80070005: Failed attempt 
to download URL: 
'https://www.python.org/ftp/python/3.10.8/amd64/core_pdb.msi' to: 
'C:\Users\Kirill\AppData\Local\Temp\{93FCA30B-7B82-4BF0-B911-5223F0E6A053}\core_AllUsers_pdb'
[183C:19E4][2022-10-12T12:01:29]w343: Prompt for source of package: 
core_AllUsers_pdb, payload: core_AllUsers_pdb, path: 
C:\Users\Kirill\Downloads\core_pdb.msi
[183C:19E4][2022-10-12T12:01:32]i338: Acquiring package: 
core_AllUsers_pdb, payload: core_AllUsers_pdb, download from: 
https://www.python.org/ftp/python/3.10.8/amd64/core_pdb.msi
[183C:19E4][2022-10-12T12:01:32]e000: Error 0x80070005: Failed attempt 
to download URL: 
'https://www.python.org/ftp/python/3.10.8/amd64/core_pdb.msi' to: 
'C:\Users\Kirill\AppData\Local\Temp\{93FCA30B-7B82-4BF0-B911-5223F0E6A053}\core_AllUsers_pdb'
[183C:19E4][2022-10-12T12:01:32]e000: Error 0x80070005: Failed to 
acquire payload from: 
'https://www.python.org/ftp/python/3.10.8/amd64/core_pdb.msi' to working 
path: 
'C:\Users\Kirill\AppData\Local\Temp\{93FCA30B-7B82-4BF0-B911-5223F0E6A053}\core_AllUsers_pdb'
[183C:19E4][2022-10-12T12:01:32]e313: Failed to acquire payload: 
core_AllUsers_pdb to working path: 
C:\Users\Kirill\AppData\Local\Temp\{93FCA30B-7B82-4BF0-B911-5223F0E6A053}\core_AllUsers_pdb, 
error: 0x80070005.
[08CC:3570][2022-10-12T12:01:32]i351: Removing cached package: 
core_AllUsers, from path: C:\ProgramData\Package 
Cache\{6463E43B-54B1-4407-818D-DD90D11CDD06}v3.10.8150.0\
[183C:313C][2022-10-12T12:01:32]e000: Error 0x80070005: Cache thread 
exited unexpectedly.


 end here  part of installer log file 
---



--
https://mail.python.org/mailman/listinfo/python-list

Re: is mypy failing here

[Kirill Ratkin via Python-list]

Hi Robin,

mypy --strict gives you detail info.

On Thu, Nov 24, 2022 at 10:05 +, Robin Becker wrote:
> I haven't used dataclasses or typing very much, but while playing about I 
> found this didn't give me an expected error
> 
> (.py312) robin@minikat:~/devel/reportlab
> $ cat tmp/examples/tdc.py && python tmp/examples/tdc.py && mypy 
> tmp/examples/tdc.py
> ##
> from dataclasses import dataclass
> 
> @dataclass
> class DC:
> a: str
> b: str
> 
> def main():
> dc = DC(DC, "B")
> print(dc)
> 
> if __name__ == "__main__":
> main()
> ##
> DC(a=, b='B')
> Success: no issues found in 1 source file
> (.py312) robin@minikat:~/devel/reportlab
> 
> DC.a is supposed to be a str and I expected mypy to indicate a type error
> 
> should typing work for this case?
> --
> Robin Becker
> -- 
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to detect an undefined method?

[Kirill Ratkin via Python-list]

Hi

You can get all methods of your object and check the method you want to 
call is there or not.


|methods = [method for method in dir() if 
callable(getattr(, method))] if 'method_you_need' in 
methods: . // BR |


27.03.2022 12:24, Manfred Lotz пишет:

Let's say I have a Python app and have used an undefined method somewhere. Let
us further assume I have not detected it thru my tests.

Is there a way to detect it before deploying the app? pylint doesn't notice it.


Minimal example:

#!/usr/bin/env python3

import logging
from logging import Logger
from random import randrange

def main():
 """
 Below logger.err gives

 'Logger' object has no attribute 'err'
 """

 logger = logging.getLogger('sample')
 logger.setLevel(logging.DEBUG)
 handler = logging.StreamHandler()
 logger.addHandler(handler)

 num = randrange(0,1000)
 if num == 0:
 logger.err("got zero")
 else:
 logger.info(f'got a positive integer: {num}')

if __name__ == "__main__":
 main()




--
https://mail.python.org/mailman/listinfo/python-list

Re: How to detect an undefined method?

[Kirill Ratkin via Python-list]

I just started to think from your example with method 'err' of logger 
object.
In this particular case you can check method 'err' exists or not before 
call this.



But if you mean general case ... . If for example I use some library 
which uses another library and someone just 'typo' there ...



Here is example from my code:

    calc: Calculator = Calculator()

    ...

    actions: Dict[str, Callable] = {
   "s.sysinfo":  calc.get_system_info,
   "s.setloglevel":  calc.set_log_level,
   ...
    }

    ...

    def do_action(action: str, params: Dict[str, str]) -> ActionResult:
    return await actions[action](params)


And if I make mistake and type 'calc.get_s*i*stem_info' instead 
'calc.get_s*y*stem_info. Error appears on rutime stage only.


And neither 'mypy --strict' or 'pyre' can find such error.


I guess there  is not warranty to detect such sitations in huge codebase.

It's python dynamic nature.


May be dynamic checkers can help in such situations ...


27.03.2022 20:07, Manfred Lotz пишет:

On 3/27/22 18:57, Kirill Ratkin wrote:

Hi

You can get all methods of your object and check the method you want to call is
there or not.

|methods = [method for method in dir() if
callable(getattr(, method))] if 'method_you_need' in methods:
. // BR |


I don't understand how this may help. Assume somebody has a codebase of 15T
lines of Python code. How do you want to apply your method?

But perhaps I overlook things.


--
https://mail.python.org/mailman/listinfo/python-list

Re: calling a function asynchronously

[Kirill Ratkin via Python-list]

Hi,

You can use asyncio.create_task and gather results. See docs -
https://docs.python.org/3/library/asyncio-task.html

But think twice what you want to do in async task. Do you use synchronous
requests to database? If yes it will blocks eventloop...

If you use Django it makes sense to use something like
'django-background-tasks'

It just saves your time possibly.

// BR

ср, 30 мар. 2022 г., 19:14 Larry Martell :

> I have a django app, and for a certain request I need to kick off a
> long running task. I want to do this asynchronously and immediately
> return a response. I tried using subprocess.Process() but the forked
> process does not have a django database connection. I then tried
> posting a request using ajax but that does not have a django session
> so it's not authorized. Tried using asyncio but I am finding the
> caller of the async function does not return until the async function
> returns - maybe I am doing something wrong, as it does appear to be
> actually asynchronous. I tried this test:
>
> import asyncio
> import time
>
> async def long():
> for i in range(100):
>time.sleep(10)
>
> asyncio.run(long())
> print('after asyncio.run')
>
> The final print does not come out until after long() completes.
>
> Is there any way to do this?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: calling a function asynchronously

[Kirill Ratkin via Python-list]

Hi again,

I changed a bit your example and it works as you expected I hope.

import asyncio


async def long():
    for i in range(100):
    await asyncio.sleep(10)
    print("long is done")


loop = asyncio.get_event_loop()

task = loop.create_task(long())
print('after asyncio.run')
loop.run_until_complete(asyncio.gather(task))


But how I wrote before ... if you are in big Django project just look at 
existent django libraries for long task running. One of it I sent you. 
There is 'celery' as well.


It's more pragmatic way ...

30.03.2022 19:10, Larry Martell пишет:

import asyncio
import time

async def long():
 for i in range(100):
time.sleep(10)

asyncio.run(long())
print('after asyncio.run')

--
https://mail.python.org/mailman/listinfo/python-list

Re: calling a function asynchronously

[Kirill Ratkin via Python-list]

Hi

30.03.2022 21:44, Larry Martell пишет:

On Wed, Mar 30, 2022 at 2:40 PM Kirill Ratkin via Python-list
  wrote:

Hi again,

I changed a bit your example and it works as you expected I hope.

import asyncio


async def long():
  for i in range(100):
  await asyncio.sleep(10)
  print("long is done")


loop = asyncio.get_event_loop()

task = loop.create_task(long())
print('after asyncio.run')
loop.run_until_complete(asyncio.gather(task))


But how I wrote before ... if you are in big Django project just look at
existent django libraries for long task running. One of it I sent you.
There is 'celery' as well.

It's more pragmatic way ...

Appreciate the reply. I did not know about django-background-tasks -
thanks. I've been trying to make use of that. I do not get the errors
I was getting before but it does not appear that my long running task
is running at all. Still debugging. But concerting asyncio - doesn't
run_until_complete block until long() completes?


Yes, It runs until the /future/ has completed.

In example above 'gather' is not necessary because you create one async 
task only.


You can pass 'task' to run_until_complete directly.

But if you create several tasks, all of it need to be run concurently 
and 'gather' does it.


import asyncio
import random


async def long(x):
    duration = random.randint(2, 5)
    await asyncio.sleep(duration)
    print(f"long is done {x} slept for {duration} seconds")


loop = asyncio.get_event_loop()

task1 = loop.create_task(long(1))
task2 = loop.create_task(long(2))
task3 = loop.create_task(long(3))

print('after asyncio.run')

loop.run_until_complete(asyncio.gather(task1, task2, task3))

So here run_until_complete will wait untill all three tasks complete  or 
cancel for some reasons (then exception happens. btw we don't handle it 
in example).



In your example you use 'asyncio.run'. Internally it does things like to 
this


def run(ft)
loop = asyncio.get_event_loop()
task = loop.create_task(ft())
loop.run_until_complete(asyncio.gather(task))

Of course real asyncio.run is much more complicated but model is same, i 
think.


It creates loop and future and 'run_until_complete' for future/task in 
the loop.


That's why you never get 'print' before asyncio.run finishes.


You also can split run_until_complete and gather.

s = asyncio.gather(task1, task2, task3)
print('after asyncio.run')
loop.run_until_complete(s)

Then 'gather' starts schedule all tasks before 'print' executes. For 
example, if you have some network IO operations instead this 'print' ... 
maybe few of your async tasks are done during this time.






30.03.2022 19:10, Larry Martell пишет:

import asyncio
import time

async def long():
  for i in range(100):
 time.sleep(10)

asyncio.run(long())
print('after asyncio.run')

--
https://mail.python.org/mailman/listinfo/python-list

--
https://mail.python.org/mailman/listinfo/python-list

Re: dict.get_deep()

[Kirill Ratkin via Python-list]

Hi Marco.

Recently I met same issue. A service I intergated with was documented 
badly and sent ... unpredictable jsons.


And pattern matching helped me in first solution. (later I switched to 
Pydantic models)


For your example I'd make match rule for key path you need. For example:


data = {"users": [{"address": {"street": "Baker"}}]}

match data:
    case {"users": [{"address": {"street": street}}]}:
    print(f"street: {street}")

    case _:
    print("unsupported message structure")


Structural matching gives you warranty you process exactly message you 
expect and explicitly discards messages with another structure.


But type is still issue. I don't know how to say 'street' must be 'str' 
not 'int'. That's why I switched to Pydantic.



02.04.2022 23:44, Marco Sulla пишет:

A proposal. Very often dict are used as a deeply nested carrier of
data, usually decoded from JSON. Sometimes I needed to get some of
this data, something like this:

data["users"][0]["address"]["street"]

What about something like this instead?

data.get_deep("users", 0, "address", "street")

and also, instead of this

try:
 result = data["users"][0]["address"]["street"]
except KeyError, IndexError:
 result = "second star"

write this:

data.get_deep("users", 0, "address", "street", default="second star")

?

--
https://mail.python.org/mailman/listinfo/python-list

Re: dict.get_deep()

[Kirill Ratkin via Python-list]

To my previous post.

It seems 'case if' should help with types:


case {"users": [{"address": {"street": street}}]} if isinstance(street, 
str):



:)

// BR

02.04.2022 23:44, Marco Sulla пишет:

A proposal. Very often dict are used as a deeply nested carrier of
data, usually decoded from JSON. Sometimes I needed to get some of
this data, something like this:

data["users"][0]["address"]["street"]

What about something like this instead?

data.get_deep("users", 0, "address", "street")

and also, instead of this

try:
 result = data["users"][0]["address"]["street"]
except KeyError, IndexError:
 result = "second star"

write this:

data.get_deep("users", 0, "address", "street", default="second star")

?

--
https://mail.python.org/mailman/listinfo/python-list