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

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

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

чт, 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(dum

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

чт, 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 htt

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

чт, 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 = "

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

чт, 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(dum

Difference between os.path.isdir and Path.is_dir

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: How to achieve pyc only deployment for module in python3.6

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

Re: [OT] master/slave debate in Python

пн, 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 chang

Re: Python aliases under Windows?

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 t

Re: Python aliases under Windows?

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 >

Re: Python aliases under Windows?

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

Re: Python aliases under Windows?

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-

Python aliases under Windows?

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

Re: check if bytes is all nulls

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 bef

Re: check if bytes is all nulls

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: Do not promote `None` as the first argument to `filter` in documentation.

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

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

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 e

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

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

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

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

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

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

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

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 accepta

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

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 p

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

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 sho

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

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 wo

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

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

Ways to make a free variable local to a function?

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 e

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

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 kw

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

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

Re: Questions about `locals` builtin

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 u

Re: Questions about `locals` builtin

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

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

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

Implicit conversion to str in str.join method?

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

Questions about `locals` builtin

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 func

Re: Python on Android?

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

Re: python to C code generator

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

Creation of a metaclass for dataclass.

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 obtai

Re: Default annotations for variables

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 IP

Re: Default annotations for variables

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 do

Default annotations for variables

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

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

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

Re: Problem with assignment. Python error or mine?

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,

Fwd: property decorator?

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

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

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 i

What is the future of the PEP 467?

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() an

Performance of map vs starmap.

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