Booleans currently have reasonable overrides for the bitwise binary
>>> True | False
>>> True & False
>>> True ^ False
However, the same cannot be said of bitwise unary complement, which
returns rather useless integer values:
Numpy's boolean type does the more useful (and more expected) thing:
How about changing the behaviour of bool.__invert__ to make it in line
with the Numpy boolean?
(i.e. bool.__invert__ == operator.not_)
On Apr 19, 2016 5:48 AM, "Paul Moore" <p.f.moore(a)gmail.com> wrote:
> > You say "should"? Do you mean that it is likely, or do you mean that it
> > what would happen in an ideal world? My college had CS students SSH
> > department's Linux server to compile and run their code, and many
> > don't believe that students should start with fancy IDE featues like,
> > syntax highlighting.
> I mean that that is what I hear people on lists like this saying as "a
> reasonable beginner environment". It means that the people I've
> introduced to Python (on Windows) have tended to end up using IDLE
> (either from the start menu or via "edit with IDLE" from the right
> click menu on a script).
But are they perhaps tending to use IDLE because you were the one
introducing them to it? Whether it is a recommended environment by the
consensus of mailing lists is hardly indicative that IDLE is what people
will start on.
> My experience (in business, environments) is that people expect an IDE
> when introduced to a new programming language, and IDLE, like it or
> not, is what is available out of the box with Python.
They expect it => they know what an IDE is. Programmers are already
half-intermediate, especially programmers who use IDEs.
> > You (and most regulars on this list) can adjust your shell to the way
> > like it, or use a more sophisticated shell, like IPython or bpython. On
> > other hand, changing shells and adding display hooks to site.py is not
> > option for those who don't know it's an option.
> As a "scripting expert" and consultant, I typically get asked to knock
> up scripts on a variety of environments. I do not normally have what
> I'd describe as "my shell", just a series of basic "out of the box"
> prompts people expect me to work at. So no, the luxury of configuring
> the default experience is *not* something I typically have.
I suggested a command-line switch.
> >> I view the REPL as more
> >> important for intermediate or advanced users who want to quickly test
> >> out an idea (at least, that's *my* usage of the REPL).
> > But that doesn't answer my question: would the proposed change hurt your
> > workflow?
> Yes. If I get a stack trace, I want it all. And if I print something
> out, I want to see it by default. The REPL for me is an investigative
> environment for seeing exactly what's going on.
And why is it an insufficient option for you to type, for example,
"_exfull()" to get the full trace?
> (Also, having the REPL behave differently depending on what version of
> Python I have would be a problem - backward compatibility applies here
> as much as anywhere else).
This is a concern, but not one that is enough, by itself, to justify the
status quo. I disagree that it applies *anywhere near as much* here, since
I don't see how it could break existing code. It will add a little
adjustment and a little more work sometimes, but it doesn't require, say,
refactoring a module, or every site page you ever downloaded.
I saw that there was recently a change to pep 8 to suggest adding a line
break before a binary operator. Pep 7 suggests the opposite:
> When you break a long expression at a binary operator, the operator goes
at the end of the previous line, e.g.:
> if (type->tp_dictoffset != 0 && base->tp_dictoffset == 0 &&
> type->tp_dictoffset == b_size &&
> (size_t)t_size == b_size + sizeof(PyObject *))
> return 0; /* "Forgive" adding a __dict__ only */
I imagine that some of the reasons for making the change in pep 8 for
readability reasons will also
translate to C; maybe pep 7 should also be updated.
On Apr 18, 2016 12:30 PM, "Wes Turner" <wes.turner(a)gmail.com> wrote:
> > I think the users of oneline.py could be people that now write lots of
> > bash scripts and work on the command line. So whenever someone asks a
> > question somewhere about how to do X on the linux command line, we
> > might have the answer: """
> > Q: On the linux commandline, how do I get only the filename from a
> > full path that is in $FILEPATH
> > A: Python has this. You can use the tools in os.path:
> > Filename:
> > $ oneline.py "os.path.basename('$FILEPATH')"
> > Path to directory:
> > $ oneline.py "os.path.dirname('$FILEPATH')"
> > """
> FILEPATH='for'"example');"'subprocess.call("cat /etc/passwd", shell=True)'
sys.argv (IFS=' ')
(considering adding an argument (in addition to the existing -m) for
> > This might be more appealing than python -c. The whole point is to
> > make Python's power available and visible for a larger audience.
> > -Koos
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas(a)python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
Python 3 becomes more and more popular and is close to a dangerous point
where it can become popular that Python 2. The PSF decided that it's
time to elaborate a new secret plan to ensure that Python users suffer
again with a new major release breaking all their legacy code.
The PSF is happy to announce that the new Python release will be
Why the version 8? It's just to be greater than Perl 6 and PHP 7, but
it's also a mnemonic for PEP 8. By the way, each minor release will now
multiply the version by 2. With Python 8 released in 2016 and one
release every two years, we will beat Firefox 44 in 2022 (Python 64) and
Windows 2003 in 2032 (Python 2048).
A major release requires a major change to justify a version bump: the
new killer feature is that it's no longer possible to import a module
which does not respect the PEP 8. It ensures that all your code is pure.
$ python8 -c 'import keyword'
Lib/keyword.py:16:1: E122 continuation line missing indentation or outdented
Lib/keyword.py:16:1: E265 block comment should start with '# '
Lib/keyword.py:50:1: E122 continuation line missing indentation or outdented
ImportError: no pep8, no glory
Good news: since *no* module of the current standard library of Python 3
respect the PEP 8, the standard library will be simplified to one
unique module, which is new in Python 8: pep8. The standard library will
move to the Python Cheeseshop (PyPI), to reply to an old and popular
DON'T PANIC! You are still able to import your legacy code into
Python 8, you just have to rename all your modules to add a "_noqa" suffix
to the filename. For example, rename utils.py to utils_noqa.py. A side
effect is that you have to update all imports. For example, replace
"import django" with "import django_noqa". After a study of the PSF,
it's a best option to split again the Python community and make sure
that all users are angry.
The plan is that in 10 years, at least 50% of the 77,000 packages on the
Python cheeseshop will be updated to get the "_noqa" tag. After 2020,
the PSF will start to sponsor trolls to harass users of the legacy
Python 3 to force them to migrate to Python 8.
Python 8 is a work-in-progress (it's still an alpha version), the
standard library was not removed yet. Hopefully, trying to import any
module of the standard library fails.
Don't hesitate to propose more ideas to make Python 8 more incompatible
with Python 3!
Note: The change is already effective in the default branch of Python:
Every now and then there's been talk of making it easier to subclass
modules, and the most common use case that I can remember hearing
about is descriptor protocol requiring code on the type. (For
instance, you can't change a module-level constant into a property
without moving away from the default ModuleType.)
How bad would it be for the default ModuleType to have a __getattr__
function which defers to the instance? Something like this:
def __getattr__(self, name):
if '__getattr__' in self.__dict__:
The biggest downside I'm seeing is that module attributes double as
global names, which might mean this would get checked for every global
name that ends up being resolved from the builtins (which is going to
be a LOT). But I'm not sure if that's even true.
Dumb idea? Already been thought of and rejected?
I have been looking over the toolz library and one of the functions I like the most is pipe. Since most programmers are familiar with piping (via the Unix `|` symbol), and it can help make tighter code, I think it would be nice to add it to the standard library (such as functools).
- Ed Minnix
Is there any mileage in having a naming convention to indicate the type of
a variable? I have never really liked the fact that the Python 'duck
typing' policy is so lax, yet the new "Type Hints" package for Python 3 is
rather clumsy, IMO.
github_response = requests.get('https://api.github.com/user',
# Derived from http://docs.python-requests.org/en/master.
The above request returns a Response
and so the variable has 'response' in its name.
word_count = total_words_in_file('text_file')
where 'count' has been defined (in the IDE, by the user perhaps) as an
Integer and the function is known to return an Integer, perhaps via a local
'count' or 'total' variable.
I know that this has been attempted before but I think that an IDE like
PyCharm could actually check variable usage and issue a warning if a
conflict is detected. Also earlier usages of this 'Hungarian Notation' have
largely been applied to compiled languages - rather strangely, in the case
of known types - rather than an interpreted one like Python.
Please note that I have shown suffixes above but prefixes could also be
valid. I am not sure about relying on 'type strings' *within* a variable
Is this idea feasible, do you think?
PS Originally posted in