Should constants be introduced to Python?

[Saeed Baig]

Hey guys I am thinking of perhaps writing a PEP to introduce constants to 
Python. Something along the lines of Swift’s “let” syntax (e.g. “let pi = 
3.14”).

Since I’m sort of new to this, I just wanted to ask:
- Has a PEP for this already been written? If so, where can I find the 
link/info to it?
- Do you guys think it would be a good idea? Why or why not? Do you think 
there’s a better way to do it? I’d like to know what others think about this 
idea before making any formal submission.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To ASCII Or Not To ASCII? (Posting On Python-List Prohibited)

[Christian Gollwitzer]

Am 16.11.17 um 02:45 schrieb Lawrence D’Oliveiro:

 From :

 def raıse(self) :
 "raises this exception."
 libm.feraiseexcept(self.mask)
 #end raıse

 raiise = raıse # if you prefer


you do this to annoy people?

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

Re: Windows - py363 crashes with "vonLöwis.py"

[breamoreboy]

On Thursday, November 16, 2017 at 8:43:24 AM UTC, wxjm...@gmail.com wrote:
> Le mercredi 15 novembre 2017 23:43:46 UTC+1, Terry Reedy a écrit :
> > On 11/15/2017 6:58 AM, breamoreboy wrote:
> > > On Wednesday, November 15, 2017 at 8:53:44 AM UTC, wxjm...@gmail.com 
> > > wrote:
> > >> Sorry, to have to say it.
> > >>
> > >> Have a nice day.
> > > 
> > > Do you mean it segfaults or simply provides a traceback?  If the latter 
> > > is your environment set correctly?
> > 
> > Why bother?  Anyway, for the obvious interpretation of the message, 
> > given f:/python/a/vonLöwis.py containing 'print("works")'"
> > 
> > C:\Users\Terry>py -3.6 f:/python/a/vonLöwis.py
> > works
> > 
> > -- 
> > Terry Jan Reedy
> 
> Do you remember stringbench.py ? Years later, I still do
> not understand how it is possible to write a test module,
> which is supposed to test Unicode and does not even
> contain a non ascii char...

What has benchmarking (I assume) code got to do with your claim in the subject 
that Python 3.6 crashes?  I have never known any other person make this claim.

> 
> -
> 
> Quick experiment
> 
> 1) Download Py363, the embeded version. This just
> avoid a Python installation.
> 2) Unpacked it in a dir.
> 2) Put "café.py" in python36.zip
> 3) Launch python.exe

So I'll repeat my question, does it segfault or does it give a traceback?

> 
> -
> 
> You do not imagine how this language is problematic
> as soon as one leaves the ascii world (all platforms).
> It is better to not speak about the Flexible String
> Representation...

The thing that works perfectly all around the world except for one user, you.

> 
> Do not take this msg badly. It's only illustrating,
> some people are still living on an another planet.

It's quite clear that you're in another universe.  Unless of course you'd 
actually, for the first time ever, like to produce some evidence to support 
your claims.  I know that hell will freeze over before that happens.

> 
> Regards.

So how many bug reports have you raised over the years to report the dreadful 
state of Python's unicode implementation?  What is the difference between you 
running vonLöwis.py and Terry Reedy running it?  What is the difference between 
you running vonLöwis.py and café.py?  Why are you incapable of running code 
that tens of thousands of users all around the world are quite content with, to 
the extent that Python 3.6 is widely recognised as the best ever version of 
Python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Dropbox releases PyAnnotate -- auto-generate type annotations for mypy

[breamoreboy]

As type annotations seem to be taking off in a big way I thought that 
http://mypy-lang.blogspot.co.uk/2017/11/dropbox-releases-pyannotate-auto.html 
would be of interest, to some of you anyway.

--
Kindest regards.

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

Re: Windows - py363 crashes with "vonLöwis.py"

[Thomas Jollans]

On 2017-11-16 11:51, breamore...@gmail.com wrote:
> On Thursday, November 16, 2017 at 8:43:24 AM UTC, wxjm...@gmail.com wrote:
>> Le mercredi 15 novembre 2017 23:43:46 UTC+1, Terry Reedy a écrit :
>>> On 11/15/2017 6:58 AM, breamoreboy wrote:
 On Wednesday, November 15, 2017 at 8:53:44 AM UTC, wxjm...@gmail.com wrote:
>> 2) Put "café.py" in python36.zip

