Re: Overriding True and False ?

[Ben Finney]

Irv Kalb  writes:

> I teach intro to programming using Python. […]

Thank you for teaching Python to beginners!

> It seems very odd that Python allows you to override the values of
> True and False.

Yes, it is. That's why Python 3 forbids it::

>>> True = "shadow"
  File "", line 1
SyntaxError: can't assign to keyword
>>> False = "light"
  File "", line 1
SyntaxError: can't assign to keyword

When teaching Python, please do not teach Python 2. Your students should
learn Python 3 first, primarily, and for most of the course.

Python 2 is a legacy that will never gain new features, and will only
slip further behind the current supported Python version. That makes
Python 2 a poor choice for teaching to beginners.

-- 
 \  “The entertainment industry calls DRM "security" software, |
  `\ because it makes them secure from their customers.” —Cory |
_o__) Doctorow, 2014-02-05 |
Ben Finney

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

[issue15373] copy.copy() does not properly copy os.environment

[INADA Naoki]

INADA Naoki added the comment:

patch looks OK.
But I prefer `__deepcopy__ = __copy__ = copy`.

I don't know how to support pickling. (should unpickled object
reference os.environ, or copied dict?)
I feel it is different issue.

--
nosy: +inada.naoki

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

RE: Overriding True and False ?

[Deborah Swanson]

Irv Kalb wrote, on Sunday, January 29, 2017 9:04 PM
> 
> I teach intro to programming using Python.  In my first 
> assignment, students are asked to assign variables of 
> different types and print out the values.  
> 
> One student (who really did not understand Booleans) turned 
> in the following for his/her interpretation of Booleans (Python 2.7):
> 
> True = 'shadow'
> False = 'light'
> print "If the sun is behind a cloud, there is", True
> print "If it is a clear day, there is", False
> 
> And it printed:
> 
> If the sun is behind a cloud, there is shadow
> If it is a clear day, there is light
> 
> 
> It seems very odd that Python allows you to override the 
> values of True and False.  In the code, True and False were 
> clearly recognized as keywords as they were colored purple.  
> But there was no error message.
> 
> You cannot assign new values to other keywords.  Simple tests 
> of things like:
> 
> for = 5
> 
> while = 2
> 
> not = 3
> 
> As expected, all result in SyntaxError: invalid syntax.  Why 
> would Python allow you to override the values of True and 
> False?  I wonder if this is some sort of historical thing as 
> these are the only keywords besides None that are uppercased. 
>  This line:
> 
> None = 5
> 
> Even gives a special SyntaxError: cannot assign to None
> 
> Just curious,
> 
> Irv

Just guessing, but in the examples you give in Python 2.7, substitute
strings are syntactically correct in print statements, but:

5 in list('abc'):

2 True:

if a 3 b:

would all be syntactical errors.

As is 'None = 5'.

Looks like the moral of the story is that in Python 2.7 you can redefine
keywords, so long as you don't get any syntax errors after (or during)
redefinition.

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

Re: What are your opinions on .NET Core vs Python?

[denis . akhiyarov]

On Sunday, January 29, 2017 at 4:00:27 PM UTC-6, Gregory Ewing wrote:
> Joseph L. Casale wrote:
> >>.NET is a library that can be used from many languages, including Python. 
> >
> > No.
> 
> Yes:
> 
> http://pythonnet.sourceforge.net/
> 
> "Python for .NET is a package that gives Python programmers nearly seamless 
> integration with the .NET Common Language Runtime (CLR) and provides a 
> powerful 
> application scripting tool for .NET developers. Using this package you can 
> script .NET applications or build entire applications in Python, using .NET 
> services and components written in any language that targets the CLR (Managed 
> C++, C#, VB, JScript)."
> 
> -- 
> Greg

This is outdated location. pythonnet (python for .NET) is on GitHub since 2014.

https://github.com/pythonnet/pythonnet

We just released v2.2.2 with Python 3.6 support and transition to MIT license.

Download from PYPI using pip or from Anaconda using conda:

https://pypi.python.org/pypi/pythonnet/2.2.2
https://anaconda.org/pythonnet/pythonnet

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

Re: Overriding True and False ?

[INADA Naoki]

It's fixed already in Python 3.
Please use Python 3 when teaching to students.

$ python3
Python 3.6.0 (default, Dec 24 2016, 00:01:50)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> True = "foo"
  File "", line 1
SyntaxError: can't assign to keyword
-- 
https://mail.python.org/mailman/listinfo/python-list

Overriding True and False ?

[Irv Kalb]

I teach intro to programming using Python.  In my first assignment, students 
are asked to assign variables of different types and print out the values.  

One student (who really did not understand Booleans) turned in the following 
for his/her interpretation of Booleans (Python 2.7):

True = 'shadow'
False = 'light'
print "If the sun is behind a cloud, there is", True
print "If it is a clear day, there is", False

And it printed:

If the sun is behind a cloud, there is shadow
If it is a clear day, there is light


It seems very odd that Python allows you to override the values of True and 
False.  In the code, True and False were clearly recognized as keywords as they 
were colored purple.  But there was no error message.

You cannot assign new values to other keywords.  Simple tests of things like:

for = 5

while = 2

not = 3

As expected, all result in SyntaxError: invalid syntax.  Why would Python allow 
you to override the values of True and False?  I wonder if this is some sort of 
historical thing as these are the only keywords besides None that are 
uppercased.  This line:

None = 5

Even gives a special SyntaxError: cannot assign to None

Just curious,

Irv


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

RE: What are your opinions on .NET Core vs Python?

[Joseph L. Casale]

> What .NET APIs are anticipated to be released that aren't on the
> official CLI list now:
> https://en.wikipedia.org/wiki/List_of_CLI_languages#Current_Languages,
> and/or, are .NET supported languages expected to expand beyond the CLI
> list?

I think this (and the last point) misinterprets the semantics of the OPs post.

.NET Core is not .NET, it's a **multi-platform** framework for a language
syntax specification (c#). It's not an implementation of some API that you
cannleverage in another language specification.

Writing a ctype accessor for a Windows API does not equate to cpp code
that is now magically Python. It means no more than what it is, "a foreign
function library for Python" (https://docs.python.org/3/library/ctypes.html).

.Net Core is fundamentally different and much like Python in the way that
a compiler and runtime for a common language syntax specification has been
written for multiple platforms. So in general, the same Python script could
run on both platforms, and most certainly the same .NET Core source could
compile and run on its supported platforms.

So back to the question, .NET Core is a wip which where applicable will soon
present all the existing .NET APIs, excluding those which are Windows specific
and don't make sense to present on a non-Windows platform like Windows Forms.

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

Re: GeneratorExit masks StopIteration?

[inyeol . lee]

On Sunday, January 29, 2017 at 10:47:09 PM UTC-8, Chris Angelico wrote:
> On Mon, Jan 30, 2017 at 5:38 PM,   wrote:
> > On Sunday, January 29, 2017 at 9:54:44 PM UTC-8, Chris Angelico wrote:
> >> ...
> >> When you close() a generator, it raises GeneratorExit into it, and
> >> then silences any StopIteration or GeneratorExit that comes out of it.
> >
> > Chris,
> > Thanks for the info. Is this (GenExit silencing StopIteration) documented 
> > somewhere?
> > I was suspecting this but couldn't find any reference.
> 
> Actually. think this might be incorrect. I didn't look in the
> docs, I looked in the source code, so my information is guaranteed
> accurate

I found PEP-342 describes this behavior - silencing other GenExit or 
StopIteration.

BTW, the reason why I was checking this was to find a solution on how to get 
return value from coroutine without relying on some sentinel value, something 
like (not tested):

def accumulator():
  sum = 0
  try:
while True:
  sum += yield
  except GeneratorExit:
return sum

Any alternatives? Explicitly throwing GenExit looks like a hack.

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

[issue29385] Sockets Crashes or Memory Corruption

[INADA Naoki]

INADA Naoki added the comment:

I can't reproduce it because of some reason.

1. While you report it affects Python 3.3~3.7, the script doesn't work on 
Python 3.7
2. I've fixed webserver.py to work on Python 3, but it uses very old (draft) 
websocket protocol.  Current browser doesn't send headers like 
"Sec-WebSocket-Key1".
3. Even if handshake succeed, you can't send `\xff`*10 directly.  You should 
wrap it with "frame", specified in RFC.

I can't understand what "Close/Crash" means.
But I propose you to use websocket libraries, or read protocol specification 
carefully.
WebSocket is not "raw TCP socket after handshake", it's framed protocol on top 
of TCP (or other stream protocol).

--
nosy: +inada.naoki
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: GeneratorExit masks StopIteration?

[Chris Angelico]

On Mon, Jan 30, 2017 at 5:38 PM,   wrote:
> On Sunday, January 29, 2017 at 9:54:44 PM UTC-8, Chris Angelico wrote:
>> ...
>> When you close() a generator, it raises GeneratorExit into it, and
>> then silences any StopIteration or GeneratorExit that comes out of it.
>
> Chris,
> Thanks for the info. Is this (GenExit silencing StopIteration) documented 
> somewhere?
> I was suspecting this but couldn't find any reference.

Actually. think this might be incorrect. I didn't look in the
docs, I looked in the source code, so my information is guaranteed
accurate; this is where I would expect the information to be:

https://docs.python.org/3/reference/expressions.html#generator.close

As a general rule, a generator shouldn't be leaking StopIteration. In
a future version of Python, this will trigger RuntimeError. (You can
get that behaviour in 3.6 with a future import, too.) So what this
really means is that close() will suppress any GeneratorExit, or the
generator returning, both of which are normal occurrences. The only
significant thing is that the generator's return value could usefully
be propagated out of close().

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

Re: GeneratorExit masks StopIteration?

[inyeol . lee]

On Sunday, January 29, 2017 at 9:54:44 PM UTC-8, Chris Angelico wrote:
> ...
> When you close() a generator, it raises GeneratorExit into it, and
> then silences any StopIteration or GeneratorExit that comes out of it.

Chris,
Thanks for the info. Is this (GenExit silencing StopIteration) documented 
somewhere?
I was suspecting this but couldn't find any reference.

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

Display a label while pressing the button in my GUI

[hmmeeranrizvi18]

Hello Guys,
Here i am creating a GUI which will act as a search engine that will find the 
results from the browser and save the results as a xls file.
When i typed something in my search box and click the (GO)button.It should 
display search in progress.when the file is saved it should display done.
How to do that?
My button gets hung for a seconds.We should give any timeout for that?

Here is my script

from Tkinter import *
import mechanize
def clear_search(event):
search.delete(0,END)
obj = Tk()
Label = Label(obj,text="Top Findings:",font="-weight bold")
search = Entry(obj,width=100)
search.insert(0, "Enter the value to search")
search.bind("", clear_search)
def fun():
new = search.get()
url = "http://duckduckgo.com/html;
br = mechanize.Browser()
br.set_handle_robots(False)
br.open(url)
br.select_form(name="x")
br["q"] = str(new)
res = br.submit()
content = res.read()
with open("result1.xls", "w") as f:
f.write(content)
fun()
Go = Button(obj,text="GO",width=5,command=fun)
Label.pack()
search.pack()
Go.pack()
mainloop()

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

RE: GeneratorExit masks StopIteration?

[Deborah Swanson]

inyeol@gmail.com wrote, on January 29, 2017 9:24 PM

> 
> Does generator.close() prevent raising StopIteration?
> 
> I'm trying to get the return value from coroutine after 
> terminating it. Here is simple test code:
> 
> $ python3
> Python 3.6.0 (default, Dec 23 2016, 12:50:55) 
> [GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on 
> darwin Type "help", "copyright", "credits" or "license" for 
> more information.
> >>> def cor():
> ...   try:
> ... item = yield
> ...   except GeneratorExit:
> ... return 1
> ... 
> >>> c = cor()
> >>> next(c)
> >>> c.close()
> >>>
> 
> I was expecting StopIteration from c.close() call, but Python 
> 3.6 doesn't raise any. Is this behavior expected? I couldn't 
> find any reference regarding GeneratorExit and StopIteration 
> interaction.

Use except StopIteration:

(Not sure what generator.close() should do, or if GeneratorExit is any
kind of equivalent, but StopIteration works. I'm less familiar with
Python 2.)

Python 3.4.3 |Anaconda 2.3.0 (32-bit)| (default, Mar  6 2015, 12:08:17)
[MSC v.1600 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.
>>> help(generator.close)
Traceback (most recent call last):
  File "", line 1, in 
help(generator.close)
NameError: name 'generator' is not defined

So at the very least, generator needs to be defined, if it's possible to
define or import it in Python 3. Probably not.

In Python 2, GeneratorExit is raised when the generator's close() method
is called. But in my quick search, I couldn't find GeneratorExit in
Python 3, or any note that it had been dropped, but it's a good guess
that it was dropped. It's redundant with StopIteration.

I always use StopIteration. It works in all Python versions.

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

Re: Is shutil.get_terminal_size useless?

[Wildman via Python-list]

On Sat, 28 Jan 2017 19:03:42 +1100, Steve D'Aprano wrote:

> shutil.get_terminal_size returns the wrong values when you pipe your output
> to another process, even it you do so in a terminal. Consider this script:
> 
> 
> import os
> import shutil
> print('shutil:', shutil.get_terminal_size(fallback=(999, 999)))
> print('os:', os.get_terminal_size(0))
> 
> 
> That uses two different methods to get the terminal size. If I run that in a
> terminal in the normal way, it works fine, returning the correct size for
> my terminal:
> 
> 
> [steve@ando ~]$ python3.5 test_gts.py
> shutil: os.terminal_size(columns=116, lines=29)
> os: os.terminal_size(columns=116, lines=29)
> 
> 
> But if I pipe the output to something else, the shutil version fails to
> determine the correct terminal size, and falls back on the default:
> 
> 
> [steve@ando ~]$ python3.5 test_gts.py | cat
> shutil: os.terminal_size(columns=999, lines=999)
> os: os.terminal_size(columns=116, lines=29)
> 
> 
> while the os version gives the correct result.
> 
> Is shutil.get_terminal_size useless? When, if ever, should I use it in
> preference to the os version? If the shutil version is broken, can it be
> fixed?
> 
> 
> Thanks to Bernardas Ališauskas:
> 
> http://granitosaurus.rocks/getting-terminal-size.html

I can suggest a third approach to try but I have not tried
piping it.  YMMV.

import fcntl
import os
import struct
import termios

tty = os.open(os.ctermid(), os.O_RDONLY)
ts = struct.unpack("hh", fcntl.ioctl(tty, termios.TIOCGWINSZ, "1234"))
os.close(tty)
columns = ts[1]
rows = ts[0]
print(str(columns) + "x" + str(rows))

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: GeneratorExit masks StopIteration?

[Chris Angelico]

On Mon, Jan 30, 2017 at 4:24 PM,   wrote:
> I was expecting StopIteration from c.close() call, but Python 3.6 doesn't 
> raise any.
> Is this behavior expected? I couldn't find any reference regarding 
> GeneratorExit and StopIteration interaction.

When you close() a generator, it raises GeneratorExit into it, and
then silences any StopIteration or GeneratorExit that comes out of it.
If you need different behaviour, what you could do is explicitly
throw() into it:

>>> c.throw(GeneratorExit)
Traceback (most recent call last):
  File "", line 1, in 
StopIteration: 1

which you'd obviously want to wrap in try/except, but at that point,
you have the result.

Maybe this could be a feature request - that generator.close() returns
the return value of the generator (or None if the GeneratorExit comes
out)?

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

Re: Is shutil.get_terminal_size useless?

[Steven D'Aprano]

On Monday 30 January 2017 08:12, Serhiy Storchaka wrote:

> On 28.01.17 10:03, Steve D'Aprano wrote:
>> Is shutil.get_terminal_size useless? When, if ever, should I use it in
>> preference to the os version? If the shutil version is broken, can it be
>> fixed?
> 
> Read the history of shutil.get_terminal_size(). All this was discussed.


Yes, it was discussed, but not resolved: Antoine Pitrou just closed the task 
and declared it done, without resolving the failures I am talking about here.

http://bugs.python.org/issue13609

(Thanks Eryk Sun for the link.)



-- 
Steven
"Ever since I learned about confirmation bias, I've been seeing 
it everywhere." - Jon Ronson

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

GeneratorExit masks StopIteration?

[inyeol . lee]

Does generator.close() prevent raising StopIteration?

I'm trying to get the return value from coroutine after terminating it.
Here is simple test code:

$ python3
Python 3.6.0 (default, Dec 23 2016, 12:50:55) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> def cor():
...   try:
... item = yield
...   except GeneratorExit:
... return 1
... 
>>> c = cor()
>>> next(c)
>>> c.close()
>>>

I was expecting StopIteration from c.close() call, but Python 3.6 doesn't raise 
any.
Is this behavior expected? I couldn't find any reference regarding 
GeneratorExit and StopIteration interaction.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29070] Integration tests for pty.spawn on Linux and all other platforms

[Martin Panter]

Martin Panter added the comment:

Can you explain your broken pipe situation? Are you talking about a real-world 
EPIPE operating on a pseudoterminal, or just a result of using a Unix socket to 
emulate a PTY in the tests? Usually a broken pipe is an asynchronous condition. 
You cannot predict exactly when it will happen without knowing the state of the 
other end, OS implementation, buffering, etc. It does not seem appropriate to 
change the _copy() loop around unless there is an real bug.

Regarding the buildbots, if I get this patch into a state that I am comfortable 
committing, the buildbots will are generally set to timeout in 15 or 20 
minutes. See the “make buildbottest” commands in Makefile.pre.in, test.regrtest 
--timeout option, etc. You can also see which platforms have buildbots, and the 
state of them etc: .

I left a bunch of comments in the code review. There is a lot of useful code in 
there, but also a lot of stuff that is hard to follow or that I want to clean 
up.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Rename file without overwriting existing files

[Cameron Simpson]

On 30Jan2017 13:49, Steve D'Aprano  wrote:

This code contains a Time Of Check to Time Of Use bug:

   if os.path.exists(destination)
   raise ValueError('destination already exists')
   os.rename(oldname, destination)


In the microsecond between checking for the existence of the destination and
actually doing the rename, it is possible that another process may create
the destination, resulting in data loss.

Apart from keeping my fingers crossed, how should I fix this TOCTOU bug?


For files this is a problem at the Python level. At the UNIX level you can play 
neat games with open(2) and the various O_* modes.


however, with directories things are more cut and dry. Do you have much freedom 
here? What's the wider context of the question?


Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Rename file without overwriting existing files

[MRAB]

On 2017-01-30 03:27, Chris Angelico wrote:

On Mon, Jan 30, 2017 at 1:49 PM, Steve D'Aprano
 wrote:

This code contains a Time Of Check to Time Of Use bug:

if os.path.exists(destination)
raise ValueError('destination already exists')
os.rename(oldname, destination)


In the microsecond between checking for the existence of the destination and
actually doing the rename, it is possible that another process may create
the destination, resulting in data loss.

Apart from keeping my fingers crossed, how should I fix this TOCTOU bug?


The Linux kernel (sorry, I don't know about others) provides a
renameat2() system call that has the option of failing if the
destination exists. However, I can't currently see any way to call
that from CPython. Seems like an excellent feature request - another
keyword-only argument for os.rename(), like the directory file
descriptors.


On Windows it raises FileExistsError if the destination already exists.

shutil.move, on the other hand, replaces if the destination already exists.

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

[issue29381] Tutorial documentation contains undefined reference to #!

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

Thanks for the feedback, Raymond. I adjusted my patch.

--
Added file: http://bugs.python.org/file46453/issue29381v2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Rename file without overwriting existing files

[Chris Angelico]

On Mon, Jan 30, 2017 at 1:49 PM, Steve D'Aprano
 wrote:
> This code contains a Time Of Check to Time Of Use bug:
>
> if os.path.exists(destination)
> raise ValueError('destination already exists')
> os.rename(oldname, destination)
>
>
> In the microsecond between checking for the existence of the destination and
> actually doing the rename, it is possible that another process may create
> the destination, resulting in data loss.
>
> Apart from keeping my fingers crossed, how should I fix this TOCTOU bug?

The Linux kernel (sorry, I don't know about others) provides a
renameat2() system call that has the option of failing if the
destination exists. However, I can't currently see any way to call
that from CPython. Seems like an excellent feature request - another
keyword-only argument for os.rename(), like the directory file
descriptors.

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

[issue29248] os.readlink fails on Windows

[Eryk Sun]

Eryk Sun added the comment:

os.symlink calls CreateSymbolicLink, which creates the reparse data buffer with 
the print name stored first, so the offset is always 0. Otherwise we would have 
noticed this problem already. For example:

>>> os.symlink('C:\\', 'link', True)
>>> os.system('fsutil reparsepoint query link')
Reparse Tag Value : 0xa00c
Tag value: Microsoft
Tag value: Name Surrogate
Tag value: Symbolic Link

Reparse Data Length: 0x0020
Reparse Data:
:  06 00 0e 00 00 00 06 00  00 00 00 00 43 00 3a 00  C.:.
0010:  5c 00 5c 00 3f 00 3f 00  5c 00 43 00 3a 00 5c 00  \.\.?.?.\.C.:.\.

As you can see above, CreateSymbolicLink stores the "PrintName" DOS path (e.g. 
"C:\") first, with an offset of 0, followed by the "SubstituteName" NT path 
(e.g. "\??\C:\").

The "All Users" link, on the other hand, seems to have been created manually 
with an inverted order. I have ctypes code to manually create a similar link 
(calling OpenProcessToken/AdjustTokenPrivileges to enable the required 
privilege and CreateFile/DeviceIoControl to set the reparse point), but I doubt 
it's worth adding it just to test this bug.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29381] Tutorial documentation contains undefined reference to #!

[Raymond Hettinger]

Raymond Hettinger added the comment:

Suggestions:

* Please add a cross-link to from '''UNIX “shebang” line"''' to 16.1.2. 
Executable Python Scripts.

* Instead of a link to a PEP (which is outside the main documentation), let's 
just add an example:

   # /usr/bin/env python3
   # -*- coding: cp-1252 -*-

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Is shutil.get_terminal_size useless?

[eryk sun]

On Mon, Jan 30, 2017 at 2:16 AM, Steve D'Aprano
 wrote:
> On Mon, 30 Jan 2017 08:12 am, Serhiy Storchaka wrote:
>
>> On 28.01.17 10:03, Steve D'Aprano wrote:
>>> Is shutil.get_terminal_size useless? When, if ever, should I use it in
>>> preference to the os version? If the shutil version is broken, can it be
>>> fixed?
>>
>> Read the history of shutil.get_terminal_size(). All this was discussed.
>
> Where?

See issue 13609:
http://bugs.python.org/issue13609
-- 
https://mail.python.org/mailman/listinfo/python-list

Rename file without overwriting existing files

[Steve D'Aprano]

This code contains a Time Of Check to Time Of Use bug:

if os.path.exists(destination)
raise ValueError('destination already exists')
os.rename(oldname, destination)


In the microsecond between checking for the existence of the destination and
actually doing the rename, it is possible that another process may create
the destination, resulting in data loss.

Apart from keeping my fingers crossed, how should I fix this TOCTOU bug?



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue29388] regex mismatch in the simple cases

[Steven D'Aprano]

Steven D'Aprano added the comment:

re.match only matches at the start of the string. If you use re.search instead, 
you will get the results you are expecting.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29248] os.readlink fails on Windows

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the patch. I think it would be better to use the existing framework 
in Win32SymlinkTests to create a test file instead of using a hardcoded path 
like 'C:\Users\All Users' (e.g. use Win32SymlinkTests.filelink and 
Win32SymlinkTests.filelink_target to create a link)

--
nosy: +berker.peksag
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Is shutil.get_terminal_size useless?

[Steve D'Aprano]

On Mon, 30 Jan 2017 08:12 am, Serhiy Storchaka wrote:

> On 28.01.17 10:03, Steve D'Aprano wrote:
>> Is shutil.get_terminal_size useless? When, if ever, should I use it in
>> preference to the os version? If the shutil version is broken, can it be
>> fixed?
> 
> Read the history of shutil.get_terminal_size(). All this was discussed.

Where?



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: How coding in Python is bad for you

[Steve D'Aprano]

On Mon, 30 Jan 2017 10:52 am, Erik wrote:

> On 29/01/17 14:42, Steve D'Aprano wrote:
>> 1. for...else is misspelled, and should be for...then;
>>
>> 2. Same for while...else;
> 
> I don't think I'll ever agree with you on this one.
> 
> "then", to me, implies the code following it is always executed.
> "else" implies it's conditional.
> 
> In those constructs it's conditional and therefore, to me, "else" is a
> better reminder of that.

But it isn't conditional. When the code reaches the end of the for/while
block, the else block is ALWAYS executed. Unconditionally.

The only way to skip the else block is to avoid reaching the end of the
for/while block: raise, break or return out of the body of the block.


> It would be even better if it was "else if not break:" to make the
> meaning clearer.

break is not the only way to exit the for loop.


> I would agree that it would be even better than that if 
> it was "then if not break:" (apart from needing the new keyword ;)), as
> then the conditional aspect is explicit.

But it isn't conditional. Your syntax implies that the interpreter keeps
some sort of flag did_we_reach_the_end_of_the_loop_without_break or
something, and then it checks the state of that flag. There is no such
flag. If I remember correctly, that last time this came up here was because
somebody asked how they could read the value of that flag, instead of
setting their own:

for x in seq:
...
if not did_we_reach_the_end_of_the_loop_without_break:
print("break")


They hoped to use the same flag the for-loop used.

But if you use the dis module to decompile the CPython byte-code you will
see that there is no such flag. Code like this:

for i in seq:
break
else:
foo
bar

compiles to something like this (results may vary according to the version
of Python):


py> import dis
py> code = compile("""
... for i in seq:
... break
... else:
... foo
... bar
... """, "", "exec")
py> dis.dis(code)
  2   0 SETUP_LOOP  19 (to 22)
  3 LOAD_NAME0 (seq)
  6 GET_ITER
>>7 FOR_ITER 7 (to 17)
 10 STORE_NAME   1 (i)

  3  13 BREAK_LOOP
 14 JUMP_ABSOLUTE7
>>   17 POP_BLOCK

  5  18 LOAD_NAME2 (foo)
 21 POP_TOP

  6 >>   22 LOAD_NAME3 (bar)
 25 POP_TOP
 26 LOAD_CONST   0 (None)
 29 RETURN_VALUE


Not a single condition to be seen, anywhere. Its all unconditional jumps.

To anticipate a possible objection: it is possible that the FOR_ITER
bytecode is implemented with a conditional test, but even so, all that
tests for is whether to enter the main body of the for-loop (10
STORE_NAME ...) or jump to (18 LOAD_NAME ...).

If you remove the break completely, or replace it with raise or (in a
function) return, and you'll see the same structure to the code: for loops
run the main body of the loop, then unconditionally run the else block,
then unconditionally exit the loop and continue on with the rest of the
program. To avoid the else block, you have to jump out of the entire
for-loop.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue29381] Tutorial documentation contains undefined reference to #!

[Mariatta Wijaya]

Mariatta Wijaya added the comment:

There are certain rules about the encoding declaration line.
It has to be the first line of the source code, or in the case that the file 
starts with a unix "shebang" line, then the encoding declaration has to be on 
the second line. In fact, the first or the second lines of the source code has 
to follow a certain regular expression. This is all described in PEP 263, but 
we don't have to repeat all of those here. IMO we can just refer the reader to 
the PEP.

I've prepared a patch that addresses this. Please review, and let me know if 
you have additional feedback.

Thanks :)

--
Added file: http://bugs.python.org/file46452/issue29381.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29388] regex mismatch in the simple cases

[MaxR]

New submission from MaxR:

When I compile and match, for example:
pattern = re.compile(r"""([a-z]|\d)+$ # ends with letter or number 
only""", re.VERBOSE | re.IGNORECASE)
print(re.match(pattern, 'abc'))

result is correct:
<_sre.SRE_Match object; span=(0, 3), match='abc'>

but then I use the same pattern with another string:
print(re.match(pattern, 'abc.fds'))

result is: 
None

I tried to reformulate the pattern to the same, for example:
pattern = re.compile(r"""
(a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z|\d)+$ # ends with 
letter or number only""", re.VERBOSE | re.IGNORECASE)

or to:
pattern = re.compile(r"""[a-z\d]+$ # ends with letter or number 
only""", re.VERBOSE | re.IGNORECASE)

or to:

pattern = = re.compile(r"""([a-z]|\d)+$ # ends with letter or 
number only""", re.VERBOSE | re.IGNORECASE)

but the result is all the time the same - None
And еhat is the double strange for the last three pattern - None is result also 
for 
print(re.match(pattern, 'abc'))

I checked this patterns on the site regex101.com
and all of them should work good and right
It's achtung!

--
components: Regular Expressions
messages: 286464
nosy: MaxR, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: regex mismatch in the simple cases
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: count points where is within the polygons using shapely and fiona

[Peter Pearson]

On Sun, 29 Jan 2017 11:42:47 -0800 (PST), Xristos Xristoou wrote:
> i tried to count points from the point shapefile where is within in
> the polygon shapefile but i fail.Maybe my code is complete wrong but i
> tried.
> any idea how to fix my code ?
> i want fast method because i have big data features
> from shapely.geometry import shape
> import fiona
>
> filepath1 = "point.shp"
> file1features = []
> intersectfeatures_file1 = []
> intersectfeatures_file2 = []
> count =0
> count=count+1

This is an illogical place to increment count.

> outschema = None
> with fiona.collection(filepath1, "r") as input1:
> outschema = input1.schema.copy()
> for p1 in input1:
> file1features.append(p1)

I believe you could also say file1features = list(input1).


> filepath2 = "polygon.shp"
> with fiona.collection(filepath2, "r") as input2:
> for p2 in input2:
> for p1 in file1features:
> [count for i in 
> [shape(p1['geometry']).within(shape(p2['geometry']))]]

The above line produces a list that is discarded because it is not
assigned any name.

> if p1 not in intersectfeatures_file1:
> intersectfeatures_file1.append(p1)
> if p2 not in intersectfeatures_file2:
> intersectfeatures_file2.append(p2)
>
> print count

> '''
> if intersectfeatures_file1:
> outfile = "outputfile1.shp"
> with fiona.collection(outfile, "w", "ESRI Shapefile", outschema) as 
> output:
> for outfeature in intersectfeatures:
> output.write(outfeature)
> if intersectfeatures_file2:
> outfile = "outputfile2.shp"
> with fiona.collection(outfile, "w", "ESRI Shapefile", outschema) as 
> output:
> for outfeature in intersectfeatures:
> output.write(outfeature)
> '''

The above lines between triple quotes should have been omitted
from this post.

> on the print count i take 20 times the number 1. after for this count i want 
> to export to new shapefile the polygons where have specific number of points. 
> thnx


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

[issue27200] make doctest in CPython has failures

[Brett Cannon]

Brett Cannon added the comment:

I'm -1 on building the docs from Sphinx master as I don't want to complicate 
our development process to deal with potential broken tooling. Basically if the 
doctests don't pass on a compiled checkout for the  version of Python the docs 
are being built for then the doctest is broken (i.e. no need to care about 
compatibility with older Python versions for docs meant for master).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods

[Martin Panter]

Martin Panter added the comment:

While I don’t have much opinion either way, here is a patch to remove the 
existing dead code should that be the eventual outcome.

If the default implementations in the base class deferred to math.isfinite() 
etc, that may help with compatibility.

--
versions: +Python 3.7 -Python 3.4
Added file: http://bugs.python.org/file46451/rm-finite.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[Martin Panter]

Martin Panter added the comment:

I pushed the simpler 2.6-compatible option. Keeping this open to check the 
buildbot is happy overnight.

--
stage: needs patch -> resolved

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How coding in Python is bad for you

[Erik]

On 29/01/17 14:42, Steve D'Aprano wrote:

1. for...else is misspelled, and should be for...then;

2. Same for while...else;


I don't think I'll ever agree with you on this one.

"then", to me, implies the code following it is always executed.
"else" implies it's conditional.

In those constructs it's conditional and therefore, to me, "else" is a 
better reminder of that.


It would be even better if it was "else if not break:" to make the 
meaning clearer. I would agree that it would be even better than that if 
it was "then if not break:" (apart from needing the new keyword ;)), as 
then the conditional aspect is explicit.


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

[issue29387] Tabs vs spaces FAQ out of date

[Martin Panter]

New submission from Martin Panter:

The Windows FAQ 

 mentions the “python -t” command-line option, but in Python 3 this option is 
undocumented (and I understand has no effect):

/media/disk/home/proj/python/cpython/Doc/faq/windows.rst:303: WARNING: unknown 
option: -t

Also, the reference to the tabnanny script is wrong. It exists as a module 
(Lib/tabnanny.py), not in Tools/scripts/. This aspect also applies to 2.7.

--
assignee: docs@python
components: Documentation, Windows
files: tabnanny.patch
keywords: patch
messages: 286460
nosy: docs@python, martin.panter, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Tabs vs spaces FAQ out of date
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46450/tabnanny.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28822] Fix indices handling in PyUnicode_FindChar

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2b5e5a3a805e by Martin Panter in branch 'default':
Issue #28822: Add susp-ignored entry for NEWS; fix grammar
https://hg.python.org/cpython/rev/2b5e5a3a805e

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11670] configparser read_file now iterates over f, docs still say it calls readline

[Roundup Robot]

Roundup Robot added the comment:

New changeset e70882558a96 by Martin Panter in branch '3.5':
Issue #11670: readfp(fp) parameter name is different to read_file(f)
https://hg.python.org/cpython/rev/e70882558a96

New changeset e06de6f9cfe5 by Martin Panter in branch '3.6':
Issues #11670: Merge configparser doc from 3.5
https://hg.python.org/cpython/rev/e06de6f9cfe5

New changeset 6db0a62b6aa6 by Martin Panter in branch 'default':
Issues #11670: Merge configparser doc from 3.6
https://hg.python.org/cpython/rev/6db0a62b6aa6

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9880928ec962 by Martin Panter in branch '3.5':
Issue #29349: Use __future__ print_function; Sphinx may use Python 2.6+
https://hg.python.org/cpython/rev/9880928ec962

New changeset 1708afd284ff by Martin Panter in branch '3.6':
Issues #29349: Merge Py 2.6+ compatibility from 3.5
https://hg.python.org/cpython/rev/1708afd284ff

New changeset e50058ecd808 by Martin Panter in branch 'default':
Issues #29349: Merge Py 2.6+ compatibility from 3.6
https://hg.python.org/cpython/rev/e50058ecd808

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29283] duplicate README in site-packages

[Berker Peksag]

Berker Peksag added the comment:

Good catch and thanks for the report! Renaming was done in issue 24633. It 
looks like it was added back in a merge commit: 
https://github.com/python/cpython/commit/ebe304e919b56d889313a2d15fb5c52189a32ef7

I will delete Lib/site-packages/README shortly.

--
nosy: +berker.peksag
type: enhancement -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[David Bolen]

David Bolen added the comment:

Whoops, I just realized that the patch still needs adjusting to be 2.x 
compatible, so obviously the extra build still won't work.

But at this point it should be safe to assume 2.6+ such as for the rest of the 
sphinx processing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[David Bolen]

David Bolen added the comment:

2.7.12 (/usr/local/bin) is used for the build slave and main external commands 
(such as hg and sphinx) and is in the buildslave path, but 2.5.1 is still the 
default in /usr/bin so can get used for processes with a restricted 
environment.  Tiger's original 2.3 is present but unused.

The DMG build-installer script itself runs under 2.5.1, because it specifies 
"python2.5" in its command to the slave.  I believe that was originally added 
once the system 2.3 couldn't be used.

During the DMG construction process, a particular step might, I suppose use 
2.5.1 or 2.7.12 depending on whether it's internal to the build script, 
something using the same executable as the script, a subprocess with limited 
path, or an independent utility (like sphinx) referencing 2.7.

I believe Ned's comment in issue 17861 about 2.6+ is a reference to the sphinx 
step, which is covered by the fact that sphinx is using the newer 2.7.12.

What appears to break in this specific case is some of the preparation - 
specifically the Makefile referencing patchlevel is running "python".  That 
should work (2.7.12) if it inherits the overall build slave environment (which 
has /usr/local/bin first) but I think the install script filters that, so it's 
probably getting the /usr/bin/python 2.5.1 version.

I've just changed the default /usr/bin/python to be 2.7 so external processes 
run by build-installer should get 2.7.  I don't think that will break anything 
else currently done on the machine, but I'll deal with any fallout if needed.  
I'm rerunning build 59 now.

As in issue 28039 there's no immediate need to change the installer script 
itself, but since it's clearly the last hold out, I'll find some time to test 
that I've got any pre-requisites for it set up at which point the build master 
could be changed to remove the python2.5 reference.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16899] Add support for C99 complex type (_Complex) as ctypes.c_complex

[Armin Rigo]

Armin Rigo added the comment:

* Tom: the issue is unrelated to cffi, but both ctypes and cffi could proceed 
to support C complexes, now that libffi support has been added.

* Mark: the problem is that the text you quote from the C standard fixes the 
representation of a complex in memory, but doesn't say anything about directly 
passing a complex as argument or return value to a function call.  Platforms 
use custom ways to do that.  The text you quote says a complex is an array of 
two real numbers; but passing an array as argument to a function works by 
passing a pointer to the first element.  Typically, this is not how complexes 
are passed: instead, some pointerless form of "passing two real numbers" is 
used.

--
nosy: +arigo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

RE: What are your opinions on .NET Core vs Python?

[Deborah Swanson]

Joseph L. Casale wrote, on January 29, 2017 1:14 PM
> 
> > .NET is a library that can be used from many languages, including 
> > Python.
> 
> No.
> 
> .NET Core (what the OP asked about which is not .NET) is a 
> cross-platform framework. Obviously Python and .NET differ in 
> runtime semantics with respect to the original source code, 
> however they are now roughly equivalent in that both 
> specifications are cross platform.
> 
> I personally like .NET Core a great deal and as the framework 
> matures and it starts to present all of the .NET APIs, it 
> will become a viable choice on non Windows platforms.
> 
> jlc

What .NET APIs are anticipated to be released that aren't on the
official CLI list now:
https://en.wikipedia.org/wiki/List_of_CLI_languages#Current_Languages,
and/or, are .NET supported languages expected to expand beyond the CLI
list?



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

Re: What are your opinions on .NET Core vs Python?

[Gregory Ewing]

Joseph L. Casale wrote:
.NET is a library that can be used from many languages, including Python. 


No.


Yes:

http://pythonnet.sourceforge.net/

"Python for .NET is a package that gives Python programmers nearly seamless 
integration with the .NET Common Language Runtime (CLR) and provides a powerful 
application scripting tool for .NET developers. Using this package you can 
script .NET applications or build entire applications in Python, using .NET 
services and components written in any language that targets the CLR (Managed 
C++, C#, VB, JScript)."


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

Re: How coding in Python is bad for you

[Chris Angelico]

On Mon, Jan 30, 2017 at 8:54 AM, Gregory Ewing
 wrote:
> Steve D'Aprano wrote:
>
>> 5. The statistics module is too slow (and if I ever meet the author, I'll
>> give him a kick in the head);
>
>
> Wow... ad-hominem take to a physical level!

If Steve ever comes face to face with the author of the statistics
module, he should avoid excessive violence, lest he get seven years of
bad luck... for breaking a mirror. :)

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

Re: How coding in Python is bad for you

[Gregory Ewing]

Steve D'Aprano wrote:


5. The statistics module is too slow (and if I ever meet the author, I'll
give him a kick in the head);


Wow... ad-hominem take to a physical level!

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

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[Martin Panter]

Martin Panter added the comment:

According to , Ned says 2.6+ is 
already needed to build the Python 3.5 documentation, so maybe Sphinx uses that.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[Ned Deily]

Ned Deily added the comment:

Dunno for sure, perhaps David can answer that.  But the Sphinx docs imply that 
Sphinx 1.4.6 requires at least 2.6 and I don't test the installer build with 
anything less than 2.7.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[Martin Panter]

Martin Panter added the comment:

Thanks Ned. Do you know what version of Python Sphinx uses (which runs 
patchlevel.py)?

According to Issue 28039, David set up Python 2.7 so that “make touch” would 
work. But the log also uses a python2.5 command, and apparently Python 2.3 also 
installed on that buildbot.

If we can rely on 2.6+, we just need to add “from __future__ import 
print_function”. Otherwise, we may need something like

if sys.stderr is not None:
sys.stderr.write(...)

and also do something about that “with” statement.

--
nosy: +db3l

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

RE: What are your opinions on .NET Core vs Python?

[Joseph L. Casale]

> .NET is a library that can be used from many languages, including Python. 

No.

.NET Core (what the OP asked about which is not .NET) is a cross-platform
framework. Obviously Python and .NET differ in runtime semantics with
respect to the original source code, however they are now roughly equivalent
in that both specifications are cross platform.

I personally like .NET Core a great deal and as the framework matures and
it starts to present all of the .NET APIs, it will become a viable choice on non
Windows platforms.

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

Re: Is shutil.get_terminal_size useless?

[Serhiy Storchaka]

On 28.01.17 10:03, Steve D'Aprano wrote:

Is shutil.get_terminal_size useless? When, if ever, should I use it in
preference to the os version? If the shutil version is broken, can it be
fixed?


Read the history of shutil.get_terminal_size(). All this was discussed.

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

[issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I concur with Raymond. This expands the API too much. Not just the float API, 
but the API of all numeric classes, including third-party classes. And since 
the existence of additional method in third-party classes (e.g. NumPy classes) 
can't be guarantied, this couldn't help in the case of msg286441.

The less harmful way is making math.isfinite() and like supporting non-float 
numeric types. Always return False for integer types and fall back to the 
is_finite() method. But even this can be too expensive.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

count points where is within the polygons using shapely and fiona

[Xristos Xristoou]

i tried to count points from the point shapefile where is within in the polygon 
shapefile but i fail.Maybe my code is complete wrong but i tried.
any idea how to fix my code ?
i want fast method because i have big data features
from shapely.geometry import shape
import fiona

filepath1 = "point.shp"
file1features = []
intersectfeatures_file1 = []
intersectfeatures_file2 = []
count =0
count=count+1
outschema = None
with fiona.collection(filepath1, "r") as input1:
outschema = input1.schema.copy()
for p1 in input1:
file1features.append(p1)

filepath2 = "polygon.shp"
with fiona.collection(filepath2, "r") as input2:
for p2 in input2:
for p1 in file1features:
[count for i in 
[shape(p1['geometry']).within(shape(p2['geometry']))]]
if p1 not in intersectfeatures_file1:
intersectfeatures_file1.append(p1)
if p2 not in intersectfeatures_file2:
intersectfeatures_file2.append(p2)

print count
'''
if intersectfeatures_file1:
outfile = "outputfile1.shp"
with fiona.collection(outfile, "w", "ESRI Shapefile", outschema) as output:
for outfeature in intersectfeatures:
output.write(outfeature)
if intersectfeatures_file2:
outfile = "outputfile2.shp"
with fiona.collection(outfile, "w", "ESRI Shapefile", outschema) as output:
for outfeature in intersectfeatures:
output.write(outfeature)
'''
on the print count i take 20 times the number 1. after for this count i want to 
export to new shapefile the polygons where have specific number of points. thnx
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29301] decimal: Use FASTCALL and/or Argument Clinic

[Raymond Hettinger]

Raymond Hettinger added the comment:

>> Ah you dislike the additional [clinic input] sections?
>
> Yes, they tear apart the code.  I stopped reading many C files because
> of this.

I concur with Stefan.  AC is very impactful on modules, greatly affecting their 
readability and maintainability.  The existing PyArg_ParseXXX() calls and their 
"kwlist" static variable are very easy to work with, easy to modify, and easy 
to teach (I cover them effortlessly in the Python classes I teach).  In 
contrast, AC is much harder to learn, harder to get right, doesn't fit some 
existing APIs, harder to change, and it greatly expands the number of lines of 
code.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods

[Raymond Hettinger]

Raymond Hettinger added the comment:

I would like to caution against expansion of core APIs in cases where we 
already have a way to do it.  In almost every corner, Python's APIs are 
growing, resulting in the language becoming massive, where very few people on 
the planet can claim to know what is in it and it is becoming much harder to 
teach as it gets bigger.

Also, we should place very little value on anecdotal evidence from one core 
developer who says he once wrote a single line of code that would have 
benefitted from a single part of the proposed changes.  In general, core devs 
tend to write much more generic code than end users, so our needs are often 
atypical and do not reflect user needs (in this case, no non-core-dev numeric 
user has ever requested this behavior or had a real use case that couldn't be 
met by the existing APIs).  The bar for new APIs is much higher than "I wrote a 
line of code once".  

We should be looking for APIs additions that significantly reduce complexity or 
solve problems that can't easily be met with existing APIs.  Minor expansions 
create long term maintenance burdens, increase the size of docs making them 
less usable, cause other implementations to have to follow suit, cause 
subclassers and users of the numeric module to have to implement additional 
methods, and make Python more difficult to learn.  There is a reason that the 
zen expresses a preference for only one way to do it.

Replicating parts the decimal API should always be suspect as well.  In 
general, that module is much more difficult to use and learn than regular 
floats.  Many parts of the API are simply worthless and are there only because 
they were part of the spec.  We have no evidence that any of these proposed 
methods are actually being used and are of real benefit to real users.

Also, remember that Decimal is not registered as a Real for a reason.  Guido 
does not consider them to be interoperable with binary floats.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

ANN: A new version (0.4.0) of python-gnupg has been released.

[Vinay Sajip via Python-list]

A new version of the Python module which wraps GnuPG has been released.

What Changed?
=
This is an enhancement and bug-fix release, and all users are encouraged to 
upgrade.
See the project website [1] for more information.

Brief summary:


* Added support for ``KEY_CONSIDERED`` in more places - encryption /
  decryption, signing, key generation and key import.

* Partial fix for #32 (GPG 2.1 compatibility). Unfortunately, better
  support cannot be provided at this point, unless there are certain
  changes (relating to pinentry popups) in how GPG 2.1 works.

* Fixed #60: An IndexError was being thrown by ``scan_keys()``.

* Ensured that utf-8 encoding is used when the ``--with-column`` mode is
  used. Thanks to Yann Leboulanger for the patch.

* ``list_keys()`` now uses ``--fixed-list-mode``. Thanks to Werner Koch
  for the pointer.

This release [2] has been signed with my code signing key:

Vinay Sajip (CODE SIGNING KEY) 
Fingerprint: CA74 9061 914E AC13 8E66 EADB 9147 B477 339A 9B86

What Does It Do?

The gnupg module allows Python programs to make use of the
functionality provided by the Gnu Privacy Guard (abbreviated GPG or
GnuPG). Using this module, Python programs can encrypt and decrypt
data, digitally sign documents and verify digital signatures, manage
(generate, list and delete) encryption keys, using proven Public Key
Infrastructure (PKI) encryption technology based on OpenPGP.

This module is expected to be used with Python versions >= 2.4, as it
makes use of the subprocess module which appeared in that version of
Python. This module is a newer version derived from earlier work by
Andrew Kuchling, Richard Jones and Steve Traugott.

A test suite using unittest is included with the source distribution.

Simple usage:

>>> import gnupg
>>> gpg = gnupg.GPG(gnupghome='/path/to/keyring/directory')
>>> gpg.list_keys()

[{
...
'fingerprint': 'F819EE7705497D73E3CCEE65197D5DAC68F1AAB2',
'keyid': '197D5DAC68F1AAB2',
'length': '1024',
'type': 'pub',
'uids': ['', 'Gary Gross (A test user) ']},
{
...
'fingerprint': '37F24DD4B918CC264D4F31D60C5FEFA7A921FC4A',
'keyid': '0C5FEFA7A921FC4A',
'length': '1024',
...
'uids': ['', 'Danny Davis (A test user) ']}]
>>> encrypted = gpg.encrypt("Hello, world!", ['0C5FEFA7A921FC4A'])
>>> str(encrypted)

'-BEGIN PGP MESSAGE-\nVersion: GnuPG v1.4.9 (GNU/Linux)\n
\nhQIOA/6NHMDTXUwcEAf
.
-END PGP MESSAGE-\n'
>>> decrypted = gpg.decrypt(str(encrypted), passphrase='secret')
>>> str(decrypted)

'Hello, world!'
>>> signed = gpg.sign("Goodbye, world!", passphrase='secret')
>>> verified = gpg.verify(str(signed))
>>> print "Verified" if verified else "Not verified"

'Verified'

As always, your feedback is most welcome (especially bug reports [3],
patches and suggestions for improvement, or any other points via the
mailing list/discussion group [4]).

Enjoy!

Cheers

Vinay Sajip
Red Dove Consultants Ltd.

[1] https://bitbucket.org/vinay.sajip/python-gnupg
[2] https://pypi.python.org/pypi/python-gnupg/0.4.0
[3] https://bitbucket.org/vinay.sajip/python-gnupg/issues
[4] https://groups.google.com/forum/#!forum/python-gnupg
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods

[Mark Dickinson]

Mark Dickinson added the comment:

@Martin: the dead code should definitely be removed from floatobject.c and 
longobject.c. (Though that's kinda independent of this issue.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Looking for a basic address book/contacts program

[Chris Green]

I'm looking for a simple Address Book program written in Python, I've
looked at addressbook 1.0.1 from PyPi but it doesn't quite do what I
want.  I may have to start with this and modify it but maybe there's
something better out there.

In particular I want some sort of import/export ability and I'd really
like some more configurability.

Any ideas anyone?

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Is shutil.get_terminal_size useless?

[Grant Edwards]

On 2017-01-29, Grant Edwards  wrote:
> On 2017-01-29, Marko Rauhamaa  wrote:
>
>> Mount? As a regular user?
>
> Yes, using a "fuse" use-space filesystem, you can mount things as a
> normal user. There are a couple ISO9660 fuse implemenations.  But, you
> can't modify a mounted ISO9660 filesystem.  I have read about how to
> use a union mount to simulate a writable ISO9660 filesystem, but
> that's going to require root (I've never tried it).
>
> As long as you've got the disk space available, the simplest option is
> to unpack the .iso into a directory, modify the files, and then use
> mkisofs to create the new .iso image.

OK, just one more level of pointless digression...

_If_ your ISO image is using syslinux as the bootloader (it probably
isn't, it's almost certainly using isolinux -- usually in hybrid
mode), then the bootloader stuff is actually an image of a bootable
floppy disk. It is sort of "outside" the normal ISO9660 filesystem
with a fixed size in a "well known" location.  I'm pretty sure you
could extract that chunk from the ISO using dd, tweak it, and then put
it back into the ISO image without having to mount/extract everything
and then recreate a new ISO9660 image.

But, it's very probably using isolinux, so the bootloader
configuration stuff is actually inside the ISO9660 filesystem tree,
and you'll have to extract the whole tree, modify the files, and
create a new ISO9660 image.

-- 
Grant

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

Re: Is shutil.get_terminal_size useless?

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Jan 30, 2017 at 3:44 AM, Marko Rauhamaa  wrote:
>> Mount? As a regular user?
>
> Let me see, how much effort are you prepared to go to in order to do
> this as a "regular user"... because at some point, "sudo" becomes only
> one of many options, including "install another Unix system somewhere
> that you are root of". But if you genuinely have to mount as a
> non-root user, there's fusermount, which is often capable of loading
> up an ISO.
>
> But honestly, "ssh you@somebox" can be run by anyone, so there's
> always a way around the whole not-having-root thing.

At the moment, we have found it easiest to create our base OS snapshots
with some manual steps. Ideally, we could get rid of the manual steps
and just have a python script take the place of the human user. That
would be trivial if the distros continued the grand tradition of
offering serial consoles out of the box.

As it stands, all methods of working serial-interface support in the ISO
image would still be more trouble than the manual steps.

We also use "Packer" to build virtual machines automatically. That works
albeit in a somewhat kludgy manner. As far as I understand, Packer
delivers keystrokes to the boot command over VNC but can't interpret the
graphical responses but simply trusts that the commands do the right
thing with a proper timing.


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

Re: Is shutil.get_terminal_size useless?

[Chris Angelico]

On Mon, Jan 30, 2017 at 4:08 AM, Grant Edwards
 wrote:
> As long as you've got the disk space available, the simplest option is
> to unpack the .iso into a directory, modify the files, and then use
> mkisofs to create the new .iso image.
>
> I've written scripts like that to build cusotmized bootable ISO images
> (usually using systemrescuecd as the starting point).  It's not
> particulary difficult, but it does burn up a lot of disk space.  It's
> also rather slow, so when you get into the tweak-build-burn-test cycle
> you don't get in a lot of guesses-per-hour.

These days, CD images are a tiny proportion of typical hard disk
capacities. Every terabyte of disk can hold over a thousand ISOs, and
that's assuming they're using the whole disc (~760MB). Several
thousand, if they're only part-full images.

But the time factor is considerable. Especially if you then have to
boot up a VM or something to test it.

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

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[Ned Deily]

Ned Deily added the comment:

These changes have broken some buildbots, for example, the OS X dmg buildbots 
which are still using Python 2 for sphinx builds of the docs.  They should be 
version agnostic as much as possible.

http://buildbot.python.org/all/builders/bolen-dmg-3.x/builds/59

--
nosy: +ned.deily
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Is shutil.get_terminal_size useless?

[Grant Edwards]

On 2017-01-29, Marko Rauhamaa  wrote:

> Mount? As a regular user?

Yes, using a "fuse" use-space filesystem, you can mount things as a
normal user. There are a couple ISO9660 fuse implemenations.  But, you
can't modify a mounted ISO9660 filesystem.  I have read about how to
use a union mount to simulate a writable ISO9660 filesystem, but
that's going to require root (I've never tried it).

As long as you've got the disk space available, the simplest option is
to unpack the .iso into a directory, modify the files, and then use
mkisofs to create the new .iso image.

I've written scripts like that to build cusotmized bootable ISO images
(usually using systemrescuecd as the starting point).  It's not
particulary difficult, but it does burn up a lot of disk space.  It's
also rather slow, so when you get into the tweak-build-burn-test cycle
you don't get in a lot of guesses-per-hour.

-- 
Grant


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

Re: Is shutil.get_terminal_size useless?

[Grant Edwards]

On 2017-01-29, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Mon, Jan 30, 2017 at 3:28 AM, Marko Rauhamaa  wrote:
>>> Grant Edwards :
>>>
 On 2017-01-29, Marko Rauhamaa  wrote:
> I *have* been longing for a serial console in linux distros.

 Well, all it takes is a tweak to the bootloader to add a kernel
 "command-line" parameter...
>>>
>>> Can you give me a short Python script that effects the tweak to an ISO
>>> image? I need to run the script as a regular user.
>>
>> It'd start by mounting it somewhere, and finish by building a new ISO
>> with mkisofs, so a shell script would be more appropriate :)
>
> Mount? As a regular user?

https://linux.die.net/man/8/isoinfo

-- 
Grant



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

Re: Is shutil.get_terminal_size useless?

[Chris Angelico]

On Mon, Jan 30, 2017 at 3:44 AM, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Mon, Jan 30, 2017 at 3:28 AM, Marko Rauhamaa  wrote:
>>> Grant Edwards :
>>>
 On 2017-01-29, Marko Rauhamaa  wrote:
> I *have* been longing for a serial console in linux distros.

 Well, all it takes is a tweak to the bootloader to add a kernel
 "command-line" parameter...
>>>
>>> Can you give me a short Python script that effects the tweak to an ISO
>>> image? I need to run the script as a regular user.
>>
>> It'd start by mounting it somewhere, and finish by building a new ISO
>> with mkisofs, so a shell script would be more appropriate :)
>
> Mount? As a regular user?

Let me see, how much effort are you prepared to go to in order to do
this as a "regular user"... because at some point, "sudo" becomes only
one of many options, including "install another Unix system somewhere
that you are root of". But if you genuinely have to mount as a
non-root user, there's fusermount, which is often capable of loading
up an ISO.

But honestly, "ssh you@somebox" can be run by anyone, so there's
always a way around the whole not-having-root thing.

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

Re: Is shutil.get_terminal_size useless?

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Jan 30, 2017 at 3:28 AM, Marko Rauhamaa  wrote:
>> Grant Edwards :
>>
>>> On 2017-01-29, Marko Rauhamaa  wrote:
 I *have* been longing for a serial console in linux distros.
>>>
>>> Well, all it takes is a tweak to the bootloader to add a kernel
>>> "command-line" parameter...
>>
>> Can you give me a short Python script that effects the tweak to an ISO
>> image? I need to run the script as a regular user.
>
> It'd start by mounting it somewhere, and finish by building a new ISO
> with mkisofs, so a shell script would be more appropriate :)

Mount? As a regular user?


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

Re: Is shutil.get_terminal_size useless?

[Chris Angelico]

On Mon, Jan 30, 2017 at 3:28 AM, Marko Rauhamaa  wrote:
> Grant Edwards :
>
>> On 2017-01-29, Marko Rauhamaa  wrote:
>>> I *have* been longing for a serial console in linux distros.
>>
>> Well, all it takes is a tweak to the bootloader to add a kernel
>> "command-line" parameter...
>
> Can you give me a short Python script that effects the tweak to an ISO
> image? I need to run the script as a regular user.

It'd start by mounting it somewhere, and finish by building a new ISO
with mkisofs, so a shell script would be more appropriate :)

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

Re: Is shutil.get_terminal_size useless?

[Marko Rauhamaa]

Grant Edwards :

> On 2017-01-29, Marko Rauhamaa  wrote:
>> I *have* been longing for a serial console in linux distros.
>
> Well, all it takes is a tweak to the bootloader to add a kernel
> "command-line" parameter...

Can you give me a short Python script that effects the tweak to an ISO
image? I need to run the script as a regular user.


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

Re: Is shutil.get_terminal_size useless?

[Grant Edwards]

On 2017-01-29, Marko Rauhamaa  wrote:
> Grant Edwards :
>
>> On 2017-01-28, Marko Rauhamaa  wrote:
>>
>>> (Although if I were to design an operating system, I don't know if I
>>> would bother with controlling terminals, job control or chirping
>>> modems.)
>>
>> I've been using serial ports on Unix for 35 years, and maintaining
>> serial drivers for Linux for almost 20. Many days, it seems like the
>> tty/serial API in Unix is the rug under which all the ugly dirt got
>> swept...
>>
>> [...]
>>
>> It's really pretty impressive how orthogonal they did manage to make
>> things.
>
> I *have* been longing for a serial console in linux distros.

Well, all it takes is a tweak to the bootloader to add a kernel
"command-line" parameter...

> That would make it possible to set up virtual machines from ISO
> images automatically as virtualization environments can emulate a
> serial interface with an SSH connection. As it stands, such
> automation requires ugly, brittle VNC tricks.

-- 
Grant


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

Re: How coding in Python is bad for you

[Steve D'Aprano]

On Mon, 30 Jan 2017 12:05 am, BartC wrote:

> What might be unreasonable is to criticise it in a Python group full
> of language aficionados who are going to view every feature and quirk of
> the language in a good light; 

It's all about the trade-offs we choose to make. Its not that we don't
understand that feature X has a downside; its that we value that feature
enough to make up for it.


> nothing is ever a problem! 

1. for...else is misspelled, and should be for...then;

2. Same for while...else;

3. shutil.get_terminal_size() is broken by design;

4. Decimal is not integrated with the numeric tower;

5. The statistics module is too slow (and if I ever meet the author, I'll
give him a kick in the head);

6. duck-typing with numbers often fails, requiring you to resort to
polymorphic code with type checking;

7. which is too slow;

8. fractions could easily support infinities (±1/0) and NAN (0/0) but don't;

9. the state of GUI toolkits in 2017 is nowhere near as easy to use as
Hypercard in 1986 (although that doesn't apply just to Python);

10. packaging is still too complex and hard to get right;

11. the last couple of years has seen an emphasis on asynchronous
programming that I don't understand and scares me;

12. there's no try...except expression;

13. or constants;

14. writing bullet-proof file handling code (e.g. atomic file save that
either is guaranteed to write to the disk or guaranteed to leave the
previous file contents in place) is too hard;

15. str.centre() is misspelled;

16. despite what the Zen says, there aren't enough namespaces;

17. unicodedata is missing a lot of functionality;

18. CPython makes object IDs look like memory addresses;

19. there's no way to tell the compiler to do certain calculations at
compile-time, instead of run-time;

20. the utf-8 encoder is strict, but the utf-16 and utf-32 encoders are not,
which makes them technically non-compliant;

21. the CPython compiler isn't smart enough, and so has to forgo the
opportunity for optimizations which apply 99.9% of the time, because of the
0.1% of the time that they don't apply (e.g. in-lining functions);

22. there's no syntax for Design By Contract;

23. no support for Snobol/Icon like string patterns (BNF context-free
grammars, more powerful than regular expressions);

24. lack of support for Prolog-like logic programming paradigm;

25. no way to bail out of generator expressions early, e.g. (expr for x in
seq while condition);

26. the glob module doesn't support escaping, or {a,b,c} alternatives;

27. in hindsight, all() and any() shouldn't coerce their result to True or
False, but return a truthy or falsey value from their inputs.


That's just off the top of my head. Is that enough for you?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue10399] AST Optimization: inlining of function calls

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3991] urllib.request.urlopen does not handle non-ASCII characters

[R. David Murray]

R. David Murray added the comment:

I believe the last time this subject was discussed the conclusion was that we 
really needed a full IRI module that conformed to the relevant RFCs, and that 
putting something on pypi would be one way to get there.  

Someone should research the existing packages.  It might be that we need 
something simpler than what exists, but whatever we do should be informed by 
what exists, I think.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: How coding in Python is bad for you

[Chris Angelico]

On Mon, Jan 30, 2017 at 12:05 AM, BartC  wrote:
> On 29/01/2017 01:35, pavlovevide...@gmail.com wrote:
>>
>> On Monday, January 23, 2017 at 9:24:56 AM UTC-8, bream...@gmail.com wrote:
>>>
>>> The article is here http://lenkaspace.net/index.php/blog/show/111
>>>
>>> Kindest regards.
>>>
>>> Mark Lawrence.
>>
>>
>> I remember the old days of Python when it was just Perl's little brother.
>> Sometimes I feel moments of amazement whenever someone makes this much of an
>> effort to badmouth it (and this blog is definitely badmouthing it, very
>> little of criticism is reasonable).
>
>
> I think it's completely reasonable for anyone to criticise Python if they
> want (or any other computer language for that matter).
>
> (And it didn't cover that much; I could do a far more in-depth critique if I
> wanted.)
>
> What might be unreasonable is to criticise it in a /Python/ group full of
> language aficionados who are going to view every feature and quirk of the
> language in a good light; nothing is ever a problem!
>
> But the author of piece didn't post it here.

It's completely reasonable for someone to critique Python. It's not
reasonable to post a bunch of baseless FUD, regardless of your forum.

There's plenty in Python that you can legitimately criticise.
Sometimes you'll get a response of "actually this is good, because X,
Y, Z"; sometimes you get "well, what you suggest is marginally better,
but not enough to justify breaking backward compatibility"; and
sometimes you get "good point, maybe we can change that in the next
version - want to write a patch?". But when all your criticisms are
either (a) true of virtually every programming language, yet you claim
they're Python's faults; or (b) actually false, you just make yourself
look like a troll.

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

Re: How coding in Python is bad for you

[BartC]

On 29/01/2017 01:35, pavlovevide...@gmail.com wrote:

On Monday, January 23, 2017 at 9:24:56 AM UTC-8, bream...@gmail.com wrote:

The article is here http://lenkaspace.net/index.php/blog/show/111

Kindest regards.

Mark Lawrence.


I remember the old days of Python when it was just Perl's little brother.  
Sometimes I feel moments of amazement whenever someone makes this much of an 
effort to badmouth it (and this blog is definitely badmouthing it, very little 
of criticism is reasonable).


I think it's completely reasonable for anyone to criticise Python if 
they want (or any other computer language for that matter).


(And it didn't cover that much; I could do a far more in-depth critique 
if I wanted.)


What might be unreasonable is to criticise it in a /Python/ group full 
of language aficionados who are going to view every feature and quirk of 
the language in a good light; nothing is ever a problem!


But the author of piece didn't post it here.

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

Fwd: What are your opinions on .NET Core vs Python?

[Gerald Britton]

>
> As you guys might know, .NET Core is up and running, promising a
> "cross-platform, unified, fast, lightweight, modern and open source
> experience" (source: .NET Core official site). What do you guys think about
> it? Do you think it will be able to compete with and overcome Python in the
> opensource medium?


It's an apples/oranges comparison.

.NET is a library that can be used from many languages, including Python.
 (Not just IronPython, but also Python for .NET (pythonnet.sourceforge*.*net
*))*

Python is a language that can use many libraries, including .NET

The set of libraries that can be used from all the languages that can also
use .NET (out of the box, that is) is smaller.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29384] Unused beos build scripts

[Martin Panter]

Martin Panter added the comment:

Thanks Senthil

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue10399] AST Optimization: inlining of function calls

[irdb]

Changes by irdb :


--
nosy: +irdb

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods

[Martin Panter]

Martin Panter added the comment:

Of course, somehow I missed that

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods

[Steven D'Aprano]

Steven D'Aprano added the comment:

On Sun, Jan 29, 2017 at 08:23:05AM +, Martin Panter wrote:
> Why do you name the methods is_finite() etc with underscores, when the 
> existing methods math.isfinite() etc do not have underscores? Seems it 
> would add unnecessary confusion.

The idea is to enable duck-typing between float and Decimal. Instead of:

if isinstance(x, float):
math.isfinite(x)
else:
x.is_finite()

we can just say

x.is_finite() 

on both floats and decimals.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[Martin Panter]

Martin Panter added the comment:

I think the general rule is to clean up code if you are doing something else in 
nearby code, but don’t go out of your way with unnecessary cleanups to 
arbitrary code. Otherwise it adds too much noise to the repository history, 
review process, risks adding bugs, etc, for little gain.

Anyway, thanks for the patch!

--
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions:  -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12067] Doc: remove errors about mixed-type comparisons.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8c9a86aa222e by Martin Panter in branch '3.5':
Issue #12067: Recommend that hash and equality be consistent
https://hg.python.org/cpython/rev/8c9a86aa222e

New changeset 9702c5f08df1 by Martin Panter in branch '3.6':
Issues #12067: Merge hash recommendation from 3.5
https://hg.python.org/cpython/rev/9702c5f08df1

New changeset 9dbb7bbc1449 by Martin Panter in branch 'default':
Issues #12067: Merge hash recommendation from 3.6
https://hg.python.org/cpython/rev/9dbb7bbc1449

New changeset 8a9904c5cb1d by Martin Panter in branch '2.7':
Issue #12067: Rewrite Comparisons section in the language reference
https://hg.python.org/cpython/rev/8a9904c5cb1d

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29349] Update old Python 2 code in Docs/tools/extensions/patchlevel.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset ecdc864884a9 by Martin Panter in branch '3.5':
Issue #29349: Fix Python 2 syntax in documentation build code
https://hg.python.org/cpython/rev/ecdc864884a9

New changeset cdcb33f37bf3 by Martin Panter in branch '3.6':
Issues #29349: Merge Py 2 fix 3.5
https://hg.python.org/cpython/rev/cdcb33f37bf3

New changeset db8b917bbfdd by Martin Panter in branch 'default':
Issues #29349: Merge Py 2 fix 3.6
https://hg.python.org/cpython/rev/db8b917bbfdd

New changeset ca7d2af9920e by Martin Panter in branch 'default':
Issues #29349: Add NEWS for 3.7; use “with” statement
https://hg.python.org/cpython/rev/ca7d2af9920e

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29384] Unused beos build scripts

[Roundup Robot]

Roundup Robot added the comment:

New changeset aa9aef656fe0 by Martin Panter in branch 'default':
Issue #29384: Remove Be OS scripts from Modules/, unused in 3.0+
https://hg.python.org/cpython/rev/aa9aef656fe0

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files

[Martin Panter]

Martin Panter added the comment:

longobject_v5 looks good to me

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20180] Derby #11: Convert 50 sites to Argument Clinic across 9 files

[Martin Panter]

Martin Panter added the comment:

For str.format_map(mapping), yes the parsing happens in 
Objects/stringlib/unicode_format.h, but I don’t see that as a big problem. 
Moving this back to “needs patch”, assuming it is okay to convert format_map().

Other than from that, there are just tricky things left like the str() 
constructor, str.format(*args, **kwargs) (see Issue 20291), and the shared code 
in Objects/stringlib/find.h and Objects/stringlib/transmogrify.h. I don’t know 
what to do about those.

--
nosy: +martin.panter
stage: commit review -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13 files

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file46449/clinic_longobject_v5.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Is shutil.get_terminal_size useless?

[Marko Rauhamaa]

Grant Edwards :

> On 2017-01-28, Marko Rauhamaa  wrote:
>
>> (Although if I were to design an operating system, I don't know if I
>> would bother with controlling terminals, job control or chirping
>> modems.)
>
> I've been using serial ports on Unix for 35 years, and maintaining
> serial drivers for Linux for almost 20. Many days, it seems like the
> tty/serial API in Unix is the rug under which all the ugly dirt got
> swept...
>
> [...]
>
> It's really pretty impressive how orthogonal they did manage to make
> things.

I *have* been longing for a serial console in linux distros. That would
make it possible to set up virtual machines from ISO images
automatically as virtualization environments can emulate a serial
interface with an SSH connection. As it stands, such automation requires
ugly, brittle VNC tricks.


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

RE: What are your opinions on .NET Core vs Python?

[Deborah Swanson]

Juan C. wrote, on Saturday, January 28, 2017 7:07 PM
> 
> As you guys might know, .NET Core is up and running, 
> promising a "cross-platform, unified, fast, lightweight, 
> modern and open source experience" (source: .NET Core 
> official site). What do you guys think about it? Do you think 
> it will be able to compete with and overcome Python in the 
> opensource medium?

I don't really know what .NET does these days, but looking at the list
of languages it supports:
https://en.wikipedia.org/wiki/List_of_CLI_languages#Current_Languages
I don't see any I'd likely want to use instead of Python, with the
possible exception of IronPython. A few people on this list have
mentioned it, but I don't really see any good reason to paste any
version of Python onto some other kind of system. Unless maybe you're
required to use that system for some other reason.

Most of the languages on this "List_of_CLI_languages" supported by .NET
have already been shown to my satisfaction to have been overtaken and
subsumed by Python. It's a good thing that .NET's framework has shed
some baggage, which was sorely needed, but what really matters is what
you can do with it. And given the choices of languages available in
.NET, in most cases I think you'd be better off working in straight
Python. You can't put lipstick on a pig. It will still be a pig, even if
you give it flashy sunglasses and put it on jetskis.

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

[issue18842] Add float.is_finite is_nan is_infinite to match Decimal methods

[Martin Panter]

Martin Panter added the comment:

FWIW, here is an attempt to add Argument Clinic to the Objects/floatobject.c 
and Objects/longobject.c implementations:

https://bugs.python.org/file33943/issue20185_conglomerate_v4.diff
https://bugs.python.org/file33989/clinic_longobject_v3.patch

If the methods are rejected, the dead code should be removed to avoid wasting 
people’s time.

Why do you name the methods is_finite() etc with underscores, when the existing 
methods math.isfinite() etc do not have underscores? Seems it would add 
unnecessary confusion.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com