This is rather unorthodox. Perhaps the OP (or someone else) can clarify
whether this is necessary: does the non-ASCII filename have to be in the
stdlib zip? Does it have to be imported? Can it be in any other zip file
on sys.path? Also...


>> 3) Launch python.exe
> 
> So I'll repeat my question, does it segfault or does it give a traceback?

Indeed.


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

Re: from xx import yy

[bvdp]

On Tuesday, November 14, 2017 at 2:53:22 PM UTC-7, Cameron Simpson wrote:
> On 13Nov2017 08:58, bvdp  wrote:
> >On Sunday, November 12, 2017 at 7:18:04 PM UTC-7, bvdp wrote:
> >> I'm having a conceptual mind-fart today. I just modified a bunch of code 
> >> to use "from xx import variable" when variable is a global in xx.py. But, 
> >> when I change/read 'variable' it doesn't appear to change. I've written a 
> >> bit of code to show the problem:
> >>
> >> mod1.py
> >> myvar = 99
> >> def setvar(x):
> >> global myvar
> >> myvar = x
> >>
> >> test1.py
> >> import mod1
> >> mod1.myvar = 44
> >> print (mod1.myvar)
> >> mod1.setvar(33)
> >> print (mod1.myvar)
> >>
> >> If this test1.py is run myvar is fine. But, if I run:
> >>
> >> test2.py
> >> from mod1 import myvar, setvar
> >> myvar = 44
> >> print (myvar)
> >> setvar(33)
> >> print (myvar)
> >>
> >> It doesn't print the '33'.
> >>
> >> I thought (apparently incorrectly) that import as would import the name 
> >> myvar into the current module's namespace where it could be read by 
> >> functions in the module
> >
> >Thanks all for confirming that I was wrong to use "from .. import". Hmmm, 
> >perhaps for functions it might be okay. But, in most cases it's a lot more 
> >obvious to use module.function() when calling. Maybe a bit slower, but I'm 
> >sure it's negligible in most cases.
> 
> You're wrong to use it for this particular special case, and ony because you 
> lose the reference to the module itself, which means you're no longer 
> accessing 
> the _reference_ "mod1.myvar", you're accessing a copy of the reference. So 
> the 
> wrong reference gets changed.
> 
> In the general case, this isn't something people do a great deal. For most 
> imports you want access to things from the module with no intention of 
> changing 
> those references in the source module.
> 
> So "from xx import yy" is perfectly find for that, the most common use case.
> 
> Consider:
> 
>   from os.path import basename, dirname
> 
> Is your code more readable with:
> 
>   from os.path import basename, dirname
>   base_of_parent_dir = basename(dirname(some_path))
> 
> or as:
> 
>   import os.path
>   base_of_parent_dir = os.path.basename(os.path.dirname(some_path))
> 
> particularly when you make lots of such calls? I much prefer the former.
> 
> >And, yes, I am trying to share state info between modules. Is this a bad 
> >thing? I guess I would write getter() and setter() functions for all this. 
> >But 
> >that does seem to remind me too much of some other language :)
> 
> In controlled situations it can be ok. Usually I define a small class for 
> this 
> kind of thing and keep all the state in class instances. That way it can 
> scale 
> (keeping multiple "states" at once).
> 
> However, it does depend on your particular situation. I find situations where 
> I 
> want to directly change "global" values in other modules very rare, though 
> not 
> unknown.
> 
> Cheers,
> Cameron Simpson  (formerly c...@zip.com.au)

In my original case, I think (!!!), the problem was that I had a variable in 
mod1.py and when I did the "from mod1 import myvarible" all was fine. Python 
create a new local-to-the-module variable and initialized it to the value it 
was set to in mod1. And at this point all is well. But, when mod1 changed the 
value of myvariable the change didn't get passed to the other modules. Of 
course, the reason for my confusion is that I'm thinking that python is using 
pointers :) Opps.

Maybe we need pointers in python .
-- 
https://mail.python.org/mailman/listinfo/python-list

How to maintain same permissions on python dist-package after upgrade?

[Debraj Manna]

I am using a python package patroni version 1.0 on Ubuntu 14. On doing ls
-lrt /usr/local/lib/python2.7/dist-packages/ I am seeing the permission
like below

drwxr-sr-x4   root   staff 4096 Nov 6 14:29 patroni
drwxr-sr-x2   root   staff 4096 Nov 6 14:29 patroni-1.0-py2.7.egg-info

But once I upgrade the patroni via the command sudo pip install patroni
--upgrade I am seeing the permission of the patroni change after upgrade

drwxr-s---4   root   staff 4096 Nov 6 15:29 patroni
drwxr-s---2   root   staff 4096 Nov 6 15:29 patroni-1.3.6.dist-info

The installation output is attached (sudo-pip-install.txt).

If I don't use sudo and just do pip install patroni --upgrade it fails. The
output is attached (pip-install.txt).

Can someone let me know :-


   1. Why is the permission changing after upgrade?
   2. How can I have the same permission even after the upgrade?

Due to some other limitations I cannot switch to virtualenv like
environment now.
sudo pip install patroni  --upgrade
The directory '/home/ubuntu/.cache/pip/http' or its parent directory is not 
owned by the current user and the cache has been disabled. Please check the 
permissions and owner of that directory. If executing pip with sudo, you may 
want sudo's -H flag.
The directory '/home/ubuntu/.cache/pip' or its parent directory is not owned by 
the current user and caching wheels has been disabled. check the permissions 
and owner of that directory. If executing pip with sudo, you may want sudo's -H 
flag.
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90:
 InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause certain SSL 
connections to fail. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning
Collecting patroni
Requirement already up-to-date: requests in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Collecting cdiff (from patroni)
Requirement already up-to-date: six>=1.7 in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Collecting python-etcd<0.5,>=0.4.3 (from patroni)
Requirement already up-to-date: prettytable>=0.7 in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Requirement already up-to-date: tzlocal in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Requirement already up-to-date: boto in /usr/local/lib/python2.7/dist-packages 
(from patroni)
Collecting python-consul>=0.7.0 (from patroni)
  Downloading python_consul-0.7.2-py2.py3-none-any.whl
Requirement already up-to-date: psycopg2>=2.6.1 in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Requirement already up-to-date: kazoo==2.2.1 in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Requirement already up-to-date: urllib3>=1.9 in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Requirement already up-to-date: click>=4.1 in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Requirement already up-to-date: python-dateutil in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Collecting psutil (from patroni)
Requirement already up-to-date: PyYAML in 
/usr/local/lib/python2.7/dist-packages (from patroni)
Requirement already up-to-date: certifi>=2017.4.17 in 
/usr/local/lib/python2.7/dist-packages (from requests->patroni)
Requirement already up-to-date: chardet<3.1.0,>=3.0.2 in 
/usr/local/lib/python2.7/dist-packages (from requests->patroni)
Requirement already up-to-date: idna<2.7,>=2.5 in 
/usr/local/lib/python2.7/dist-packages (from requests->patroni)
Requirement already up-to-date: dnspython>=1.13.0 in 
/usr/local/lib/python2.7/dist-packages (from python-etcd<0.5,>=0.4.3->patroni)
Requirement already up-to-date: pytz in /usr/local/lib/python2.7/dist-packages 
(from tzlocal->patroni)
Installing collected packages: cdiff, python-etcd, python-consul, psutil, 
patroni
  Found existing installation: python-etcd 0.4.3
Uninstalling python-etcd-0.4.3:
  Successfully uninstalled python-etcd-0.4.3
  Found existing installation: python-consul 0.6.0
Uninstalling python-consul-0.6.0:
  Successfully uninstalled python-consul-0.6.0
  Found existing installation: patroni 1.0
Uninstalling patroni-1.0:
  Successfully uninstalled patroni-1.0
Successfully installed cdiff-1.0 patroni-1.3.6 psutil-5.4.1 python-consul-0.7.2 
python-etcd-0.4.5
You are using pip version 7.1.2, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.pip install patroni  --upgrade
/usr/local/lib/python2.7/dist-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90:
 InsecurePlatformWarning: A true SSLContext object is not available. This 
prevents urllib3 from configuring SSL appropriately and may cause certain SSL 
connections to fail. For more information, see 
https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.
  InsecurePlatformWarning

Re: Should constants be introduced to Python?

[Ned Batchelder]

On 11/16/17 1:16 AM, Saeed Baig wrote:

Hey guys I am thinking of perhaps writing a PEP to introduce constants to 
Python. Something along the lines of Swift’s “let” syntax (e.g. “let pi = 
3.14”).

Since I’m sort of new to this, I just wanted to ask:
- Has a PEP for this already been written? If so, where can I find the 
link/info to it?
- Do you guys think it would be a good idea? Why or why not? Do you think 
there’s a better way to do it? I’d like to know what others think about this 
idea before making any formal submission.


I don't know if a PEP like this has been attempted before.  They are all 
in one place (https://github.com/python/peps/), so it's not hard to find 
out.


But talking about it here first will be a good way to flesh out your 
ideas, hear the most likely objections, and so forth.


Start by telling us: Why should Python have constants?  Be specific: 
what current problems would it solve?


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

Re: Windows - py363 crashes with "vonLöwis.py"

[Terry Reedy]

On 11/16/2017 5:51 AM, breamore...@gmail.com wrote:

On Thursday, November 16, 2017 at 8:43:24 AM UTC, wxjm...@gmail.com wrote:


Mark: Jmf's troll posts to the Google group are not propagated to 
python-list and the gmane mirror except when people, like you here, 
quote him.  Please stop.

Do you remember stringbench.py ? Years later, I still do
not understand how it is possible to write a test module,
which is supposed to test Unicode and does not even
contain a non ascii char...


For the benefit of any unicode newbies who read Mark's post but
have not read
https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals 
,
by using \u, \U, and \N{name} escape sequences in string 
literals.


--
Terry Jan Reedy

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

Re: from xx import yy

[Cameron Simpson]

On 16Nov2017 09:42, bvdp  wrote:
In my original case, I think (!!!), the problem was that I had a variable in 
mod1.py and when I did the "from mod1 import myvarible" all was fine. Python 
create a new local-to-the-module variable and initialized it to the value it 
was set to in mod1. And at this point all is well. But, when mod1 changed the 
value of myvariable the change didn't get passed to the other modules. Of 
course, the reason for my confusion is that I'm thinking that python is using 
pointers :) Opps.


Maybe we need pointers in python .


Thinking about this as pointers works pretty well. We call them references in 
Python because they are not (or need not be) memory addresses and C pointers 
are memory addresses. However the model is the same: an arrow from a variable 
name pointing at the place a value (the object) is stored.


Look:

 mod1.py: x = 1

making:

 mod1.x --> 1

Now consider:

 mod2.py: from mod1 import x

Making:

 mod1.x --> 1
^
 mod2.x +

both referring to the "1" object.

Now:
 mod2.py: x = 2

Making:

 mod1.x --> 1
 mod2.x --> 2

You see that mod1 is not adjusted. Versus:

 mod2.py: import mod1

Making:

 mod2.mod1 --> mod1, mod1.x --> 1

Then:

 mod2.py: mod1.x = 2

Making:

 mod2.mod1 --> mod1, mod1.x --> 2

Because you're adjusting the reference "mod1.x", _not_ the distinct reference 
"mod2.x".


Cheers,
Cameron Simpson  (formerly c...@zip.com.au)

Draw little boxes with arrows.  It helps.   - Michael J. Eager
--
https://mail.python.org/mailman/listinfo/python-list

Re: Should constants be introduced to Python?

[Michael Torrie]

On 11/15/2017 11:16 PM, Saeed Baig wrote:
> - Do you guys think it would be a good idea? Why or why not? Do you
> think there’s a better way to do it? I’d like to know what others
> think about this idea before making any formal submission.

Except for forcing it to be read-only, there's absolutely no difference
between your idea of a constant and a normal module name in Python.
Since Python is a dynamic language, all names have to be looked up at
run time.  So there's really no speed benefit to having a special const
syntax.  In Python, we normally expect developers to act as consenting
adults.  Thus a constant is often denoted by an uppercase name (at least
in the scripts I've seen), similar to C or other languages.  We can just
say to developers, please don't rebind a name that's all capitals.
That's it.

Constants as you propose really only make sense in statically-typed,
compiled languages where the compiler replaces the constant names with
the values in the compiled code.  Doesn't work that way in Python, where
things are interpreted at run time.

That's my opinion anyway.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Should constants be introduced to Python?

[Terry Reedy]

On 11/16/2017 4:55 PM, Michael Torrie wrote:

On 11/15/2017 11:16 PM, Saeed Baig wrote:

- Do you guys think it would be a good idea? Why or why not? Do you
think there’s a better way to do it? I’d like to know what others
think about this idea before making any formal submission.


Except for forcing it to be read-only, there's absolutely no difference
between your idea of a constant and a normal module name in Python.
Since Python is a dynamic language, all names have to be looked up at
run time.  So there's really no speed benefit to having a special const
syntax.  In Python, we normally expect developers to act as consenting
adults.  Thus a constant is often denoted by an uppercase name (at least
in the scripts I've seen), similar to C or other languages.  We can just
say to developers, please don't rebind a name that's all capitals.
That's it.


The idea of named constants has been proposed before, and rejected 
pretty much for the reason you give above.



Constants as you propose really only make sense in statically-typed,
compiled languages where the compiler replaces the constant names with
the values in the compiled code.  Doesn't work that way in Python, where
things are interpreted at run time.


CPython, at least, already has anonymous constant objects.  Number and 
string literals are turned into objects when parsed.  I presume that all 
implementations do this.  Some constant expressions are replaced by 
(constant) objects during compiling, instead of when running.  For 
instance "n = 10 + 3' will run as 'n = 13', and "for lang in ('C', 
'Java', 'Python') will have the tuple pre-computed (whereas "for lang in 
['C', 'Java', 'Python] will have to construct the list each time run).


--
Terry Jan Reedy


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

Re: Should constants be introduced to Python?

[Chris Angelico]

On Fri, Nov 17, 2017 at 9:27 AM, Terry Reedy  wrote:
> CPython, at least, already has anonymous constant objects.  Number and
> string literals are turned into objects when parsed.  I presume that all
> implementations do this.  Some constant expressions are replaced by
> (constant) objects during compiling, instead of when running.  For instance
> "n = 10 + 3' will run as 'n = 13', and "for lang in ('C', 'Java', 'Python')
> will have the tuple pre-computed (whereas "for lang in ['C', 'Java',
> 'Python] will have to construct the list each time run).

Just to thoroughly confuse people, CPython can actually optimize one
into the other...

>>> def f():
...  for lang in ['C', 'Java', 'Python']:
...   print(lang)
...
>>> dis.dis(f)
  2   0 SETUP_LOOP  20 (to 22)
  2 LOAD_CONST   4 (('C', 'Java', 'Python'))
  4 GET_ITER
>>6 FOR_ITER12 (to 20)
  8 STORE_FAST   0 (lang)

  3  10 LOAD_GLOBAL  0 (print)
 12 LOAD_FAST0 (lang)
 14 CALL_FUNCTION1
 16 POP_TOP
 18 JUMP_ABSOLUTE6
>>   20 POP_BLOCK
>>   22 LOAD_CONST   0 (None)
 24 RETURN_VALUE

Since there's no way to get a reference to the underlying list during
iteration (which would allow you to mutate it), Python can happily
pretend that you used a tuple. Similarly with membership tests:

>>> dis.dis("x in [1,2,3,4,5]")
  1   0 LOAD_NAME0 (x)
  2 LOAD_CONST   5 ((1, 2, 3, 4, 5))
  4 COMPARE_OP   6 (in)
  6 RETURN_VALUE
>>> dis.dis("x in {1,2,3,4,5}")
  1   0 LOAD_NAME0 (x)
  2 LOAD_CONST   5 (frozenset({1, 2, 3, 4, 5}))
  4 COMPARE_OP   6 (in)
  6 RETURN_VALUE

However, outside of these special optimization cases, you're right
that a tuple is a constant and a list gets built at run time.

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

Re: Shoulid constants be introduced to Python?

[ROGER GRAYDON CHRISTMAN]

On Thu, Nov 16, 2017, Saeed Baig wrote:
>
Message: 7
>Date: Thu, 16 Nov 2017 17:16:11 +1100
>From: Saeed Baig 
>To: python-list@python.org
>Subject: Should constants be introduced to Python?
>Message-ID: <5d4da7b2-504a-4a3a-bace-ffadea1d2...@icloud.com>
>Content-Type: text/plain;  charset=utf-8
>
>Hey guys I am thinking of perhaps writing a PEP to introduce constants to
>Python. Something along the lines of Swift?s ?let? syntax (e.g. ?let pi =
>3.14?).
>
>Since I?m sort of new to this, I just wanted to ask:
>- Has a PEP for this already been written? If so, where can I find the
>link/info to it?
>- Do you guys think it would be a good idea? Why or why not? Do you think
>there?s a better way to do it? I?d like to know what others think about this
>idea before making any formal submission.


Well, pi already does have a value:

>>> import math

>>> math.pi

3.141592653589793

but it's not a constant in the sense you are looking for:

>>> math.pi = 2

>>> math.pi

2



The only PEP I saw that makes any mention of constants is the PEP 8 Style Guide,
which recommends all constants be named with all caps, such as "math.PI".
(Why the math module doesn't do that beats me, unless it is there for
hyster^H^H^H^H^Historical reasons.)

But certainly if we saw code like this:

AVOGRADO_NUMBER = x + 2

I would believe that code to be 'obviously' since it is clearly attempting to
modify
a constant -- and the naming convention tells me so.

Do you have any particular reason you wish to promote constants?
Is it anything beyond "because C++ and Java, etc. have them"?

Because do note all of those constants in those languages are *declared*
to be constants, and declarations (esp variable declarations) are notably
absent.
I took a peek at the PEP 484 about Type Hints, and I didn't see anything there
about constants either.

So if you want to make a proposal, I think you should provide a compelling
argument in favor of a name change.   Suggesting that an interpreted language
have all the features of a compiled language just does not seem to be sufficient
cause.   After all:

Python pretends to have 'private' and 'protected' data, by having 'hidden'
variables with leading underscores, but they really are none of the above.

Python claims to have immutable data types, but those immutable data types
may contain mutable elements, which are indeed quite mutable.

Python does range checking on list indexes, but will not at all complain if
your code accidentally goes one step before [0] and ends up at [-1].

Python allows these loopholes in with the expectation that the programmer
should know better.   I think the same thing would be true with constants.

If you need this crutch to protect yourself from accidentally clobbering
constants,
then do better.   If you only need it to for documentation purposes, just tweak
the documentation.

Roger Christman
Pennsylvania State University

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

Re: Artificial creating of [Lists], is it possible? the best way...

[Peter Pearson]

On Thu, 16 Nov 2017 10:47:53 -0800 (PST), jakub.raj...@gmail.com wrote:
> Hello, im working on school project, its deck game Sorry!
> I need to create specific lists:
> My idea is about to using for
> For i in range (n):
>i=[]

This will create n different empty lists, in succession, and
discard all but the last one, which will be bound to the name "i".

> I know, that there is no possibility to make it from number, but i
> havent idea, how to reach my wants Li/L"i"/L(i), how to make possible
> for lists?

You'll find that the people on this newsgroup are very helpful, but
they might (like me) be unable to discern what you're asking.


-- 
To email me, substitute nowhere->runbox, invalid->com.
-- 
https://mail.python.org/mailman/listinfo/python-list

Artificial creating of [Lists], is it possible? the best way...

[jakub . rajcok]

Hello, im working on school project, its deck game Sorry!
I need to create specific lists:
My idea is about to using for
For i in range (n):
   i=[]
I know, that there is no possibility to make it from number, but i havent idea, 
how to reach my wants Li/L"i"/L(i), how to make possible for lists?


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

Re: Artificial creating of [Lists], is it possible? the best way...

[MRAB]

On 2017-11-16 18:47, jakub.raj...@gmail.com wrote:

Hello, im working on school project, its deck game Sorry!
I need to create specific lists:
My idea is about to using for
For i in range (n):
i=[]
I know, that there is no possibility to make it from number, but i havent idea, how to 
reach my wants Li/L"i"/L(i), how to make possible for lists?



If you want multiple lists, make a list of lists:

my_lists = []

for i in range(n):
my_lists.append([])

Then you can say my_lists[0], my_lists[1], etc.
--
https://mail.python.org/mailman/listinfo/python-list

Re: How to maintain same permissions on python dist-package after upgrade?

[dieter]

Debraj Manna  writes:

> I am using a python package patroni version 1.0 on Ubuntu 14. On doing ls
> -lrt /usr/local/lib/python2.7/dist-packages/ I am seeing the permission
> like below
>
> drwxr-sr-x4   root   staff 4096 Nov 6 14:29 patroni
> drwxr-sr-x2   root   staff 4096 Nov 6 14:29 patroni-1.0-py2.7.egg-info
>
> But once I upgrade the patroni via the command sudo pip install patroni
> --upgrade I am seeing the permission of the patroni change after upgrade
>
> drwxr-s---4   root   staff 4096 Nov 6 15:29 patroni
> drwxr-s---2   root   staff 4096 Nov 6 15:29 patroni-1.3.6.dist-info
>
> The installation output is attached (sudo-pip-install.txt).
>
> If I don't use sudo and just do pip install patroni --upgrade it fails. The
> output is attached (pip-install.txt).
>
> Can someone let me know :-

Verify the "umask" effective for your "sudo" user, i.e.

   sudo bash
   umask

Should the "umask" result end in "7",
then this may be responsible for the permissions you observe.

On POSIX systems, the "umask" setting effects the permissions of newly
created directories and files.

Use "umask 0002" to change this setting temporarily.

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