Form and Database

[v]

Please help. I'm new with Python.
Using Boa (or Pythoncard) and pysqlite, how can I read/write from/to
database, thanks


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

Books for programmers

[V]

Hi,

I'm a C++, Java and C programmer, and I'm searching for a (preferably
printed) book that teaches me the "Python idioms", i.e. the "Python
way" of doing something.

Ideally, I'm searching for a book like "Effective C++" or "Effective
Java", that does not lose time teaching what is a class, or a
function, or a loop, but that enters into details and describes not
only the "how", but also the "why".

I read the book "Dive into Python", but I found too schematic and not
enough advanced for my interests.

I generally do not like books from O'Reilly, while I prefere those
from Addison Wesley.

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

Re: Books for programmers

[V]

Hi Matt,

and thank you very much for your answer.

> Hm, depends of course, how good your programming skills are in the
> languages you knwo already, but I rely on the book "Beginning Python -
> From Novice to Professional" by Magnus Lie Hetland, published by Apress.

I think that I'm interested in a more advance book, ideally one that
talk of the Python gotchas, traps, pitfall, idioms, performance,
stile, and so on. I really like the style used from Scott Meyers in
his Effective C++ series, or from Herb Sutter's Exceptional C++, but
after a quick look I did not find anything similar for Python...

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

python25.dll

[Scott V]

 I don't know if anyone has sent this in before.
> I loaded the current version of Python on my computer to learn the
> programming and, I believe, it helps my Blender to work. Anyway,
> occassionally, I get an error on the screen, before I have started running
> programs, that states "python25.dll" will not load or does not exist.
> I have removed Python from my system to stop this error.
> Anything else I can do? This is XP system.
> Scott
*I loaded version 3.2, so not sure why the python25 was in there.

___
Amazon:
Check out my over 800 items for sale on Amazon at:

http://www.amazon.com/shops/bookman236  

"I believe that everything happens for a reason.
 People change so that you can learn to let go,
 things go wrong so that you appreciate them
 when they're right, you believe lies so you 
eventually learn to trust no one but yourself, 
and sometimes good things fall apart so better
 things can fall together." -Marilyn Monroe-- 
http://mail.python.org/mailman/listinfo/python-list

compiling py 2.7.3 with openssl

[V N]

RHEL 5.3 x86_64 / Python 2.7.3

compiled as shown below ==>

PYTHON=Python-2.7.3
tar xjf bin/$PYTHON.tar.bz2
cd $PYTHON
PYHOME=/usr/local/$PYTHON; export PYHOME
LDFLAGS="-L/usr/local/lib64"; export LDFLAGS
CPPFLAGS="-I/usr/local/include/ncurses -I/usr/local/include/readline 
-I/usr/local/include"; export CPPFLAGS
./configure --prefix=$PYHOME 1>"$PYTHON"_cfg.log 2>&1
make 1>"$PYTHON"_mk.log 2>&1
sudo make install 1>"$PYTHON"_inst.log 2>&1

able to install setuptools-0.6c11 and libraries such as nose, cx_Oracle, 
pyODBC, etc.

suppose I compile and install openssl (same thing happens with openssl 1.0.0x 
as well)

OPNSSL=openssl-1.0.1c
tar xzf bin/$OPNSSL.tar.gz
cd $OPNSSL
./config --prefix=/usr/local zlib-dynamic 1>"$OPNSSL"_cfg.log 2>&1
make 1>"$OPNSSL"_mk.log 2>&1
sudo make install 1>"$OPNSSL"_inst.log 2>&1

and change CPPFLAGS as
CPPFLAGS="...  -I/usr/local/include/openssl -I/usr/local/include"; export 
CPPFLAGS

I can compile python but when I trying to install setuptools-0.6c11, I get

[... setuptools-0.6c11]$ sudo -E $PYHOME/bin/python setup.py build install
running build
running build_py
running install
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 139, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 91, in 
__get_builtin_constructor
raise ValueError('unsupported hash type %s' % name)
ValueError: unsupported hash type md5
ERROR:root:code for hash sha1 was not found.
Traceback (most recent call last):
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 139, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 91, in 
__get_builtin_constructor
raise ValueError('unsupported hash type %s' % name)
ValueError: unsupported hash type sha1
ERROR:root:code for hash sha224 was not found.
Traceback (most recent call last):
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 139, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 91, in 
__get_builtin_constructor
raise ValueError('unsupported hash type %s' % name)
ValueError: unsupported hash type sha224
ERROR:root:code for hash sha256 was not found.
Traceback (most recent call last):
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 139, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 91, in 
__get_builtin_constructor
raise ValueError('unsupported hash type %s' % name)
ValueError: unsupported hash type sha256
ERROR:root:code for hash sha384 was not found.
Traceback (most recent call last):
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 139, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 91, in 
__get_builtin_constructor
raise ValueError('unsupported hash type %s' % name)
ValueError: unsupported hash type sha384
ERROR:root:code for hash sha512 was not found.
Traceback (most recent call last):
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 139, in 
globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Python-2.7.3/lib/python2.7/hashlib.py", line 91, in 
__get_builtin_constructor
raise ValueError('unsupported hash type %s' % name)
ValueError: unsupported hash type sha512
Traceback (most recent call last):
  File "setup.py", line 94, in 
scripts = scripts,
  File "/usr/local/Python-2.7.3/lib/python2.7/distutils/core.py", line 152, in 
setup
dist.run_commands()
  File "/usr/local/Python-2.7.3/lib/python2.7/distutils/dist.py", line 953, in 
run_commands
self.run_command(cmd)
  File "/usr/local/Python-2.7.3/lib/python2.7/distutils/dist.py", line 972, in 
run_command
cmd_obj.run()
  File "/export/home/myacc/setuptools-0.6c11/setuptools/command/install.py", 
line 76, in run
self.do_egg_install()
  File "/export/home/myacc/setuptools-0.6c11/setuptools/command/install.py", 
line 85, in do_egg_install
easy_install = self.distribution.get_command_class('easy_install')
  File "/export/home/myacc/setuptools-0.6c11/setuptools/dist.py", line 395, in 
get_command_class
self.cmdclass[command] = cmdclass = ep.load()
  File "/export/home/myacc/setuptools-0.6c11/pkg_resources.py", line 1954, in 
load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
  File 
"/export/home/myacc/setuptools-0.6c11/setuptools/command/easy_install.py", line 
21, in 
from setuptools.package_index import PackageIndex, parse_bdist_wininst
  File "/export/home/myacc/setuptools-0.6c11/setuptools/package_index.py", line 
10, in 
from md5 import md5
  File "/usr/local/Python-2.7.3/lib/python2.7/md5.py", line 10, in 
from hashl

py 2.7.1 & openssl

[V N]

I installed openssl-1.0.0d.tar.gz on my RHEL 5 box using:
 ./config --prefix=/usr/local --openssldir=/usr/local/openssl
shared zlib
 make
 sudo make install

Then I installed python 2.7.1 using
 PYHOME=/usr/local/Python-2.7.1; export PYHOME
 LD_RUN_PATH=$PYHOME/lib; export LD_RUN_PATH
 LDFLAGS="-L /usr/local/lib64 -L /usr/local/lib"; export
LDFLAGS
 CPPFLAGS="-I /usr/local/include -I /usr/local/include/
openssl"; export CPPFLAGS
 ./configure --enable-shared --prefix=$PYHOME > log_cfg 2>&1
 make > log_mk 2>&1
 sudo make install > log_mk_i 2>&1

I am trying to install
sudo $PYHOME/bin/python bin/ez_setup.py

and I get the following error:

Traceback (most recent call last):
  File "bin/ez_setup.py", line 67, in 
except ImportError: from md5 import md5
  File "/usr/local/Python-2.7.1/lib/python2.7/md5.py", line 10, in

from hashlib import md5
  File "/usr/local/Python-2.7.1/lib/python2.7/hashlib.py", line 136,
in 
globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Python-2.7.1/lib/python2.7/hashlib.py", line 71, in
__get_builtin_constructor
import _md5
ImportError: No module named _md5

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

Re: py 2.7.1 & openssl

[V N]

Thank you for your response. Here's some more information:

RHEL 5.3 / x86_64,  using gcc

I am now compiling openssl-1.0.0d using:
./config --prefix=/usr/local --openssldir=/usr/local/openssl -fPIC
shared threads zlib
I do have the logs for config, make and make install. There are no
errors in any of them. When I run make test, there are no errors
reported. And, the following files are created in /usr/local/lib64:
libssl.a, libssl.so, libcrypto.a, libcrypto.so.  Also, the binary
openssl is created in the bin directory.

When I compile Python, I do not get any errors. In fact, I am able to
import hashlib, ssl, md5  and
>>> hashlib.md5


The issue is only with setup tools. I tried the following:

tar xzf bin/setuptools-0.6c11.tar.gz
cd setuptools-0.6c11
$PYHOME/bin/python setup.py build

I tried to see exactly what fails in the install:
sudo $PYHOME/bin/python setup.py install_lib  <== works fine
sudo $PYHOME/bin/python setup.py install_headers <== works fine
sudo $PYHOME/bin/python setup.py install_scripts <== get ERROR

  File "setup.py", line 94, in 
scripts = scripts,
  File "/usr/local/Python-2.7.1/lib/python2.7/distutils/core.py", line
138, in setup
ok = dist.parse_command_line()
  File "/export/home/vnori/setuptools-0.6c11/setuptools/dist.py", line
271, in parse_command_line
result = _Distribution.parse_command_line(self)
  File "/usr/local/Python-2.7.1/lib/python2.7/distutils/dist.py", line
467, in parse_command_line
args = self._parse_command_opts(parser, args)
  File "/export/home/vnori/setuptools-0.6c11/setuptools/dist.py", line
590, in _parse_command_opts
nargs = _Distribution._parse_command_opts(self, parser, args)
  File "/usr/local/Python-2.7.1/lib/python2.7/distutils/dist.py", line
523, in _parse_command_opts
cmd_class = self.get_command_class(command)
  File "/export/home/vnori/setuptools-0.6c11/setuptools/dist.py", line
395, in get_command_class
self.cmdclass[command] = cmdclass = ep.load()
  File "/export/home/vnori/setuptools-0.6c11/pkg_resources.py", line
1954, in load
entry = __import__(self.module_name, globals(),globals(),
['__name__'])
  File "/export/home/vnori/setuptools-0.6c11/setuptools/command/
install_scripts.py", line 3, in 
from easy_install import get_script_args, sys_executable, chmod
  File "/export/home/vnori/setuptools-0.6c11/setuptools/command/
easy_install.py", line 12, in 
import sys, os.path, zipimport, shutil, tempfile, zipfile, re,
stat, random
  File "/usr/local/Python-2.7.1/lib/python2.7/tempfile.py", line 34,
in 
from random import Random as _Random
  File "/usr/local/Python-2.7.1/lib/python2.7/random.py", line 49, in

import hashlib as _hashlib
  File "/usr/local/Python-2.7.1/lib/python2.7/hashlib.py", line 136,
in 
globals()[__func_name] = __get_hash(__func_name)
  File "/usr/local/Python-2.7.1/lib/python2.7/hashlib.py", line 71, in
__get_builtin_constructor
import _md5
ImportError: No module named _md5

Any idea(s)?

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

Re: py 2.7.1 & openssl

[V N]

Yes, _md5 is enabled but I get a very long list under

Failed to build these modules:
_bisect_codecs_cn _codecs_hk
_codecs_iso2022_codecs_jp _codecs_kr
_codecs_tw _collections   _csv
_ctypes_ctypes_test   _curses
_curses_panel  _elementtree   _functools
_hashlib   _heapq _hotshot
_io_json  _locale
_lsprof_multibytecodec_multiprocessing
_random_socket_sqlite3
_ssl   _struct_testcapi
array  audioopbinascii
bz2cmath  cPickle
crypt  cStringIO  datetime
fcntl  future_builtinsgrp
itertools  linuxaudiodev  math
mmap   nisoperator
ossaudiodevparser pyexpat
readline   resource   select
spwd   strop  syslog
termiostime   unicodedata
zlib

This list was empty earlier.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: py 2.7.1 & openssl

[V N]

I tried all your suggestions. No success.

On Apr 1, 8:35 am, nirinA  wrote:
> hi,
>
> > Yes, _md5 is enabled but I get a very long list under
> >  Failed to build these modules:
> > ... list of mostly all extension modules ...
> > This list was empty earlier.
>
> at some point, the compilation failed to detect
> needed headers or libraries files.
> i suggest you to try something simple in order to
> see  what is wrong in the compilation step.
-- 
http://mail.python.org/mailman/listinfo/python-list

Installation issue with Python 3.6.2.

[V Vishwanathan]

 For the past 8/10 hours I have been trying to install the above version 
without any success.

My O/S is windows 10 free upgrade from win 8.1

Every time I try to install, I simply get a message as per screen grab attached.

I did have a version of 3.61 installed prior to upgrade to win 10, but somehow

it got corrupted ,and I simply uninstalled, and just not able to install again.

When I try the "Modify" option in the screen grab it proceeds and simply hangs

at " pre version"??

I will appreciate any help.

Than you,

Venkat



Sent from Mail for Windows 10


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

Questions.

[V Vishwanathan]

Hi, From what I see in the recent 4/5 digests, this forum seems to be for 
advanced

and professional programmers.

So wondering if a newbie can post some questions to understand errors in his 
code

or will it look silly?

 Thanks,

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

Key Error: "city"

[V Vishwanathan]

(1) Trying to convert concatenated string to .format method
(2) concatenated string >>
[#todo rewrite this line to use the format method rather than string 
concatenation
alert = "Today's forecast for " + city + ": The temperature will range from " + 
str(low_temperature) + " to " + str(high_temperature) + " " + temperature_unit 
+ ". Conditions will be " + weather_conditions + "."]

(3) My code:
city = "Seoul"
high_temperature = 18
low_temperature = 9
temperature_unit = "degrees Celsius"
weather_conditions = "light rain"
alert = "Today's forecast for {city}: The temperature will range 
from{low_temperature} "" to ""{high_temperature}{temperature_unit}Conditions 
will be 
{weather_conditions}".format(city,low_temperature,high_temperature,temperature_unit,weather_conditions)
print(alert)

(4) output:

Traceback (most recent call last):
  File "D:\python exercises\uda format1.py", line 6, in 
alert = "Today's forecast for {city}: The temperature will range 
from{low_temperature} "" to ""{high_temperature}{temperature_unit}Conditions 
will be 
{weather_conditions}".format(city,low_temperature,high_temperature,temperature_unit,weather_conditions)
KeyError: 'city'

 (5) Tried Google but not much help.

So would appreciate any help.
Thanks,
Venkat
-- 
https://mail.python.org/mailman/listinfo/python-list

The "loop and a half"

[Mikhail V]

bartc wrote:
>> But as it happens, I could make computers talk to each when I was working
>> with microprocessors, using home-made interfaces, rs232 or rs423. I
wouldn't
>> know how to do it now because it depends on other people's over-complex
>> tech.

Chris Angelico wrote:
> I don't know if you're an idiot or a troll. Using TCP/IP networking is
> pretty simple (at least if you're using a real language - your own toy
> languages might have made it unnecessarily hard, for all I know),
> hardly "over-complex" by comparison to RS-232 programming.

I suppose he is a programmer who is just not much interested in
networking and what you can do in beloved console.
And if you have remote editing you still need
to work in a line by line input?

Just for people like me who know nothing about networking,
can you popularly explain the :

> Have you ever worked on a slow remote session where a GUI is
> completely impracticable (or maybe even unavailable), and redrawing
> the screen is too expensive to do all the time?

So where does the redrawing happen? The machine youre sitting on (let's
call it 'A') and send remote commands or retrieving text files? Or the
redrawing must be synced on both A and
the remote machine? If so, then why so?
How does the bandwidth implies that you must edit stuff in the console on
A?
And not in a nice editor with normal fonts?
Am i missing something or your 'A' machine cannot use graphics? Even on 386
computers
there was graphics and keybord&mouse input. That is definitely what I would
want
for editing files. Yes I've tried line by line eding back in DOS times and
that really sucks.


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

The "loop and a half"

[Mikhail V]

bartc wrote:
>> Your job is to port an editor that people have been using for 30 years to
>> Linux. The first thing you do is to change all the commands and
shortcuts to
>> match what is typical on Linux? So that no-one who was familiar with it
as
>> it was can actually use it?

Chris Angelico wrote:
> Is it graphical? Does it use any well-known toolkit? If so, then yeah,
> the first thing - and the automatic thing - is that it will respond to
> the host platform's keys and so on.

In case of a toolkit probably, but generally there is no such thing as
"host platform's keys" in context of a desktop application. There are keys
which the application defines.
OS is used only to run the application, (some system keys, e.g. Alt-Tab,
Ctrl-Alt-del, are of course better left alone).

The first thing a developer should provide - the keys and mouse input
should be
*customizable* by the user. It is so by most serious application I have
ever used.
(I don't know though if it is so in Bart's application)
Anything that can not - is for me 'below the bar' usability straightaway.
(With the exception when the defaults are so good that there is no much
need to redefine them, or it is a very simple app with only few input
commands)
Some frameworks do not provide such customization and that is simply bad
design.

The second thing - the default keys should be optimized for
the input efficiency and ergonomics.

Other issues, e.g. whether the keys are same as in some other app or not,
becomes irrelevant if the app fulfils the first two criteria (see above).
If not, I would consider looking for an alternative app with
customizable keys.

bartc wrote:
>> * Under Windows, if you press Shift while Caps Lock is on, you get lower
>> case letters. I've never, ever wanted to do this (probably no one else
has).
>> My own editor doesn't obey that convention: shift-A will always come out
as
>> 'A' whatever the caps lock setting.
>>
>> There are dozens more, yet you are surprised why sometimes I prefer doing
>> things my own way? There are good reasons!

Chris Angelico wrote:
>Yep. Good reasons like that you're a moron. You assume that
> since *you* have never needed to produce one lower-case letter
> in a block of upper-case, that "probably no one else has",
> and then you make it impossible to do that in your editor.
> I have wanted to produce a lower-case letter by holding Shift.

I think I've never advocated anybody on the list, but here
I really don't understand why you are attacking Bart.
In this particular Caps lock example - it's pretty clear for me that the
input of lowercase letters with Shift is historically there just for the
'symmetry'.
Obviously there is zero practical need for that in general case,
so "probably no one else need this" is quite appropriate statement.

> I have wanted to produce a lower-case letter by holding Shift.
Ok, once in my life I have wanted too, just to see what happens, which
does not mean that this feature has any value.


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

The "loop and a half"

[Mikhail V]

>>> Have you ever worked on a slow remote session where a GUI is
>>> completely impracticable (or maybe even unavailable), and redrawing
>>> the screen is too expensive to do all the time?
>>
>> So where does the redrawing happen? The machine youre sitting on (let's
>> call it 'A') and send remote commands or retrieving text files? Or the
>> redrawing must be synced on both A and
>> the remote machine? If so, then why so?

Peter J. Holzer wrote:

> Because you want to see what you are typing. Imagine you are logged into
> a server on the other side of the world. You want to edit a file on that
> machine (for example a configuration file for the web server). You
> invoke the editor on that server.

I've never done this, but if one told me to edit a file,
my first attempt would be like:
- get read/write access to the file system
- browse it (e.g. some file browser plugin?)
- get the file to the local machine
- edit locally
- write it back to the remote machine


>> And not in a nice editor with normal fonts?
>> Am i missing something or your 'A' machine cannot use graphics?

> ... The server may not be able to
> (it's a server, why would anyone install a GUI on it?)

If I ever work on it (locally) why would I want a GUI on it?
o_O   I'm not sure if I'm getting you.
You mean probably a server which is never worked on locally?
If it has a display and a keyb, and I must do something on it, even
seldom, then certainly I want a GUI on it (not just to see
a desktop wallpaper ;).

> streaming the screen contents of a rich GUI around the world may be not
> be possible for bandwidth or delay reasons.
Sure, streaming video consumes a lot, but that is what one tries to
avoid if under limitations so streaming messages only is faster.


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

Keyboard Input [was: The "loop and a half"]

[Mikhail V]

Chris Angelico wrote:

> On Mon, Oct 9, 2017 at 7:05 PM, Mikhail V  wrote:
> > The first thing a developer should provide - the keys and mouse input
> > should be
> > *customizable* by the user. It is so by most serious application I have
> > ever used.
>
> And they most certainly are. Often, in something in the host platform.
> For instance, Xfce allows me to change the keys used for various
> purposes, by going into the menu and choosing "Settings" and then
> "Keyboard". (Or, of course, by editing the config files.) The most
> obvious and dramatic change you can do is to choose a specific
> keyboard layout - Qwerty vs Dvorak, US vs German, etc, etc, etc. Do
> you think that sort of thing should be in the hands of the
> application, or the platform? (Note that I'm not saying "OS" here.
> Usually the platform is at a higher level than that; in my case, I
> would consider Xfce (my desktop manager) to be that.)


I am not sure I correctly understand your question.
Do you ask whether the application should bypass the OS
selected layout and use own character input tables?
It is of course possible, but since the OS provides
input events, why not use those?
We were speaking about a text editor, so yes this
will be useful if one wants multilingual text input.

Also I am almost sure I can programmatically switch
the layout pages from Python (some Winapi calls I suppose)
So theoretically, based only on keyb scancodes, one
can use own LUTS and flags to replicate the unicode
input. I personally never wrote apps with multilingual text input though.

Seems that for keyboard input everything is already invented and
well-established.
Below is a minimal app showing pressed keys.
Try switching layouts and see 'unicode'  field changing for
same key scancode.


import pygame
pygame.init()
window_w = 300# display width
window_h = 200# display height
pygame.display.set_mode((window_w, window_h))
clock = pygame.time.Clock( )
FPS = 15
MainLoop = True
while MainLoop :
clock.tick(FPS)
for E in pygame.event.get():
if E.type == pygame.QUIT:
MainLoop = False
if E.type == pygame.KEYDOWN:
print (E)
if E.key == pygame.K_ESCAPE:
MainLoop = False
pygame.quit( )




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

Lies in education [was Re: The "loop and a half"]

[Mikhail V]

> >> [...] I'm not here to "cast stones", I like Python. I just think
> >> that you shouldn't cast stones at C/C++.
> > Not while PHP exists.  There aren't enough stones in the world...
> >
>
> PHP seems (seemed?) popular for laying out web pages.  Are their vastly
> superior options?

Python? Superior syntax for sure
-- 
https://mail.python.org/mailman/listinfo/python-list

Lies in education [was Re: The "loop and a half"]

[Mikhail V]

Bill wrote:
> Mikhail V wrote:
> > Python? Superior syntax for sure
>
> I believe that.  What accounts for the popularity of PHP then?


I can't tell for PHP for sure... As in many cases in software world, there is
a principle of "who was the first there to solve some task".
Probably also it was bundled with many Web solutions at the time when
Web market started to grow, IDK.


PS Off-topic:
I have a related observation regarding popularity of software.
There is such a program "VLC", which is a video player. Some would
think it is sort of best free player, etc. I was also under impression,
but then I've found a video player called "MPC-HC".
I have started to use it and quickly understood that it is by far more
superior player than VLC, literally by all core parameters - performance,
codec support, customizable key bindings with a lot of internal commands.
(Remark for Linux users: there is no Linux version of that player, it
is Windows-only)

So, I think one key to popularity is mostly related to *marketing*, in
case of MPC, there is also a problem of a *good name* for the software.
Once I was trying to remember, what was that nice player and just couldnt
remember. MPC, MTC, HTC... So if it was from the beginning somthing
more catchy like "Vulcano" or "Tornado" then I bet it would had way
bigger user community now. And surprisingly, VLC seems to be
more popular (if we take Windows), despite
it can't even read some video formats, which MPC can.
So go figure. Most important, one should not rely on those
trashy "Top-10 ..." articles, and don't judge by the fancy GUI,
 but try the software yourself for some time.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: how to read in the newsreader

[Mikhail V]

Thomas wrote:
>
> On 16/10/17 20:02, Pete Forman wrote:
> > Thomas Jollans  writes:
> > ...
> >>> If you do stick with a digest then check your newsreader for a feature
> >>> to expand it. Then you can read and reply as if you were getting
> >>> individual posts.
> >>>
> >> That exists? How does it work?
> >
> > The Gnus newsreader in Emacs allows you to type C-d on a digest to run
> > gnus-summary-enter-digest-group. That then behaves the same as if you
> > opened any other summary such as a regular Usenet group.
> >
>
> Does it set the References header correctly when replying?

Hi Thomas, regarding the issue with my reply-to header you told me recently -
Does this message looks ok in your threaded view now?

Now I reply by the href of the message I looked up in pipermail archive,
just curious if it looks now correctly.


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

Re: Allow additional separator character in variables

[Mikhail V]

Chris A wrote:

On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V  wrote:
>
> > Well, then there is some bitter irony in this, so it allows pretty
> > much everything,
> > but does not allow me to beautify code with hyphens.
> > I can fully understand the wish to use non-latin scripts in strings or 
> > comments.
> > As for identifiers, IMO, apart from latin letters and underscore, the
> > first unicode candidate
> > I would add is U+2010. And probably the LAST one I would add.
> >
>
> Fortunately for the world, you're not the one who decided which
> characters were permitted in Python identifiers. The ability to use
> non-English words for function/variable names is of huge value; the
> ability to use a hyphen is of some value, but not nearly as much.
>


Fortunately for the world we have Chris A. Who knows what is
fortunate and of huge values.
So is there any real world projects example of usage of non-latin scripts
in identifiers? Or is it still only a plan for the new world?


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

Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

Chris A wrote:

>> On Fri, Nov 24, 2017 at 1:10 AM, Mikhail V wrote:
>>
>>> Chris A wrote:
>>>
>>> Fortunately for the world, you're not the one who decided which
>>> characters were permitted in Python identifiers. The ability to use
>>> non-English words for function/variable names is of huge value; the
>>> ability to use a hyphen is of some value, but not nearly as much.
>>
>> Fortunately for the world we have Chris A. Who knows what is
>> fortunate and of huge values.
>> So is there any real world projects example of usage of non-latin scripts
>> in identifiers? Or is it still only a plan for the new world?


> Yes, I've used them personally. And I know other people who have.


Oh, I though it would be more impressive showcase for 'huge value'.
If we drop the benefit of the bare fact that you can do it, or you just
don't know English, how would describe the practical benefit?
If you don't know english, then programming at all will be just too hard.
(or one must define a new whole language specially for some local script)

I mean for a real practical situation - for example for an average
Python programmer or someone who seeks a programmer job.
And who does not have a 500-key keyboard, and who has
a not enough high threshold of vision sensitivity to bear the look
of various scripts in one small text piece?

Ok, I personally could find some practical usage for that, but
merely for fun. I doubt though that someone with less
typographical experience and overall computer literacy could
really make benefits even for personal usage.

So - fun is one benefit. And fun is important. But is that the
idea behind it?


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 8:46 PM, Thomas Jollans  wrote:
> On 23/11/17 19:42, Mikhail V wrote:
>> I mean for a real practical situation - for example for an average
>> Python programmer or someone who seeks a programmer job.
>> And who does not have a 500-key keyboard,
>
> I don't think it's too much to ask for a programmer to have the
> technology and expertise necessary to type their own language in its
> proper alphabet.

And I don't think it is too much of benefit of using two scripts in one
source to compensate the need to constantly switching. Do you
have a method to input e.g. Cyrillic and Latin without switching the
layout? If I just use few extra chars, then I'll bind a keyboard shortcut.
but even a two-language input is annoyance.
And I need to use Cyrillic and Latin constantly, so I know how it feels.


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 8:15 PM, Chris Angelico  wrote:

>
> Let's start with a simpler question. Which of these is better code?
>
> # == Option 1
> class ZipExhausted(Exception):
> pass
>
> def zip_longest(*args, **kwds):
> # zip_longest('ABCD', 'xy', fillvalue='-') --> Ax By C- D-
> fillvalue = kwds.get('fillvalue')
> counter = len(args) - 1
> def sentinel():
> nonlocal counter
> if not counter:
> raise ZipExhausted
> counter -= 1
> yield fillvalue
> fillers = repeat(fillvalue)
> iterators = [chain(it, sentinel(), fillers) for it in args]
> try:
> while iterators:
> yield tuple(map(next, iterators))
> except ZipExhausted:
> pass
>
> # = Option 2
>
> class e(Exception):
> pass
>
> def zl(*a, **k):
> f = f.get('fillvalue')
> c = len(a) - 1
> def s():
> nonlocal c
> if not c:
> raise e
> c -= 1
> yield f
> ff = repeat(f)
> i = [chain(i, s(), ff) for i in args]
> try:
> while i:
> yield tuple(map(next, i))
> except e:
> pass
>
> # 
>
> One of them is cribbed straight from the itertools docs. The other is
> the same functionality with shorter variable names. What makes one of
> them better than the other? Answer me that, and I'll continue.


I see you manually 'optimise' the look?
I personally would end with something like this:

def zip_longest(*A, **K):
value = K.get ('fillvalue')
count = len(a) - 1
def sentinel():
nonlocal count
if not count:
raise ZipExhausted
count -= 1
yield  value
fillers = repeat (value)
iterators = [chain (it, sentinel(), fillers) for it in A]
try:
while iterators:
yield tuple (map (next, iterators))
except ZipExhausted:
pass


So I would say, my option would be something inbetween.
Note that I tweaked it for proportional font, namely Times New Roman.

Particularly I find too narrow lines/words a bit eye-straining at times.
Also self-explanation is important in many cases. But that depends of
what context you cut the example.

But if you only ask which code of two looks better for me,
then, probably Second, but it has some issues for me, e.g. "c" and "e"
almost homoglyhs, too loose 'sieve'-like, short lines.


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico  wrote:
> On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V  wrote:
>> I see you manually 'optimise' the look?
>> I personally would end with something like this:
>>
>> def zip_longest(*A, **K):
>> value = K.get ('fillvalue')
>> count = len(a) - 1
>> def sentinel():
>> nonlocal count
>> if not count:
>> raise ZipExhausted
>> count -= 1
>> yield  value
>> fillers = repeat (value)
>> iterators = [chain (it, sentinel(), fillers) for it in A]
>> try:
>> while iterators:
>> yield tuple (map (next, iterators))
>> except ZipExhausted:
>> pass
>>
>>
>> So I would say, my option would be something inbetween.
>> Note that I tweaked it for proportional font, namely Times New Roman.

> I don't see how the font applies here, but whatever.

For a different font, say CourierNew (monospaced) the tweaking strategy might
be different.

> Which is better? The one-letter names or the longer ones that tie in with 
> what they're
> doing?

I think I have answered more or less in previous post, that you cutted off.
So you were not satisfied?
But now I am probably not get your 'better' meaning.
Better for understanding, or purely visually, i.e. less eye-straining?

> Also, why do you have those loose spaces stuck in random places, eg
> before some of the open parentheses but not others?

Is it not allowed? I like how it looks with Times font.


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Thu, Nov 23, 2017 at 10:05 PM, Chris Angelico  wrote:
> On Fri, Nov 24, 2017 at 8:02 AM, Mikhail V  wrote:
>> On Thu, Nov 23, 2017 at 9:39 PM, Chris Angelico  wrote:
>>> On Fri, Nov 24, 2017 at 7:38 AM, Mikhail V  wrote:
>>>> I see you manually 'optimise' the look?
>>>> I personally would end with something like this:
>>>>
>>>> def zip_longest(*A, **K):
>>>> value = K.get ('fillvalue')
>>>> count = len(a) - 1
>>>> def sentinel():
>>>> nonlocal count
>>>> if not count:
>>>> raise ZipExhausted
>>>> count -= 1
>>>> yield  value
>>>> fillers = repeat (value)
>>>> iterators = [chain (it, sentinel(), fillers) for it in A]
>>>> try:
>>>> while iterators:
>>>> yield tuple (map (next, iterators))
>>>> except ZipExhausted:
>>>> pass
>>>>
>>>>
>>>> So I would say, my option would be something inbetween.
>>>> Note that I tweaked it for proportional font, namely Times New Roman.
>>
>>> I don't see how the font applies here, but whatever.
>>
>> For a different font, say CourierNew (monospaced) the tweaking strategy might
>> be different.
>
> If you have ANY font-specific "tweaking", you're doing it wrong.
> Thanks for making it look worse on everyone else's screen.

Trolling attempt counted :)
No I don't have any particular font-specific strategy,
it is just my wording reflecting the fact that things look different
in different fonts, even among proportional fonts.


>
>>> Which is better? The one-letter names or the longer ones that tie in with 
>>> what they're
>>> doing?
>>
>> I think I have answered more or less in previous post, that you cutted off.
>> So you were not satisfied?
>> But now I am probably not get your 'better' meaning.
>> Better for understanding, or purely visually, i.e. less eye-straining?
>
> Which one would you prefer to maintain? Which would you prefer in a code 
> review?
>
> Do you want to have one- and two-letter variable names, or longer and
> more descriptive ones?
>
> Seriously? Do I need to wrench this part out of you? This was supposed
> to be the EASY question that everyone can agree on, from which I can
> then draw my line of argument.


>From my above example, you could probably see that I prefer somewhat
middle-sized identifiers, one-two syllables. And naturally, they tend to
reflect some process/meaining, it is not always achievable,
but yes there is such a natural tendency, although by me personally
not so strong, and quite often I use totally meaningless names,
mainly to avoid visual similarity to already created names.
So for very expanded names, it ends up with a lot of underscores :(


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 4:13 AM, Chris Angelico  wrote:
> On Fri, Nov 24, 2017 at 1:44 PM, Mikhail V  wrote:
>> From my above example, you could probably see that I prefer somewhat
>> middle-sized identifiers, one-two syllables. And naturally, they tend to
>> reflect some process/meaining, it is not always achievable,
>> but yes there is such a natural tendency, although by me personally
>> not so strong, and quite often I use totally meaningless names,
>> mainly to avoid visual similarity to already created names.
>> So for very expanded names, it ends up with a lot of underscores :(
>
> Okay. So if it makes sense for you to use English words instead of
> individual letters, since you are fluent in English, does it stand to
> reason that it would make sense for other programmers to use Russian,
> Norwegian, Hebrew, Korean, or Japanese words the same way?

I don't know. Probably, especially if those *programmers* don't know latin
letters, then they would want to write code with their letters and their
language. This target group, as I said, will have really hard time
with programming,
and in Python in particular, because they will be not only forced to learn
some english, but also will have all 'pleasures' of  multi-script editing.
But wait, probably one can write python code in, say Arabic script *only*?
How about such feature proposal?

As for non-english speaker who know some English already,
could of course want to include identifiers in those scripts.
But how about libraries?
Ok, so we return back to my original question: apart from
ability to do so, how beneficial is it on a pragmatical basis?
I mean, e.g. Cyrillic will introduce homoglyph issues.
CJK and Arabic scripts are metrically and optically incompatible with
latin, so such mixing will end up with messy look. So just for
the experiment, yes, it's fun.


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico  wrote:

>> and in Python in particular, because they will be not only forced to learn
>> some english, but also will have all 'pleasures' of  multi-script editing.
>> But wait, probably one can write python code in, say Arabic script *only*?
>> How about such feature proposal?
>
> If Python supports ASCII identifiers only, people have no choice but
> to transliterate. As it is, people get to choose which is better for
> them - to transliterate or not to transliterate, that is the
> readability question.

Sure, let them choose.
Transliteration though is way more reasonable solution.

>
>> As for non-english speaker who know some English already,
>> could of course want to include identifiers in those scripts.
>> But how about libraries?
>
> If you want to use numpy, you have to understand the language of
> numpy. That's a lot of technical jargon, so even if you understand
> English, you have to learn that. So there's ultimately no difference.

That's what I'm saying. There will be anyway major parts of code in
English and pretty much every already existing modules that can
further  help the developer will be in English, like it or not.

>> Ok, so we return back to my original question: apart from
>> ability to do so, how beneficial is it on a pragmatical basis?
>> I mean, e.g. Cyrillic will introduce homoglyph issues.
>> CJK and Arabic scripts are metrically and optically incompatible with
>> latin, so such mixing will end up with messy look. So just for
>> the experiment, yes, it's fun.
>
> Does it really introduce homoglyph issues in real-world situations,
> though? Are there really cases where people can't figure out from
> context what's going on? I haven't seen that happening. Usually there
> are *entire words* (and more) in a single language, making it pretty
> easy to figure out.

The issues can be discussed long, but I have no doubt that even placing words
in two different scripts on one text line is a bad idea, not only for source
code. For mixing Cyrillic+Latin, yes, this also causes extra issues due to
homoglyphs in many cases, I know it practically from everyday work with
Cyrillic filenames, and from past experience with English-Russian textbooks.
In textbooks at least I can help it by proper layout - separating them
in tables,
or putting in quotes or bold for inline usage.


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 5:37 PM, Chris Angelico  wrote:
> On Sat, Nov 25, 2017 at 3:33 AM, Mikhail V  wrote:
>> On Fri, Nov 24, 2017 at 8:03 AM, Chris Angelico  wrote:
>>
>>>> and in Python in particular, because they will be not only forced to learn
>>>> some english, but also will have all 'pleasures' of  multi-script editing.
>>>> But wait, probably one can write python code in, say Arabic script *only*?
>>>> How about such feature proposal?
>>>
>>> If Python supports ASCII identifiers only, people have no choice but
>>> to transliterate. As it is, people get to choose which is better for
>>> them - to transliterate or not to transliterate, that is the
>>> readability question.
>>
>> Sure, let them choose.
>> Transliteration though is way more reasonable solution.
>
> That right there has settled it: you agree that identifiers have to
> use the broader Unicode set, not limited to ASCII. Otherwise they
> can't choose. Everything else is down to style guides; the language
> MUST support all alphabets so that people have this choice.

That's a valid and somewhat obvious point.
I agree that one should have more choices, but
people still can't really choose many things.
I can't choose hyphen, I can't choose minus sign,
and many tech people would probably want more operators.
It counts probably not so *big* amount of people, compared to *all*
people that potentially would say "oh how wonderful is it to be able
to write in various scripts", still it is just a "use it at your own risk"
thing at a minimum, and merely based on emotions rather than
common sense.

Regardless of what Unicode decides for classifications, there simply must
be careful analysis how the major *Python* code actually looks in the end
of all experiments. Especially true for characters in regard
identifiers versus operators.


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 9:08 PM, Chris Angelico  wrote:
> On Sat, Nov 25, 2017 at 7:00 AM, Mikhail V  wrote:
>> I agree that one should have more choices, but
>> people still can't really choose many things.
>> I can't choose hyphen, I can't choose minus sign,
>> and many tech people would probably want more operators.
>> It counts probably not so *big* amount of people, compared to *all*
>> people that potentially would say "oh how wonderful is it to be able
>> to write in various scripts", still it is just a "use it at your own risk"
>> thing at a minimum, and merely based on emotions rather than
>> common sense.
>>
>> Regardless of what Unicode decides for classifications, there simply must
>> be careful analysis how the major *Python* code actually looks in the end
>> of all experiments. Especially true for characters in regard
>> identifiers versus operators.
>
> And it's the "identifiers versus operators" question that is why you
> can't use hyphen in an identifier. Underscore is available as an ASCII
> joiner, and there are various non-ASCII joiners available too. Why is
> hyphen so important?

Yes I understand this, so it is how Unicode defines joiners.
Yeah, debates about the classifications can be
hold forever, but one should not forget about the hyphen during
these debates. Hyphen is used I think more then six hundreds
years as a joiner (or probably some other classification term one prefer).
And just comes so it works very well.
Among Unicode joiners, middledot reminds of hyphen,
but it is not used in typography for this task. So it is not good option
and has issues in most fonts (too small or not aligned with lowercase).
Often it is used to show up whitespace in editors,
so it is kind of 'reserved'.
Other joiners in unicode classification - well probably ok for a 1st April
proposal.

About importance, it was already covered in the proposal.
Why it is SO important? It is rhetorical question.
Important compared to what? Compared to the question, what
one will eat and where sleep tomorrow? Then it is not so important.


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

Re: Benefits of unicode identifiers (was: Allow additional separator in identifiers)

[Mikhail V]

On Fri, Nov 24, 2017 at 11:26 PM, Richard Damon
 wrote:
>
> Have you tried using U+2010 (HYPHEN) ‐. It is in the class XID_CONTINUE (in
> fact it is in XID_START) so should be available.
>

Hi Richard.

U+2010 is SyntaxError.
5 days ago I made a proposal on python-ideas, and we have already discussed
many aspects including straw-man arguments about fonts,etc


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

Re: Increasing the diversity of people who write Python

[Mikhail V]

On Mon, Nov 27, 2017 at 8:09 PM, Alexandre Brault  wrote:
> A quick Google search turned up WinCompose. It defaults to Right-Alt for
> its compose key, but that's configurable
>
> On 2017-11-27 02:05 PM, Paul Moore wrote:
>> On 27 November 2017 at 18:13, Skip Montanaro  
>> wrote:
 If you have a Windows key, you can assign it to be
 the Compose key.
>>> Would this be true on a machine running Windows? My work environment
>>> has me developing on Linux, with a Windows desktop. It's not clear to
>>> me that any sort of xmodmap shennanigans would work. Won't Windows
>>> itself always gobble up that key?
>> Programs can access the Windows key. IIRC, there is a utility that
>> provides compose-key functionality on Windows. I can't recall the name
>> right now and it's on my other PC, not this one, but I'll try to
>> remember to post the name tomorrow...
>>
>> Paul


On Windows people usually use AHK (Autohotkey).
It is a programming language, so you can do anything you
want. For example, here is a script that converts two
characters to the left of current cursor position:
if it is "e" followed by apostrophe then it replaces it with é,

;---
#NoEnv
SendMode Input
SetWorkingDir %A_ScriptDir%

parse_clip(str) {
firstchar := substr(str, 1,1)
lastchar := substr(str, 2,2)
if  (lastchar = "'") {
if (firstchar = "e") {
Send, {raw}é
}
if (firstchar = "a") {
Send, {raw}á
}
}
else {
Send, {right}
}
}


Esc:: ExitApp

!c::
clipboard := ""
Send, {Shift down}{left}{left}{Shift up}
Send, ^c
Clipwait, 1
gettext := clipboard
parse_clip(gettext)
return

;---

So here the command is bound to Alt-C,
it selects two previus chars (shift+arrow commands), copies to clipboard
and parses the contents. It works system-wide, but
can be programmed to specific app as well.
Best thing is, you can program it youself as you like.
However if you want to program with AHK,
be prepared to invest time, it is not the easiest
programming language out there, only built-ins
probably more than hundred, so better not try to code without
syntax highlighting :)
.
-- 
https://mail.python.org/mailman/listinfo/python-list

Goto

[Mikhail V]

MRAB wrote:


> It's OK for code that's close to the metal, but in high-level code? No.
> Python has managed for >25 years without it, and I've yet to see a
> convincing use-case.

"convincing" is a broad term I think, especially for syntax proposals ;)

I think often one wish to use it just to avoid "if" blocks in
obvious situations - no need to setup flags and  indent/unindent code blocks.

Apart from that, I personally would prefer it in such typical code:

if a :
a()
goto "end"
if b :
b()
goto "end"
if c :
c()
goto "end"
"end"

I know I can do it with "elif", but "elif" is just not my cup of tea.
For this case goto provides symmetrical and explicit look, which I value a lot.


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

Simple graphic library for beginners

[Mikhail V]

> > But the OP isn't looking for a full-blown GUI toolkit.  I went back and
> > re-read his post to be sure I wasn't misunderstanding.  Therefore I
> > don't think the suggestion to use wxPython or PyQt is that helpful.
> >
> > Do you have any other suggestions?
> >
> > Even Cairo is pretty complicated (requiring pens and contexts) for what
> > he's asking for.
> >
> > Personally I don't think it gets much easier or simpler than this sort
> > of thing:
> > https://github.com/Mekire/pygame-samples
>
> I couldn't see anything obviously simple there. A lot seems to do with
> interaction which is always much more complicated than just drawing stuff.
>
> 'Turtle' will do it (assuming there's a way of drawing things without
> having to watch an actual turtle symbol crawling around the screen).
>

That's right. Cairo, IIRC is mainly used as a rasterizer backend, so it
is not what OP wants.

Pygame is a SDL wrapper (a low-level lib), and NOT a wrapper for
GUI widgets. Almost everything must be made from ground up -
keyborad/mouse input, buttons (OP told about buttons).

So there not even such thing as "button" there - Pygame has nothing
of that high-level concept by default, so it will require an 3d party
module that implements those.

But, for *programming* classes, I personally would still recommend Pygame.

As for something quick and simple, Turtle seems to be good.

BTW - openCV is an excellent lib for drawing and image manipulation.
It has tons of ready-to-use functions and can show things up in a
window without additional coding.
But again: if you want *buttons*, then you are merely speaking about
a framework, not a lib. IOW if you drop the beloved by
people "buttons" idea, then you have much more good options.

PyQT is probably overkill, but it has a tool for GUI construction (qtdesigner)
and it makes it child-easy to draw a window with buttons, and some
canvas object, and then auto-creates pieces of code with objects and
interaction slots. So PyQT is imo better option for noobs than Pygame.
So here you have buttons and lots of OOP bloat as a consequence.



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

Re: Simple graphic library for beginners

[Mikhail V]

On Fri, Jan 12, 2018 at 10:38 AM, Paul Moore  wrote:
> On 12 January 2018 at 06:47, Steven D'Aprano
>  wrote:

>> If pip is joined at the hip to a specific version of Python, I think that
>> we ought to be able to specify the version number like we can with Python.
>>
>> Something like:
>>
>> pip ...  # use whichever version of pip comes first on the PATH
>> pip3.6 ...  # use the pip installed with Python 3.6
>> pip2.7 ...  # use the pip installed with Python 2.7
>
> Well, that's sort of how it's intended to work, but in practice it
> doesn't seem to be as straightforward as it ought to be. I can't
> really say why, as it's a Unix-only thing and I don't really
> understand the reasons, but it's why I'm a fan of the "python -m pip"
> approach. There's discussion on the pip tracker if you're interested
> enough to go searching - I know it's something that's been debated,
> but I don't recall the context.

In general I think more than one app and executable with same name
on a system already asks for problems.
On Windows I had issues with pip and pygame and I have two Pythons -
2.7.14 and 3.6.2.
The problem was that I could not make it install to 2.7, and tried many options,
looking in SO there were so many different solutions, but finally I found
something that reinstalled newer pip, but I don't remember frankly.

My opinion (from Windows user's POV) - I'd prefer if there should be
only one PIP in system,
so running pip will unambigiosly mean that I run (or upgrade) THE pip.
(and not something which I don't
even know where it is located). Ideally also it should be installed in
separate Directory.
So I'd have folders:

python 27
python 36
pip

And the target Python where the package will be installed should be defined by
a switch, e.g. 'pip -2', 'pip -3' (in analogy with 'py -2', 'py -3').
The question is though, how pip will know what version(s) of python I have, and
if I installed them later? Hmm, not an easy problem. So in this case pip shoud
track the multiple versions each time I install another version of python.


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

Spotify technology

[Gonzalo V]

Hi everyone!
i need a guide or advice or anything.
I few years ago, i was able to connect to my music receiver via spotify app
from my phone or laptop. You had to connect to receiver and your laptop to
the same wifi network and this is. Years later, that service was deprecated
by spotify conditions. Spotify would only work with some brands, i can
understand that.
Do you know guys, how that technology works?,
it could be replicated via python app?,
Is there some kind a documentation that could help me?.
i cant find anything because i cant find the keyword to start my research
thanks in advance.
Gonzalo form Chile.

Saludos,
Gonzalo
-- 
https://mail.python.org/mailman/listinfo/python-list

always return the same pdf

[Gonzalo V]

Hello everyone.
i had upload a Django app to an ubuntu 18.04 server and it gives me the
same pdf everytime the view is called. To generate the pdf it receipts
differents string buy it gives me the same pdf. Could you give some idea
what is happening?

thanks everyone
@never_cached
def generar_pdf(request):
prueba = request.session.get('contenedor')
cantidad_preguntas=prueba['cantidad_preguntas']
archivo_salida = open("prueba.tex","w")

archivo_salida.write("\\documentclass[10pt,oneside,letterpaper]{article}")
archivo_salida.write("\\usepackage[utf8x]{inputenc}")

  ##hace mas y mas cosas sin importancia con latex que funcionan bien

archivo_a_descargar = open("prueba.pdf","rb") #
respuesta =
HttpResponse(archivo_a_descargar,content_type='application/pdf')
respuesta['Content-Disposition'] = 'attachment; filename="{0}"'.format(
archivo_a_descargar.name)

return respuesta
Saludos,
Gonzalo
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Web Scraping

[Gonzalo V]

Explore url module and you need urlretrieve()

saludos,
desde un móvil.
El nov 12, 2016 12:23 p.m., "Veek M"  escribió:

> Steve D'Aprano wrote:
>
> > On Sat, 12 Nov 2016 11:07 pm, Veek M wrote:
> >
> >> 121sukha wrote:
> >>
> >>> I am new to python and I want to use web scraping to download songs
> >>> from website. how do I write code to check if the website has
> >>> uploaded a new song and have that song automatically be downloaded
> >>> onto my computer. I know how to use the requests.get() module but i
> >>> am more interested in knowing how to download and save every new
> >>> song that the website uploads on the site. I would extremely
> >>> appreciate the help from anyone. Thanks!
> >>
> >> What you're doing is illegal
> >
> > Really? Everywhere in the world? And you're sure of this because
> > you're a lawyer?
>
> 'probably illegal' (i did mentally assume he's from India - the nick is
> very indianish and since I am Indian and noticed many badly formatted
> posts I felt obliged to help out)
>
> > Even if the website uses public domain or freely licenced songs?
> >
> > Even if the downloads count as fair use, time-shifting or
> > format-shifting?
>
> ah true
>
> >> but Youtube/websites have a lot of stuff up
> >> that's easily accessible - the moral issue seems ambiguous especially
> >> if you use adblocker..
> >
> > Doesn't seem ambiguous to me.
>
> > Or are you one of those people who think that you are a thief for
> > leaving the room when ads are playing on TV?
> >
> > https://yro.slashdot.org/story/02/05/02/0550214/turner-
> ceo-pvr-users-are-thieves
>
> yep as in.. do the networks have a right to tempt me
>
> >
> > Downloading may, or may not, violate the terms of use of the website.
> > But you *literally* cannot watch the video without downloading it: in
> > order for the video to play in your browser, it must be downloaded.
> > That's the end of the story. "Streaming video" is just another way of
> > saying "downloading video, where the video is deleted afterwards".
> >
> > (Actually, streaming video is just another way of saying "lots of
> > pauses, stuttering, dropped frames and a really awful user
> > experience".)
>
> also true, but gramophone records were an inconvenience we put up with
> lacking a better solution.. so an inconvenience strictly speaking
> doesn't imply you can break the law.. however, is it fair to tempt us
> with these delights.. hence my moral confusion..
>
> Anyway.. yes I agree that I have no business telling people off (and
> that was not my intention) it was a succinct warning of the dangers..
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: UTF-8 Encoding Error

[Gonzalo V]

Try utf-8-sig
El 25 dic. 2016 2:57 AM, "Grady Martin"  escribió:

> On 2016年12月22日 22時38分, subhabangal...@gmail.com wrote:
>
>> I am getting the error:
>> UnicodeDecodeError: 'utf8' codec can't decode byte 0x96 in position 15:
>> invalid start byte
>>
>
> The following is a reflex of mine, whenever I encounter Python 2 Unicode
> errors:
>
> import sys
> reload(sys)
> sys.setdefaultencoding('utf8')
>
> A relevant Stack Exchange thread awaits you here:
>
> http://stackoverflow.com/a/21190382/2230956
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Beta release of pip version 10

[Mikhail V]

Paul Moore writes :

If you discover any bugs while testing the new release, please report
> them at https://github.com/pypa/pip/issues.


Link not working (on pipermail archive -- remove the period on the end)
https://github.com/pypa/pip/issues

PS: was looking forward to PIP improvements on Windows,
on 9.0.3 still some issues. E.g. trying to redirect output
from 'pip search ... > a.txt' gives a wall of errors.
it's on Windows 10.

(logging to file is needed because there is no advanced
search, so need some filtering to restrict the output to
packages only, since it searches in description too and
that may be a lng list of packages).



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

Beta release of pip version 10

[Mikhail V]

Steven D'Aprano writes:

>>
>> PS: was looking forward to PIP improvements on Windows, on 9.0.3 still
>> some issues. E.g. trying to redirect output from 'pip search ... >
>> a.txt' gives a wall of errors. it's on Windows 10.
>
>
>
> Don't be shy, tell us what those errors are.


You meant - don't be lazy to figure out how to reproduce it.

UnicodeEncodeError: 'charmap' codec can't encode character

when it meets a non-ascii char.

e.g. tried this:
pip search pygame > a.txt
-- 
https://mail.python.org/mailman/listinfo/python-list

Beta release of pip version 10

[Mikhail V]

MRAB writes:


> > UnicodeEncodeError: 'charmap' codec can't encode character
> >
> > when it meets a non-ascii char.
> >
> > e.g. tried this:
> > pip search pygame > a.txt
> >
> Well, _I_ didn't get an error!
>
> One of the lines is:
>
> kundalini (0.4)- LրVE-like PyGame API
>
> So it's down to what system encoding (active code page) is in use.

Dunno, it gives me error regardless of active codepage,
my default is 866, i've set to 1252 or 65001, same error.

The output itself is fine - I see correct glyphs, so the error
only appears when I redirect to file.
if I try some python script e.g. "a.py":
print ("абв")

and run:
py a.py > a.txt

I get some gibberish in the file.
So it is probably a global issue. Nothing works in this life :)
-- 
https://mail.python.org/mailman/listinfo/python-list

Suggestion for a "data" object syntax

[Mikhail V]

Here is an idea for 'data object' a syntax.
For me it is interesting, how would users find such syntax.
I personally find that this should be attractive from users
perspective.
Main aim is more readable presenting of typical data chunks
and some typical data types (tuples/lists) directly in code.
Further this should significantly simplify typing.

*Example 1. Multi-line strings*

Here is a 3 lines multi-line string, it will be automatically 'dedented'
by the parser by one level of indent:

data === S :
this is multi-line string
escape chars: same as in strings (\\, \\n, \\t ...) ,
but "no need to 'escape' quotes"

(Of course, assuming this feature will be added to the lexers
of your editor, otherwise it may mess up syntax highlighting)

So the proposed statement header is like:

variable === "type" :
...

The "===" token and type id's are of course subject to discussion.
"type" is type of data, which tells the parser to
convert data to specific type of Python object.
The above is type "S", a multi-line string.


*Example 2. Tuples*

Tuple is a data block with normal Python elements.

data === T :
123"hello"
abc + d

Here the separators of elements are : tab character,
new line (and maybe some white-space character like em-space?)
The above construct will be direct synonym for:

data = (1, 2, 3, "hello", a, b, c + d)

Benefits are easy to see: say I want a tuple of strings:

data === T :
"foo bar"
"hello world"
"to be continued..."

VS current:

data = (
"foo bar" ,
"hello world" ,
"to be continued..." ,
)

Main problem with the latter are commas, it is not easy
to type and, whats more important - hard to notice missing commas.
And brackets of course does not make it nicer either.

The above are typical cases where I see clear win, and
IMO they are quite common constructs.

More complicated examples :


*Example 3. Two-dimensional tuple.*

data === T/T :
123"hello"
ab c + de f

is a synonym for:

data = (
(1, 2, 3, "hello") ,
(a, b, c + d, e, f ) )

The rule here is: TAB character is inner elements' separator, and the
new line is outer elements' separator. Line continuation
character is  \  (to help with long lines).

*The benefits is just as in above examples :
readability and 'typeability' boost.*

To present nesting of elements of higher than 2 levels,
normal Python syntax can be used for deeper nesting:

data === T/T :
12(345)
ab c

Or maybe even allow commas:
data === T/T :
12(3, 4, 5)
ab c

VS normal:

data = (
(1, 2, (3, 4, 5) ) ,
(a, b, c ) )

So the idea is to cover only first two levels of
nesting of course.

Further, common types may be defined, like e.g. L/L (list of lists)
but I don't want to go far into details and want to stop
on common cases to help evaluate the idea in general.


*Main rules: *
- the definition is allowed  only as a statement (no passing as argument)
- (imo) data starts always as a new line after the header
- implicit string concatenation disallowed


So the question is, how do you like such syntax, and
if so, what common examples can be fit in here.
Any ideas, comments are of course welcome.
Suggest some data and I'll try to express it in this syntax.



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

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 10:15 AM, Steven D'Aprano
 wrote:
> On Tue, 08 May 2018 06:45:05 +0300, Mikhail V wrote:
>
>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>> 123"hello"
>> ab c + de f
>>
>> is a synonym for:
>>
>> data = (
>> (1, 2, 3, "hello") ,
>> (a, b, c + d, e, f ) )
>
> Last time you brought up this idea, you were told that it is ambiguous.
> Using whitespace alone, it is impossible to distinguish between
>
> a + b
>
> and
>
> a + b
>
>
> Can you see the difference? Of course not. That's the whole point. It is
> ambiguous. The first is a single item consisting of a plus b, and the
> second is two items consisting of a, following by unary plus b.

Can you be more precise what issue are you addressing?
Last time and this time I told it uses TAB character to
separate elements.


> There's also the problem that your syntax requires the *invisible*
> difference between tabs and spaces to be treated as syntactically
> meaningful.

What editor do you use? My editor can toggle tabs highlighting as arrows,
and I suppose almost any editor has good support for highlighting of
characters by search, etc. For NPP there are even plugins like Regex helper.

The only real issue I know that there may be no option to adjust the
minimal size for a tabulation, so it can become too small
in some rare cases, and there is the highlight function for that.

I never had problems with inputing tables - It seems you are having
an issue or may be it's even some personal pet-pieve.

>
> [...]
>> *The benefits is just as in above examples : readability and
>> 'typeability' boost.*
>
> But your syntax is not more readable, it is less readable and ambiguous.
> It requires us to care about the difference between two kinds of
> invisible whitespace.

Yes it requires you to care about tabulation - which many users already do
to improve readability in their code. As well as any software like
Matlab, Excel, etc presents matrices as tables.
So they are all making it "less readable", lol.
Ok Steven, you like the brackets and commas noise, that's
quite funny. Your opinion is heard, but I would be thankful if you'll
speak for yourself,
and not try to enforce your opinion with these "us", "for us".

Also you seem to start with cherry-picking straight away - trying
to find an issue and wind it up with the whole idea, totally ignoring
obvious benefits for most frequent use cases like multiline
strings,1d tuples/lists  and simple tables.
A very common table case is a 2-column table.

So you would prefer this:

L = (
(a, 1),
(b, 2),
(c, 3),
(foobar, 4))

over this:

L === T/T:
a1
b2
c3
foobar4

Right? Your issues with tabs aside, I think it is impossible to ignore the
the readability improvement. Not even speaking of how
many commas and bracket you need to type in the first case.


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

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 6:20 PM, Steven D'Aprano
 wrote:
> On Tue, 08 May 2018 15:52:12 +0300, Mikhail V wrote:
>
>>> Last time you brought up this idea, you were told that it is ambiguous.
>>> Using whitespace alone, it is impossible to distinguish between
>>>
>>> a + b
>>>
>>> and
>>>
>>> a + b
>>>
>>>
>>> Can you see the difference? Of course not. That's the whole point. It
>>> is ambiguous. The first is a single item consisting of a plus b, and
>>> the second is two items consisting of a, following by unary plus b.
>>
>> Can you be more precise what issue are you addressing?
>
> Was I not clear enough the first time?
>
> When you write "a + b" it is impossible for either the human reader or
> the interpreter to tell whether that is meant to be two items separated
> by white space ("a" and "+b") or a single item ("a+b").
>
> There is no acceptable work-around or fix for this.
>
> * It is not acceptable to prohibit whitespace between unary operators
>   and their operand;
>
> * or to require spaces rather than tabs between binary operators
>   and their operands;
>

Sorry this all does not seem to even refer to my proposal.

I don't propose to remove spaces, but I propose Tab-separated
elements. If I allow commas as well, this will become not so simple,
probably. Also I don't propose syntax for e-mail code exchange,
but rather syntax for *work* an this can potentially help a lot of people
in everyday work.

Also I don't know what kind of human thinks that this:
 a + b
 is two elements "a" and "+ b"
What is "+ b"? And who writes "- b" with a space in unary minus?
I don't. Nobody does. Is it allowed? yes. no problem.

(It would be great if you group the issues
related to usability separetely from technical problems
with parser. That will help to understand you comments.)


>> Last time and
>> this time I told it uses TAB character to separate elements.
>
> That's not my recollection. As I remember it, it was *your* idea to use
> tab characters, and everyone told you that was not an acceptable work-
> around.

Yes my idea, but not sure what is you concern right now.
IIRC back then, you were the *only one* who commented something about
Tab and parsing, and made some mysterious example with eval("\t") which
I still don't know what it should explain exactly.
You say "everyone?" ... Hmm, now I am starting to suspect - maybe
each your post really represents a result of a quick meeting
regarding each raised proposal?
That would explain the usage of plural "us".

>>> There's also the problem that your syntax requires the *invisible*
>>> difference between tabs and spaces to be treated as syntactically
>>> meaningful.

There is "invisible" difference in indentations tabs vs spaces - so what?
I don't want spaces or tabs visible - there is toggle "show tabs" and "toggle
show space" for that and many more usability features, as I already said.
Look, I work with layouts - there are: Indents, Tabs, spaces, En
space, Em space,
thin space, non-breaking space, "indent to here" control characters.
All those are useful parts of inner syntax - all are "invisible".
What point are you making after all?

Those are basically universal features. And thousands of Python people
already use tabs to align columns so you have to accept it - it is
part of many source code and tabulation formatting is a good and
useful feature, although not all editors cope good with that.


>>
>> What editor do you use? My editor can toggle tabs highlighting as
>> arrows, and I suppose almost any editor has good support for
>> highlighting of characters by search, etc. For NPP there are even
>> plugins like Regex helper.
>
> Using a particular editor is not and will not be a mandatory requirement
> for Python.

Using outdated tools or being PEBCAK are not and will not be justification for
language syntax improvements. Using an editor from 85 - everyone else
should bother?
As said there is already tons of code with which you may be unsatisfied
when you paste it into REPL, but nearly nobody uses REPL for work.

>
> [...]
>> So you would prefer this:
>>
>> L = (
>> (a, 1),
>> (b, 2),
>> (c, 3),
>> (foobar, 4))
>>
>> over this:
>>
>> L === T/T:
>> a1
>> b2
>> c3
>> foobar4
>>
>> Right?
>
> I am amused that you have obviously gone to a lot of trouble to carefully
> line up the columns, and yet they aren't even al

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:
> On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>> the readability improvement. Not even speaking of how
>> many commas and bracket you need to type in the first case.
>
> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.

Just admit it, you try to troll me (or just pretend, I don't know).

Have you ever seen tables with commas left in there?
I've never seen in my whole life. And you should understand why.

Have you ever seen a website with sparse menu items or 'cloud' tags
with commas attached?
Have you ever heard someone claim that writing a 2d matrix down in a
single line is better that present it as a table?

So what you find _incredibly_ subjective here?

I am not telling tabulations work as they should in many code editors, but
there is a lot of work people invest to make better support for them in editors.
Here is another indirect benefit of adding such syntax, as editor developers
will be more motivated to improve the tabulation features.


> Why should this be a language feature? Why not just create a data file
> and then load it, or use a triple quoted string and write your own
> parser? What's the advantage of making this language syntax?

I am not sure what happens if I make another argument -
if it feels so easy for you to deny the obvious improvements (which
also supported by whole worlds' typography experience) then you can
just as easy deny pretty everything. How would we build any conversation
then?




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

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 12:33 AM, Chris Angelico  wrote:
> On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
>> On Tue, May 8, 2018 at 5:25 PM, Chris Angelico  wrote:
>>> On Tue, May 8, 2018 at 10:52 PM, Mikhail V  wrote:
>>>> Right? Your issues with tabs aside, I think it is impossible to ignore the
>>>> the readability improvement. Not even speaking of how
>>>> many commas and bracket you need to type in the first case.
>>>
>>> That's incredibly subjective. Or else straight-up wrong, I'm not sure which.
>>
>> Just admit it, you try to troll me (or just pretend, I don't know).
>
> No, I am not trolling you.

I don't believe you.


> Neither of those examples is program code. You are asking for a
> syntactic change to a *programming language*. Everything you've said
> is fine for a non-code format. Nothing is applicable to a programming
> language.

Everything I said in previous mail was related to your claim that it's
Ok (or even better?) readable
with brackets and commas in a table than without them.
I was not even starting this terminology course.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 3:14 AM, Ben Finney  wrote:
> Mikhail V  writes:
>
>> On Wed, May 9, 2018 at 12:33 AM, Chris Angelico  wrote:
>> > On Wed, May 9, 2018 at 7:15 AM, Mikhail V  wrote:
>> >> Just admit it, you try to troll me (or just pretend, I don't know).
>> >
>> > No, I am not trolling you.
>>
>> I don't believe you.
>
> If that's true – if you believe Chris is trolling you – then please do
> not continue the conversation. Since you have already decided Chris is
> trolling you,

Well, the thing is I don't know how exactly the word "trolling" can
be understood by different persons. I use it here in sense of "nitpicking".
Or "fooling around" I don't know actually.
So may be "trolling" has too negative associations to your ears?

As for Chris' attitude in this thread, and my point on this -
well, honestly yes, I believe he uses an opportunity to push
his own game. It has happened before - and now I know already,
so I know that trying to explain and honestly answer his questions ends up
in the same game of Chris - so I suppose he amuses himself
in such a way.
Same scenario happens here - he just completely neglects the whole
proposal straight away with a bold provoking statement.
But then asks "why do you think this a good proposal?"
Which I actually tried to describe in the very proposal.

So honestly I can't understand what game this time he prepared,
and not very much into this kind of things.



>
> This forum has no need of another thread attempting to “win” an argument
> that one side believes is dishonest.
>
> --
>  \   “The best in us does not require the worst in us: Our love of |
>   `\ other human beings does not need to be nurtured by delusion.” |
> _o__) —Sam Harris, at _Beyond Belief 2006_ |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: seeking deeper (language theory) reason behind Python design choice

[Mikhail V]

On Wed, May 9, 2018 at 8:50 AM, Chris Angelico  wrote:
> On Wed, May 9, 2018 at 3:36 PM, Ian Kelly  wrote:
>>
>> while True:
>> if we_are_done():
>> break
>> # do some stuff
>> ...
>> if error_occurred():
>> break
>> notify_user()
>>
>>
>> Fixed, using idiomatic Python and without needing to use assignment in
>> an expression.
>
> Why is it that "while True" is idiomatic Python for a non-infinite
> loop? Is it merely because Python currently has no other way to spell
> certain loops? Surely it would be more idiomatic to encode the loop's
> termination condition in the header, if it were possible.

Don't know about 'idiomatic', but the above spelling is exactly what i
tend to use lately for almost all loops. It noticeably reduces cognitive load.
Though lately more often i prefer "while 1:" so it makes
the nodes more lightweight and distinct from the rest lines.
And not even official declaration of "idiomatic" as something else will
make me switch back.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
 wrote:
> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>

>> but I propose Tab-separated elements.
>
> We already have tab-separated elements in Python. It is allowed to use
> tabs between any whitespace separated tokens.

Yes, exactly. So in the proposed syntactic construct, it is *not*
allowed to insert tabs between _any_ tokens.
Namely if you will insert tabs _inside_ equations,
like:
a  + b

Then it will not work (it will parse 2 elements) .

So -  the simple answer, which follows directly from the
proposal: no, you don't insert tabs inside equations in this construct.
In simple words, if you want to do it nevertheless - this proposal is
not for you.

*But I am glad that at least you have managed to formulate your concern
finally,  thanks.*


>> If I allow commas as well, this will become not so simple, probably.
>> Also I don't propose syntax for e-mail code exchange, but rather syntax
>> for *work* an this can potentially help a lot of people in everyday
>> work.
>
> /head-desk
>
> You: "I have invented amazing new syntax that cannot be exchanged by
> email. Here, let me email some examples to you."

"GvR have invented amazing new syntax that cannot be preserved
by sending it by e-mail"!
(not me)

Do you understand that basically any python code sent by e-mail converts tabs to
spaces, thus the only way to receive it - is to send binary file?

Maybe you should've made more influence on that in the past and now we
all would have to use spaces only to format the code.
Also maybe include C-brackets so as not to worry when e-mail clients
add extra spaces in front of lines?


>> Also I don't know what kind of human thinks that this:
>>  a + b
>>  is two elements "a" and "+ b"
>> What is "+ b"?
>
> It is unary plus followed by b.
>
> If you don't know Python's existing syntax, how can you possibly expect
> to invent new syntax?

Wow! Uncle Steven knows Python operators.
My question was: why would you have "+ b" in
the first place in your code? So you treat the worst-case scenario
as a normal case - interesting approach  indeed!

By the way, since you are into unrealistic worst-case scenarios:
Imagine you start with Python learning, how you'd like such constructs:

L = [a + b, c, d]
L = [a + b, (c, d)]

For a starter, reading this will be quite painful.

Yes, I have told already that there are _some_ cases when
 tabulation formatting can cause visual confusion.
*But why do you blame me*?
It just the issues with editor's incompleteness.
Simple feature like "set the minimal tab size" would have solved
this issue by 100%. Maybe it even exists in some editors,
I would not be surprised at least.

 I hope you are not seriously thinking that there is good syntax
 that gives retro-tools, wacky people, not wacky people,
 pros, etc. same opportunities.

For instance, there is real demand on adding new control characters
to syntax, so as IDE developers can utilize those for making
better user experience. If you apply same one-sided principles here
then you behave good to one group of people, but just ignorant
to other group of people who want better new experience.

Seriously, your sarcasm is pretty one-sided.
You should try to think a bit wider.


>> I don't want spaces or tabs visible - there is toggle "show tabs"
>> and "toggle show space" for that
>
> /head-desk
>
> You: "This syntax doesn't need tabs and spaces to be visible. Just use
> the Show Tabs and Show Spaces commands on your editor to make them
> visible."

Yep!  Just toggle them if you want to find out. That's a good feature!

And you know, **head-desk'ing too often (and without reason) may
be not good to you.**
We need healthy Steven.


>
>>> Using a particular editor is not and will not be a mandatory
>>> requirement for Python.
>>
>> Using outdated tools or being PEBCAK are not and will not be
>> justification for language syntax improvements.
>
> It is not your choice of what editors people are permitted to use in
> order to read and write Python.

Yeah, but most people do not want to sit with technologies from 80's,
especially when many new possibilities are already available.
And that's why the scene of editors is changing so fast,
there is a lot that makes it easier to work.


>>> - the first one can include nested data structures, while
>>>   the second cannot.
>>
>> Why it can't? did you read the original e-mail?
>
> Of course I did. You said:
>
> "So the idea is to cover only first two levels of
> nesting of course."
>
> With bracket syntax, I can cover unlimited levels of nesting. Yours
> cannot.

Ok, that was a typo, it must be:

"So the idea is to _hide brackets for_ first two levels of
nesting of course."

Thanks for noticing. So it can, but that's not an easy one to
implement.



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

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Fri, May 11, 2018 at 9:12 AM, Ian Kelly  wrote:
> On Thu, May 10, 2018 at 6:34 PM, Mikhail V  wrote:
>> On Wed, May 9, 2018 at 6:25 AM, Steven D'Aprano
>>  wrote:
>>> On Tue, 08 May 2018 23:16:23 +0300, Mikhail V wrote:
>>>
>>
>>>> but I propose Tab-separated elements.
>
> Then these are not ordinary expressions, are they? They're a different
> type of expression and will require a modified parser. This adds
> complexity.

Definitely such syntax will require modifed parser.


>> "GvR have invented amazing new syntax that cannot be preserved
>> by sending it by e-mail"!
>> (not me)
>>
>> Do you understand that basically any python code sent by e-mail converts 
>> tabs to
>> spaces, thus the only way to receive it - is to send binary file?
>
> Um, no, this is false. We send Python code by email all the time.
> 1) Tabs as indentation: Python permits the use of both tabs and spaces

This means if I paste some code _inside_ an existing  block,
I get a Syntax error:
"TabError: inconsistent use of tabs and spaces in indentation"

> 3) Tabs that appear in strings: This one I'll grant you.

This too.

So what is false? Yes with my syntax it will just become
more prone to environments which replace tabs with
spaces. Mostly this happens in e-mails and web forms.
Why they do it I don't have an idea.

Anyway keeping this in mind, I'd prefer not to adapt
the syntax to such things. It would be fair that the software
solutions should address those, as it should not happen.


> In any case, the use of tabs is entirely optional. For the most part,
> programs can be safely emailed whether they contain tabs or not, the

In real situation just send as attachment, with or without such
syntax, it will be
more polite and safe if you wish the person to run the program.
For some talks in email its not *far* worse than now.


>> Yes, I have told already that there are _some_ cases when
>>  tabulation formatting can cause visual confusion.
>> *But why do you blame me*?
>> It just the issues with editor's incompleteness.
>
> That's great, but if I'm editing a file on an embedded system over a
> serial port and the only editor I have available is nano, I should be
> able to use it. You can't just assume that everybody has a fully
> featured editor (and knows how to use it -- what was that point you
> made just above about beginners?)

Wait, wait, wait - we are adult people - what problem causes nano?
I don't have nano so maybe you can tell what happens in nano if you
load for example a text file this:

→a + b →→ a + b →→a + b  →→a + b
→1 →→ 2 →→ 3 →→ 4
→width:→→100% →→!important;

In the above example one arrow → is one tab char.
What exact problem do you experience?
(note, I don't ask to align the columns, I just ask what
real problems you have with that?)
TBH I cant say for tools other than normal editor.
Just hope it will not become my problem to test
all legacy stuff out there.


>> For instance, there is real demand on adding new control characters
>> to syntax, so as IDE developers can utilize those for making
>> better user experience. If you apply same one-sided principles here
>> then you behave good to one group of people, but just ignorant
>> to other group of people who want better new experience.
>
> Please link the approved PEP that is going to add syntactically
> meaningful control characters.

Sorry, i was writing too fast - not control characters, but characters in
general. That was kind of general parallel to the current situation.
I'll try to ask better: for instance, if propose to use some unicode character
operator - so I can use the editor feature.
In theory - many people may potentially benefit but some people
have issues with it in some software.
And the issues may vary in nature - e.g. Steven can't bind a keyboard
shortcut to type it.
OTOH it may be something really bad - a software failure or general
problem. So the question is what would be more _serious/general_ problem.


>>>> I don't want spaces or tabs visible - there is toggle "show tabs"
>>>> and "toggle show space" for that

> Needing to fiddle with editor settings in order to determine how the
> code in front of me that somebody else wrote is organized doesn't
> sound to me like a good feature. That sounds to me like poor
> readability.
>

Sorry, not sure what you mean. Do you propose _visible_ character
instead of e.g. tab? But then you need to hide it to be able
to read normally.


>>
>> "So the idea is to _hide brackets for_ first two levels of
>> nesting of course."
>
> In other words, this syntax is really not appropriate for more than
>

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Fri, May 11, 2018 at 9:39 AM, Ian Kelly  wrote:
> On Mon, May 7, 2018 at 9:45 PM, Mikhail V  wrote:

>> *Example 1. Multi-line strings*
>>
>> data === S :
>> this is multi-line string
>> escape chars: same as in strings (\\, \\n, \\t ...) ,
>> but "no need to 'escape' quotes"
>
> My reaction #1: why 'S'? Python strings have a name: it's 'str'.
> ...
> My reaction #2: what's the point of this construct? Python already has
> multi-line strings that can be used as expressions, not as statements
> only.

#1. I think passing multiline data structures as arguments
is not especially beautiful. Necessary? I don't know.
#2. What is the point? If introduce the new syntax _at all_,
- the cost of adding some additional common types is less -
IOW worth investigating some options?
About string type id - I agree it may be suboptimal with "S", since
it is not like tuples. But well, there must be something.

In this case:

s = """\
multi line string multi multi line string
multi line string multi line string"""

vs:

s === S:
multi line string multi multi line string
multi line string multi line string

Nothing revolutional, just a bit cleaner and with
an indent (which is not necesserily always a good thing
but IMO a bit more presentable).
The problem though, this will require editors to
modify their lexers for highlighting - this is a problem :/


> My reaction #3: Not a fan of adding an '===' operator. We already have
> '=' and '=='. Javascript is another language that uses '===' to mean
> something completely different from this proposal (it's another
> equality operator) and it's a mess there. Come up with something else.
>

"===" is just the least disturbing one I've come up with while
experimenting. I thought it should start with "=" at least.
E.g.
data =%  T :
data =\\  T :
(\\  now is syntaxError: unexpected character after line continuation)

I dont know - frankly I think its too early to start the game of
perfect operator choice.


>> Benefits are easy to see: say I want a tuple of strings:
>>
>> data === T :
>> "foo bar"
>> "hello world"
>> "to be continued..."
>>
>> VS current:
>>
>> data = (
>> "foo bar" ,
>> "hello world" ,
>> "to be continued..." ,
>> )
>>
>> Main problem with the latter are commas, it is not easy
>> to type
>
> In what bizarro world are commas harder to type than tabs? At least if
> I type a comma I know I'll get a comma. If I type a tab then it
> depends on my editor settings what I'll actually get.

Well, in the above case you don't have to type tabs or commas.
As for what character is easier to type : commas or tabs :
I find that Tab key is maybe a bit harder when using together
 with upper number row keys - OTOH when using keypad -
it feels easier. On average I think its comparable.
Also if you type commas, usually you want to type
space after a comma, or  a Tab  ;-)
So Tab maybe will win this race.


>> and, whats more important - hard to notice missing commas.
>
> But it's totally easy to notice missing tabs, right? Not.

**Those are two different things** - commas must be there -
and the issue persists, you want it or not.

I still have feeling that you try to imply that commas have
some role apart from Disambiguation of closely positioned
tokens - that's what they are from reader's POV.
In other words, if inter-token spacing is solid - commas are nothing
but redundant noise.
Do you understand this or not?

Also there was a topic about string lists on 'Ideas' recently -
so thats not only me who notices it.

Issues with input of tabs is more of psychology &
experience I'd say. I haven't problems with that.
Normally I input 2 tabs to make it form a solid whitespace- it
gives me optimal look. And I don't bother too much with
perfect alignment usually.


>> *Example 3. Two-dimensional tuple.*
>>
>> data === T/T :
>
> What about T/S? S/T? S/S? Are these allowed?

Not really. The idea is: to identify common cases
and data structures and try to find an optimal
set of ID's to represent them. But the slash
indicates that it's 2D case - so this one
is sort of explicit sign of higher dimension.

>
> Also, why is there a division operator here?

"slash"


>
>> 123"hello"
>> abc + de f
>>
>> is a synonym for:
>>
>> data = (
>> (1, 2, 3, "hello") ,
>> (a, b, c + d, e, f ) )
>
> If this is supposed t

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Sat, May 12, 2018 at 7:54 AM, Steven D'Aprano
 wrote:
> On Sat, 12 May 2018 02:26:05 +0300, Mikhail V wrote:
>
>> it is just  not a trivial task to find an optimal solution to this
>
> We already have an optimal solution to this.

Yes. current syntax will not go anyway so proposal
addresses cases where it is appropriate and
clearly better.

>
> * It works with any editor, including simple ones.

Ok

> * It is safe for transmit over email, or on web forums,
>   so long as you avoid tabs and use spaces.

I don't use spaces so I'm out of luck already.

> * It is readable by humans without them needing to distinguish
>   between two different kinds of invisible space.

I'm using tabs from childhood and don't find it a problem.

> * It can be easily parsed by hand or by machine.

Parsed by hand?

> * It works with a multitude of text processing tools whether
>   or not they can cope with tabs.

Ok. But this is bullet #1, see above, you repeat it

>
> * It is resistant to many sorts of typos.

Here I think you oversimplify - In fact current syntax
introduces typing problems in many cases:
as a user with very high proficiency in typing and
good sight, I have some trouble inputting nested bracketed
arrays  and spend some time trying to match
corresponding suites. Plus the comma noise here,
so your statement is too one-sided and overestimated.

As said, I remember this and similar issues were raised on 'ideas'
so don't pretend it does not exist.

>
> * It allows great flexibility in the presentation, you aren't
>   forced to lay things out in one specific 2D format.

Only words - but nothing concrete

> * It uses the same consistent rules for the rest of the language,
>   without adding special cases and complexity.

I'll grant you for "special cases", but the rest is quite contradictive.
As said, Python uses indented blocks - not bracketed
blocks as in C.
Python does not make semicolons mandatory.
All this is a great improvement, but it seems you
don't see the parallel here.


> * It is a tried-and-true solution that has been used (with minor
>   modifications) for dozens, possibly hundreds, of programming
>   languages, natural language lists and data formats.

> "natural language lists and data formats"

OTOH all _real_ data list, tables, matrices do not include redundant commas,
unless it is really needed.
Any book, lectures, etc. presents them without commas so its
second nature to any human to see it without commas
and its just better so.



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

Re: Suggestion for a "data" object syntax

[Mikhail V]

On Sat, May 12, 2018 at 5:38 PM, Ian Kelly  wrote:
> On Fri, May 11, 2018 at 5:26 PM, Mikhail V  wrote:
>> On Fri, May 11, 2018 at 9:12 AM, Ian Kelly  wrote:
>>> On Thu, May 10, 2018 at 6:34 PM, Mikhail V  wrote:
>>>> Do you understand that basically any python code sent by e-mail converts 
>>>> tabs to
>>>> spaces, thus the only way to receive it - is to send binary file?

>> So what is false?
>
> Your absurd assertion that the only way to safely email Python code is
> as a binary file.

Why you say so? You have agreed yourself with the assertion.
Also I did not say "safe" but meant that I cannot receive the exact file
in the body of e-mail in case of tabs.


> no support for _fancy features_ like viewing tabs and spaces

:\
is syntax highlighting fancy feature?


>> Sorry, not sure what you mean. Do you propose _visible_ character
>> instead of e.g. tab? But then you need to hide it to be able
>> to read normally.
>
> Why would I need to hide the separator character in order to be able
> to read the data?

So you find e.g. this ok:
→1 →→ 2 →→ 3 →→ 4

>> presentable to the reader. Initial  idea is just use current
>> Python syntax for further nesting:
>>
>> image === T/T:
>> (127,127,127)(127,127,127)(127,127,127)
>> (127,127,127)(127,127,127)(127,127,127)
>> (127,127,127)(127,127,127)(127,127,127)
>>
>> vs:
>> image = (
>> ((127,127,127), (127,127,127), (127,127,127),),
>> ((127,127,127), (127,127,127), (127,127,127),),
>> ((127,127,127), (127,127,127), (127,127,127),),
>> )
>
> And if you have more than three levels of nesting, and you don't
> conveniently just have a bunch of 3-tuples that line up perfectly with
> one another?

Maybe you can come up with some example in current syntax?
I have browsed some projects with a lot of resource definitions.
sometimes it has 3-4 levels of nesting, and I have hard time
understanding the structure - so maybe it is possible to simplify
those according to this syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

"Data blocks" syntax specification draft

[Mikhail V]

I have made up a printable PDF with the current version
of the syntax suggestion.

https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

After some of your comments I've made some further
re-considerations, e.g. element separation should
be now much simpler.
A lot of examples with comparison included.


Comments, suggestions are welcome.


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

"Data blocks" syntax specification draft

[Mikhail V]

> >
> > Comments, suggestions are welcome.
> >
>
> One comment.
>
> I'm not interested in downloading a PDF. Can you rework your document
> to be in a more textual format like Markdown or reStructuredText?
> Since you're hosting on GitHub anyway, the rendering can be done
> automatically.
>
> ChrisA


What against PDF?
Anyway, I have reloaded files with most recent corrections in various formats:

PDF
https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf

TXT
https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.txt

HTML(direct preview link)
http://htmlpreview.github.io/?https://raw.githubusercontent.com/Mikhail22/Documents/master/data-blocks-v01.html


"Markdown" is too vague - there dozens of markdown styles and
also they include subsets of HTML. It is just plain text with tags -
it cannot represent syntax in civilized form (unless I embed images
for every source example - but then it is too inconvenient for editing).
Source examples on Github will force a crappy font and replace tabs.

I suggest you just view HTML or PDF - it looks better and if you need
source - just download TXT - it has tabs preserved at least.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 3:02 AM, Ian Kelly  wrote:
> On Sun, May 20, 2018 at 4:28 PM, Mikhail V  wrote:
>> "Markdown" is too vague - there dozens of markdown styles and
>> also they include subsets of HTML. It is just plain text with tags
>
> The whole point of Markdown is that it's readable as plain text
> precisely because it *doesn't* use obvious tags like HTML.
>
>> it cannot represent syntax in civilized form (unless I embed images
>> for every source example - but then it is too inconvenient for editing).
>
> Why would you need images to represent syntax? What's wrong with code blocks?

Code blocks where? In what software/webkit it is supposed to be
rendered?
How do you imagine a serious proposal with such syntax comparisons
without ability to make more or less precise presentation in various
fonts?
To speak about significant syntax change seriously you need many samples
in at least 2-3 modern quality fonts. Modulo a pair of reasonable color schemes.
Modern editors (and users) are far beyond type-writer fonts.

>> I suggest you just view HTML or PDF - it looks better and if you need
>> source - just download TXT - it has tabs preserved at least.
>
> You know, if you're serious about this proposal, then eventually you
> will have to write a PEP for it. And that PEP has a required style and
> format. And that format is reStructuredText.

Making reStructuredText is not a problem, but as said - it is not
serious to speak of syntax without good samples. IOW besides a
Markdown PEP such proposal requires a lot of supplementary material.
The best method is to create images of code snippets in addition to
text. Main advantage of images that it will be independent of browser/OS
but it requires some extra job.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 5:20 AM, Chris Angelico  wrote:
> On Mon, May 21, 2018 at 8:28 AM, Mikhail V  wrote:
>>> >
>>> > Comments, suggestions are welcome.
>>> >
>>>
>>> One comment.
>>>
>>> I'm not interested in downloading a PDF. Can you rework your document
>>> to be in a more textual format like Markdown or reStructuredText?
>>> Since you're hosting on GitHub anyway, the rendering can be done
>>> automatically.
>>>
>>> ChrisA
>>
>>
>> What against PDF?
>> Anyway, I have reloaded files with most recent corrections in various 
>> formats:
>
> The very best way to put your proposal is right here in the body of
> the email, as plain Unicode (and primarily ASCII) text, no images, no
> external links, no side dependencies.

Well that's the easiest way for me, but - if the document changes constantly
then it is more convenient to have a web link for a document.

> The second best way is to have a simple link that anyone can click on
> to read your proposal. It's an external dependency, but you're
> depending on a web browser and a basic internet connection, and
> nothing more.
>
> Forcing us to download a PDF and then read it? Well, it's your
> decision. My decision is that I cannot be bothered going to THAT much
> effort to figure out what you're saying.

THAT much effort to click two times instead of one - and get a
formatted document instead of plain bw text. o-kaay..

> The PDF link you give is not viewable on the web

Dunno, works for me - I click it and see immediately my PDF in
the browser. But I (and many people) prefer to download anyway.
Also I provided a link to HTML - also works per click and looks even
better than PDF.

> As Ian says, reStructuredText is the only supported format [1] for
> PEPs, so you may as well just start using it straight away. GitHub
> automatically renders it if you use a ".rst" extension on your file,
> so the rendered form would be visible on the web.

Ok. How is about images? this proposal will require a lot of images
- otherwise people who read it are forced to copy-paste snippets
into their code editors to understand how it may look in reality.

> I'm not going to read your proposal if you force me to go to heaps of
> effort for it.

heaps! oh come on, youre making up again.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 7:05 AM, Chris Angelico  wrote:
>>> Forcing us to download a PDF and then read it? Well, it's your
>>> decision. My decision is that I cannot be bothered going to THAT much
>>> effort to figure out what you're saying.
>>
>> THAT much effort to click two times instead of one - and get a
>> formatted document instead of plain bw text. o-kaay..
>
> Two clicks? No, that isn't how it happened for me. I clicked on it and
> then I couldn't see the content.

Sorry I don't know - seems that everyone can see it.

> What second click am I supposed to do
> that shows me the page?

No, no second click is needed. But if you want to download a file -
there is a button "download file". So in a pair of clicks you get
a file on your PC and you can use your favorite viewer to view
PDF, which is IMO more convenient than in a browser.

>> Ok. How is about images? this proposal will require a lot of images
>> - otherwise people who read it are forced to copy-paste snippets
>> into their code editors to understand how it may look in reality.
>
> If you're proposing syntax for Python, it's ultimately going to have
> to be text.

All of files that I provided are TEXT. Well maybe PDF is a bit "less text
than TXT" but still its just text pieces.

> You cannot say "and every text editor has to render it
> like this". If you can't demonstrate it using plain text, you have a
> major problem on your hands.

How do you do that?!  You're truly unsurpassed master of polemics.
How you turn everything upside down so easily? - that is _me_ who tells
to make _various_ samples so as to be able to see difference by
various fonts. And it is _you_ who say "everybody look at black and
white sample with a font out of 80' ".
WTF means "If you can't demonstrate it using plain text"?
There is nothing more simple than demonstrate it in plain text.
But it is not enough to judge the syntax since there is
_huge_ difference of fonts, and presence of highlighting makes huge
difference especially for expressions with keywords.

>>> I'm not going to read your proposal if you force me to go to heaps of
>>> effort for it.
>>
>> heaps! oh come on, youre making up again.
>
> No, I'm not making it up. Just because the PDF works perfectly for
> you, you assume that it'll work perfectly for everyone.

Look, PDF is one of the most widely used document exchange formats.
And you know it. I personally  don't need the PDF either - creating it
just adds me
work. And I am not debating anything about it, just made it for convenience
since someone maybe prefer it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 2:14 PM, Ned Batchelder  wrote:
> On 5/19/18 10:58 PM, Mikhail V wrote:
>>
>> I have made up a printable PDF with the current version
>> of the syntax suggestion.
>>
>> https://github.com/Mikhail22/Documents/blob/master/data-blocks-v01.pdf
>>
>> After some of your comments I've made some further
>> re-considerations, e.g. element separation should
>> be now much simpler.
>> A lot of examples with comparison included.
>>
>>
>> Comments, suggestions are welcome.
>>
>
> Mikhail, you have a completely different esthetic for syntax than the rest
> of the Python world.

In what sense? I don't propose to add braces to Python or anything like that.

> Your proposal seems to have almost nothing in common
> with existing Python syntax.

Well, if  speak of adding any embedded data syntax at all - how do you think:
should the embedded syntax copy everything? Even if it will look worse
in the end?
Frankly, I don't think so.
If you ask me:  may it be totally different syntax than Python?
I'd say - no, but it should be something compromising.

What other criteria is there?
Main benefits i see in Python syntax: indentation-based,
no termination tokens, new-line statement separation. Overall tendency
to prioritize readability
(e.g. over parse-ability). All these points i try to oblige.
Actually if think deeper of it - these points are not even something "Pythonic"
but merely just common sense and some basic readability principles.

> Your approach to whitespace is different.
> You've ignored existing words (tuple, str) in favor of new shorthands (t,s).

Yes. Turns out these two things should work better for presentation,
so nothing much unexpectable and nothing personal against existing words ;-).
Type abbreviations deserve more explanation in the doc though.
Simply put - if I write whole words - then type names _will dominate over data_.
E.g.:

/// tuple
   /// tuple
  foo  bar

and even so:

tuple:
   tuple:
  foo  bar

Might it be that the latter is more 'Pythonic'? Maybe yes. But how it
will look on average structure - should be compared.
Again: with proper highlighting this _might_ be an option, but without
highlighting -
sorry, would be just too hard to eyeball the nodes.

Regarding further smaller details - semicolons, asterisks - those are
subject for
further observations and may change.


> Parentheses enclosing strings!?

:-) Ok, here I agree -   the whole 'string type' part - that would be
just too much to
slip through. This would cause inconsistence and add confusion when
placed together with
normal token presentation structs. Although e.g. in a separate file
with a string-only data
it could make the difference.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 1:41 PM, Chris Lindsay via Python-list
 wrote:

> If a block of static data is large enough to start to be ugly, a common
> approach is to load the data from some other file, in a language which is
> designed around structured data.


Maybe it is common in industrial applications but not in smaller production,
and according to my observation not common at all in all occasional scripts.

>YAML comes to mind

Actually plugging a data syntax in existing language is not a new idea.
Though I don't know real success stories.

> What use-case do you foresee for your proposed new format, that isn't
> already (better) accomplished by using a separate structured
> data/serialisation language?

Well everything described in the doc is quite common. So simply put,
for all data beyond trivial inline [1,2,3].

If your idea is to use external data for all scenarios - then there are
many questions - which toolchains, file organisation, distribution etc.
One common approach is an TSV/ CSV editor plus a quick dirty
self-defined parser.
One criteria for a syntax - how simple to edit it in normal text editor
and how other existing data editors can do it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Mon, May 21, 2018 at 3:48 PM, bartc  wrote:

>
> This is intended to be used inside actual Python programs?
>
> In that case code is normally displayed in fixed pitch, as it would normally
> be viewed in a code editor, even if part of a document.
>
> But I have to say it looks pretty terrible, and I can't see that it buys
> much over normal syntax.

Ha, here we go. Last time I have used fixed pitch font for work -
maybe 4 years ago.
(and IMO fixed pitch font plus specifically Python - I find quite a blasphemy)

So, you re right, of course in one sense: "///" looks terrible with
a fixed pitch font! That's so true, but also it is true that this ///
I well maybe change for something less font-sensitive.
And in all fonts other than fixed pitch it looks cute enough.

Simply speaking, if it was not for Python, I might propose something
like:

# t
   # t
  11  22  33

You get the point?
So basically all nice chars are already occupied.
Proposing Unicode symbols -- that will probably will be
dead on arrival (just remembering some of such past proposals).
Leaving out symbols could be an option as well.
Still the structure needs a syntactical entry point.
E.g.

data = ///
t
   t
  11  22  33

Hmm. not bad. But I must think about parsing as well.


> It's not clear what ///. is for, or why it's necessary (presumably you have
> to use ///. /// instead of /// ///).

"///."  is meant to inherit the previous (parent) type:

/// t
   /// .
  /// .

is same as

/// t
   /// t
  /// t

So I can change types of all child nodes with one keystroke.


>
> The ///d dictionary example is ambiguous: can you have more than one
> key:value per line or not? If so, it would look like this:
>
>   ///d "a" "b" "c" "d" "e" "f"

///d   "a" "b""c" "d""e" "f"

Now better? :-)

Or compare these two:

{"a": "b", "c": "d", "e": "f"}

///d   "a" "b""c" "d""e" "f"

I'd say, the second one is much better.


> Or do you also allow: date = ///  with data following on the next line?

Yes, all this should be legal:

data = /// t
   11 22 33

data =\
/// t
   11 22 33

data = /// t  11 22 33


But this probly not good:

data = /// t  11 22 33  /// t  44  55

Because it will not be clear for the reader how further suite termination
happens.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Tue, May 22, 2018 at 9:01 AM, Christian Gollwitzer  wrote:
> Am 22.05.18 um 04:17 schrieb Mikhail V:
>>> YAML comes to mind
>>
>>
>> Actually plugging a data syntax in existing language is not a new idea.
>> Though I don't know real success stories.
>>
>
> Thing is, you can do it already now in the script, without modifying the
> Python interpreter, by parsing a triple-quoted string. See the examples
> right here: http://pyyaml.org/wiki/PyYAMLDocumentation
>


Yes. That is exactly what I wanted to discuss actually.
So the feature, which makes it possible in this case  is
triple quote string (TQS).

I think it would be appropriate to propose an alternative
to TQS for this specific purposes. Namely for making it
easier to implement parsers and embedded syntaxes.

So what do I have now with triple quoted strings -
a simple example:

if 1:
s = """\
print ("\n") \\
foo = 5
"""

So there is a _possibility_ in the sense it is possible to do, so
let's say I have a lib with a parser, etc. Though now a developer
and a user will face quite real issues:

- TQS itself has its specific purpose already in many contents,
  which may mean for example hard-coded syntax highlighting
- there a lot of things happening here: e.g. in the above example
  I use "\n" which I assume a part of string, or \\ - but it is interpreted.
  Maybe some other things regarding escaping. This particular
  issue maybe a blocker for making use of TQS in some data cases,
  Say if the target source text need these very characters.

- indentation is the part of TQS. That is of couse by design
  so and it's quite logical, though it is hard-coded behaviour and thus
  does not make the presentation a natural part of blocks containing
  this string.
- appearance: imagine you have some small chunks of embedded
  code parts and you will still have the closing """ everywhere -
  that would be really hairy.


The alternative proposal therefore comes down to a "data block" syntax,
without much assumption about the contents of the block.

This should be simpler to implement, because it should not need a lot
of parsing rules - only some basic options. At the same time it enables
the 'embedding' of user-defined blocks/syntax more naturally
looking than TQS.

My thoughts on possible solution.
-

Problem one: make it look natural inside python source.
Current Python behaviour: very simply speaking, first leading white space
on a line is taken and compared with the one from the next line.
Its Okay for statements, but not okay for raw text data -
because probably I want custom leading whitespaces:

string =
 abc
   abc

(So the TQS takes it simple - grabs it from the line beginning)

So the idea:
- add such a block  to syntax
- *force explicit parameter for the indent charaters.*

Explanation:
[here i'll use same symbol /// for the data entry point, but of course it can
be changed if a better idea comes later. Also for now, just for simplicity -
the rule is that the contents of a block starts always on the new line.

So, e.g. this:

data = /// s4
first line
last line
the rest python code

- will parse the block and knock out leading 4 spaces.
i.e. if the first line has 5 leading spaces then 1 space will be left
in the string. Block parsing terminates when the next line does not
satisfy the indent sequence (4 spaces in this case).
Another obvious type: tabs:

data = /// t1
first line
last line
the rest python code

Will do the same but with one tabstop character.

Actually that's it!
Some further ideas:

data = /// ts
- "any whitespace" (mimic current Python behaviour)

data = /// s# or
data = /// t
- simply count amount of spaces (tabs) from first
  line and proceed, otherwise terminate.

data = /// "???"
??? abc foo bar
???

- defines indent character by string: crazy idea but why not.

Language  parameter, e.g.:
data = /// t1."yaml"

-this can be reserved for future usage by code analysis tools
or dynamic syntax highlighting.

That's just a rough specification.

What should it give as result:

1. No clash with current TQS rules - less worries
  about reserved characters.

2. Built-in indentation parsing parameter makes it more or
  less natural continuation of Python blocks and is char-precise,
  which is very important here.

3. Independent of the indent of containing block!

4. Parameter descriptor can be developed in such manner
   that it allows more customisation and additions in the future.


Does seem to be more generalized problem-solving here.

One problem, as usual - tabs may be implicitly converted
to spaces by some software. That obviously could brake
something, but so is with any tabs, and its not related to
Python problem.


Is there something I miss here?
What caveats can be with such approach?



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

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Tue, May 22, 2018 at 1:25 PM, bartc  wrote:
> On 22/05/2018 03:49, Mikhail V wrote:
>>
>> On Mon, May 21, 2018 at 3:48 PM, bartc  wrote:
>>
>> # t
>> # t
>>11  22  33
>>
>
> Is this example complete? Presumably it means ((11,22,33),).

Yep.

>
>> You get the point?
>> So basically all nice chars are already occupied.
>
> You mean for introducing tuple, list and dict literals?

No, I've meant the node (or whole data block) entry point chars ///.

So in such an language full of various operators, it is
just hard to find anything that does not clash with some
current meaning yet looks adequate and is ASCII.

A quick note: thanks for your comments, I'll  just note that I've
moved to some more promising related proposal (see last posts in this thread),
so the original one will move to later considerations.
so the nuances will be reconsidered anyway.


> Python already uses
> (, [ and { for those, with the advantage of having a closing ), ] and } to
> make it easier to see where each ends.

Ehm, for inline usage - i.e. everywhere on a line - closing tags are necessity.
My whole idea was about indentation based data - so there it is redundant noise.
You may disagree as well, since I've noticed in some previous thread
that you prefer Fortran-like termination tags. So that's quite personal I think.

As for more objective points: currently many brackets are 'overloaded'
and moreover, they are all almost "homoglyphs" - very similar characters.

For an inline solution I'd prefer it e.g.
for a tuple:

{t  11  22  33}

nested:
{t  11  {t  11  22}  22}

Yes, it IS worse than:
{11  {11  22}  22}

But still one might need _various types_ so brackets only - has
limited potential in this sense.


>>> The ///d dictionary example is ambiguous: can you have more than one
>>> key:value per line or not? If so, it would look like this:
>>>
>>>///d "a" "b" "c" "d" "e" "f"
>>
>>
>> ///d   "a" "b""c" "d""e" "f"
>>
>> Now better? :-)
>
>
> Not really.
> Suppose one got accidentally missed out, and there was some
> spurious name at the end,

Not sure about your case, but it is up to you to format it to make it
more readable - whitespace / newline separation gives enough possibilities to
do so. And for me the lack of commas is of great benefit.
 _Some_ punctuation can be added in some cases (see e.g. "node
stacking section" in original document - dicts may adopt this as well
but I see no necessity at least for this case)


> It's not clear whether:
>
>   ///d a b
> c e
> f x
>
> is allowed ?

allowed, but i'd say merely discouraged for industrial usage. better start
newline at least for multiline contents.

> I think this is an interesting first draft of an idea, but it doesn't seem
> rigorous. And people don't like that triple stroke prefix, or those single
> letter codes (why not just use 'tuple', 'list', 'dict')?
>
> For example, here is a proposal I've just made up for a similar idea, but to
> make such constructors obey similar rules to Python blocks:
>
>  tuple:
>  10
>  20
>  30
>
>  list:
>  list:
>  10
>  tuple: 5,6,7
>  30
>  "forty"
>  "fifty"
>

Cool, I've commented on similar option actually in some post before -
it might be ok
with type codes grayed-out and good coloring, but in black and white it is a bit
"wall of text" - not much emphasis on _structure_. But its ok - good option.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: "Data blocks" syntax specification draft

[Mikhail V]

On Wed, May 23, 2018 at 2:25 AM, Dan Strohl  wrote:
>

>>
>> Explanation:
>> [here i'll use same symbol /// for the data entry point, but of course it 
>> can be
>> changed if a better idea comes later. Also for now, just for simplicity - 
>> the rule
>> is that the contents of a block starts always on the new line.
>>
>> So, e.g. this:
>>
>> data = /// s4
>> first line
>> last line
>> the rest python code
>>
>> - will parse the block and knock out leading 4 spaces.
>> i.e. if the first line has 5 leading spaces then 1 space will be left in the 
>> string.
>> Block parsing terminates when the next line does not satisfy the indent
>> sequence (4 spaces in this case).
>
>
> Personally though, I would not hard code it to knock out 4 leading spaces.
> I would have it handle spaces the same was that the existing parser does,

If I understand you correctly, then I think I have this option already
described,
i.e. these:

>> data = /// ts
>>
>> - "any whitespace" (mimic current Python behaviour)
>>
>> data = /// s# or
>> data = /// t
>>
>> - simply count amount of spaces (tabs) from first
>>   line and proceed, otherwise terminate.


Though hard-coded knock-out is also very useful, e.g. for this:

data = /// s4
First line indented more (8 spaces)
second - less (4 spaces)
rest code

So this will preserve formatting.


>> data = /// "???"
>> ??? abc foo bar
>> ???
>>
>> - defines indent character by string: crazy idea but why not.
>>
>
> Nope, don't like this one... It's far enough from Python normal that it seems
> unlikely to not get through, and (personally at least), I struggle to see the 
> benefit.

Heh, that was merely joke - but OTOH one could use it for hard-coded
indent sequences:

data = /// ""
First line indented more (8 spaces)
second - less (4 spaces)
rest code

A bit sloppy look, but it generalizes some uses. But granted - I don't
see much real applications besides than space and tab indented block
anyway - so it's under question.


>> Language  parameter, e.g.:
>> data = /// t1."yaml"
>>
>> -this can be reserved for future usage by code analysis tools or dynamic
>> syntax highlighting.
>>
>
> I can see where this might be interesting, but again, I just don't see the 
> need,

I think you're right  - if need a directive for some analysis tool then one
can make for example a consideration to precede the whole statement
with a directive, say in a comment:

# lang "yaml"
data = /// t
first line
last line
rest




Also I am thinking about this - there might be one useful 'hack".
One could even allow single-line usage, e.g.;
(with a semicolon)

data = /// s2:  first line

- so this would start parsing just after colon :
"pretending it is block.
This may be not so fat-fingered-proof and 'inconsistent',
but in the end of the day, might be a win actually.



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

Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:
> First of all, I suggest splitting this into a separate proposal (new thread) 
> that way you will avoid confusion for people who are still considering the 
> older proposal, and for the (probably many) people who have stopped reding 
> the old thread due to some of the more heated conversations in there.
>
>>
>> Though hard-coded knock-out is also very useful, e.g. for this:
>>
>> data = /// s4
>> First line indented more (8 spaces)
>> second - less (4 spaces)
>> rest code
>>
>> So this will preserve formatting.
>>

> True, but in everything, there is a balance between
> flexibility and complexity. Nothing else in python
> (that I can think of) forces people to use 4 spaces,
> that's merely a style thing.  If I want to use 2 spaces,
> I can, I've seen modules that use 3 spaces for
> indenting and it works fine.  So, the flexibility of
> adding the ability to further indent the first line seems
> to me to be outweighed by the added complexity
> of this being "different".

I think we might have a misunderstanding here.
I admit I have tendency to use false terms sometimes -
in this case I did not mean "hard-coded", but rather with
parameter which is taken by the parser.

Namely the proposal is to use 'de-dention' parameter in
such form:

data = /// sN # and
data = /// tN

Where N - is the amount of characters, spaces (s) or
tabs (t).
This should cover most use cases.
It implies of course that the user should know himself
what he is doing.

More concrete example:

def func():
foobar
data = /// s2
  first line
  last line
foobar

will store same data as:
data = "first linelast line"

(assuming of course no trailing spaces were
in original lines)

So obviously the minimal amount in a parameter is 1,
otherwise it will not work at all.

That's actually it. I am inclining to opinion that no
further parameters are necessary, but of course
there might be few other common use case.
IOW it would be not correct to totally disregard
considering some additional options.



>> # lang "yaml"
>> data = /// t
>> first line
>> last line
>> rest
>
> Again, you're complicating the thought without really
> [...] primitives should have as few caveats as possible.
> [...] Extra features are fine, but when they start making
> it "more complex" to use, then you should back off.>

I 100% agree with you. In this case it is better to concentrate
on the most 'low-level' behaviour.


>> Also I am thinking about this - there might be one useful 'hack".
>> One could even allow single-line usage, e.g.; (with a semicolon)
>>
>> data = /// s2:  first line
>>
>> - so this would start parsing just after colon :
>> "pretending it is block.
>> This may be not so fat-fingered-proof and 'inconsistent', but in the end of 
>> the
>> day, might be a win actually.
>>
>>
>
> If you are thinking about this road, what about
> instead making another reserved word and
> approaching it like class or def, for example;
>
> datablock data:
> first line
> second line

Well it looks ok, but traditionally it is forbidden to introduce
any new keywords, unless it is absolutely necessary.


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

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 8:08 PM, Mikhail V  wrote:
> On Wed, May 23, 2018 at 4:19 PM, Dan Strohl  wrote:

> data = /// sN # and
> data = /// tN
>
> Where N - is the amount of characters, spaces (s) or
> tabs (t).
> This should cover most use cases.
> It implies of course that the user should know himself
> what he is doing.
>
> More concrete example:
>
> def func():
> foobar
> data = /// s2
>   first line
>   last line
> foobar
>
> will store same data as:
> data = "first linelast line"

oops, I meant it to be:
data = "first line\nlast line"

sorry for possible confusion

>
> (assuming of course no trailing spaces were
> in original lines)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 11:45 PM, MRAB  wrote:

>>> def func():
>>> foobar
>>> data = /// s2
>>>   first line
>>>   last line
>>> foobar
>>>

> Instead of the "s2", etc:
>
> def func():
> foobar
> data = >> :
>   first line
>   last line
> foobar
>
> Leading indentation to the level of the first line would be stripped.
>
> If you want additional indentation, then provide a string literal:
>
> def func():
> foobar
> data = >> '':
>   first line
>   last line
> foobar

Such approach has its benefits.
and ">>" looks nice.

So the benefit here is that you make it more
compact - no parameters needed.
But as you see, it just cannot parse the text in
case of positive indent.
Or otherwise I need to edit the text and then, if say I want
to paste it back elsewhere - edit again. This small nuance can
get in the way.
Also semantically - I find it a bit of implication - it's something
automatic.


> As the last line also ends with '\n', the result should be 'first line\nlast
> line\n'.

Sorry, I can't see how this would be beneficial?
This would mean every string will have trailing \n.
Even if it is one word.
Maybe it could help in some cases, for example
if you write a code generator and then append to
a file consequently.
But in general I disagree with this approach.

Also it is counter-intuitive - for example if I open a
text editor and type "a", save it and then read it with
python script - then I get only "a" but not "a\n".

But maybe I am missing something.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Indented multi-line strings

[Mikhail V]

On Wed, May 23, 2018 at 11:56 PM, Bob van der Poel  wrote:
> On Wed, May 23, 2018 at 1:45 PM, MRAB  wrote:
>
>> If you want additional indentation, then provide a string literal:
>>
>> def func():
>> foobar
>> data = >> '':
>>   first line
>>   last line
>> foobar
>>
>> for 'first line\nlast line\n' or:
>>
>> def func():
>> foobar
>> data = >> '\t':
>>   first line
>>   last line
>> foobar
>>
>> for '\tfirst line\n\tlast line\n'.
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
> I think this is getting way too complex to fix a problem which doesn't
> exist.

@Bob
It is not clear at all about which issue are you writing the comment.
Also not clear to whom is it addressed (me or MRAB).

Please - can you be specific and respectful.

And a general note - It is hard to support the conversation when the
amount of rational content becomes low.
May be it surprises you but I _read_ the comments and try to
understand them.



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

Raw string statement (proposal)

[Mikhail V]

Hi.
I've put some thoughts together, and
need some feedback on this proposal.
Main question is:  Is it convincing?
Is there any flaw?
My own opinion - there IS something to chase.
Still the justification for such syntax is hard.



Raw string statement
--

Issue
-

Vast majority of tasks include operations with text in
various grades of complexity. It is relevant even by
simple ubiquitous tasks, like for example defining file paths.
String literals are interpreted - i.e. special character "\" may
change the contents of a string.
Python raw string r"" has the least amount of such cases :
namely the inclusion of the quote character requires escaping.
There is still no string type which is totally uninterpreted.
As a result, any text piece that contains a quote must
be *edited* before it can be used in sources.

This may seem a minor problem, but if we count all
cases, then the cumulative long-term impact may be significant.
Also this problem may become more acute in cases related to:
- development of text/code generators
- and, in general, all text processing with a lot of
  literal data definition
- proofreading

Such applications may *require* a lot of embedded text definitions and
this may even lead to frustration by proofreading of 'escaped' pieces
and it adds necessity for keeping track of changes in these pieces.
Using external resources for these tasks could help, but it may lead to
even worse experience because of spread definitions
and increased maintenance times.

The most common solution in existing syntax - triple quoted
strings and raw strings has some additional issues:

- Data is parsed including indents. This may be a benefit for some
cases (e.g. start lines always without any indent) but it also may
become confusing for the readers when not aligned with
containing block. So-called "de-denting" is also needed.

- Triple quotes cause visual ambiguity in some edge-cases,
e.g. when a string starts or ends with a quote. Also in many fonts
a pair of single quotes is visually identical to one double quote.


Proposal
---

Current proposal suggests adding syntax for the "raw text" statement.
This should enable the possibility to define text pieces in source
code without the need for interpreted characters.
Thereby it should solve the mentioned issues.
Additionally it should solve some issues with visual appearance.


Specification
-

Raw string statement has the following form:

name >>> "condition_string"
... text ...

in example:

data >>> "  "
  begin
  end
#rest

will parse the block by comparing each next
line part with the string "  " (2 spaces here).
This will return: "  begin\n  end"

-- Additional option: parse and remove:

data >>> !"  "
  begin
  end
#rest

Will parse by the same rule but also remove
the string from the result: "begin\nend"

- Additional option: parse *until* condition:

data >>> ?"#eof"
begin
end
#eof

Will parse up to character sequence "#eof" (if it is on the
same level) and returns: "begin\nend".
The benefit of last option - the data can be put at zero
level. It may be also prefered due to explicit terminator.


General rules:

- parsing is aware of the indent of containing
  block, i.e. no de-dention needed.
- single line assignment may be allowed with
  some restrictions.

Difficulties:

- change of core parsing rules
- backward compatibility broken
- syntax highlighting may not work
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Raw string statement (proposal)

[Mikhail V]

On Fri, May 25, 2018 at 1:15 PM, bartc  wrote:
> On 25/05/2018 05:34, Mikhail V wrote:
>

> I had one big problem with your proposal, which is that I couldn't make head
> or tail of your syntax. Such a thing should be immediately obvious.
>
> (In your first two examples, what IS the exact string that you're trying to
> incorporate? That is not clear at all.)

You re right, this part is not very clear.
I was working on syntax mainly, but the document is getting better.
I make constant changes to it, here is a link on github:

https://github.com/Mikhail22/Documents/blob/master/raw-strings.rst


> One problem here is how to deal with embedded non-printable characters: CR,
> LF and TAB might become part of the normal source text, but how about
> anything else? Or would you only allow text that might appear in a text file
> where those characters would also cause issues?

This syntax does not imply anything about text. From the editor's POV
it's just the same as it is now - you can insert anything in a .py file.
So it does not add new cases to current state of affairs in this regard.
But maybe I'm not completely understand your question.



> Another thing that might come up: suppose you do come up with a workable
> scheme, and have a source file PROG1.PY which contains such raw strings.
>
> Would it then be possible to create a source file PROG2.PY which contains
> PROG1.PY as a raw string? That is, without changing the text from PROG1.PY
> at all.

Should be fine, with only difference that you must
indent the PROG1.PY if it will be placed inside an indented suite.
I was thinking about this nuance - I've added a special case for this
in addition to the ? flag.

data >>> X"#tag"
...
#tag

It will treat the block "as is", namely grab everythin together with indents,
like in TQS. This may cover some edge-cases.


> Here's one scheme I use in another language:
>
>print strinclude "file.txt"
>
> 'strinclude "file.txt"' is interpreted as a string literal which contains
> the contents of file.txt, with escapes used as needed. In fact it can be
> used for binary files too.
> [...]
> As for a better proposal, I'm inclined not to make it part of the language
> at all, but to make it an editor feature: insert a block of arbitrary text,
> and give a command to turn it into a string literal. With perhaps another
> command to take a string literal within a program and view it as un-escaped
> text.

I think it may be vice-versa - including links to external files
might be more effective approach in some sense. It only needs
some special kind of editor that would seamlessly embed them.
Though I don't know of such feature frankly speaking.
And there might be many caveats here.

And the feature to convert a text piece to Python string directly -
it is already possible in many editors - via macros or scripting.
But I think you falsely think that it is the solution to the problem.
Such changes - it's exactly what should be avoided.

In theory - an adequate feature like this (if it has real value)
will require the editor to track all manipulations - and give feedback.
You don't know when you have escaped some string or
not. And how do you save or see this events?
IOW this might be way harder to implement than the
approach with external text bits.


The simplest solution would be of course to write a translator.
For such syntax change - it is **millions** times easier than
what you've described.



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

Re: Raw string statement (proposal)

[Mikhail V]

On Sat, May 26, 2018 at 10:55 AM, Steven D'Aprano
 wrote:
> On Sat, 26 May 2018 08:09:51 +0300, Mikhail V wrote:
>
>> On Fri, May 25, 2018 at 1:15 PM, bartc  wrote:
> [...]
>>> One problem here is how to deal with embedded non-printable characters:
>>> CR, LF and TAB might become part of the normal source text, but how
>>> about anything else? Or would you only allow text that might appear in
>>> a text file where those characters would also cause issues?
>>
>> This syntax does not imply anything about text. From the editor's POV
>> it's just the same as it is now - you can insert anything in a .py file.
>> So it does not add new cases to current state of affairs in this regard.
>> But maybe I'm not completely understand your question.
>
> Here is a string assigned to name `s` using Python's current syntax:
>
> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>
> How do you represent that assignment using your syntax?

Hope its not mandatory to decipher your random example.
If for example I'd want to work with a lot of non-presentable
characters, I'd use a more human-oriented notation than this ^.
And that is exactly where raw strings are needed.

So I'd make a readable notation where I can present a character
by its ordinal enclosed in some tag for example {10}. Then just
write a function which collapses those depending on further needs:

data >>| abc{10}def
data = f(data)

And the notation itself can be chosen depending on my needs.
Hope you get the point.

>
>
> And another example:
>
> s = """this is some text
> x = 'a'
> y = 'b'"""
> t = 'c'
>
> How do we write that piece of code using your syntax?

That's too easy - maybe you can try it yourself?
I am not trying to imply anything, but I don't see how
this example can cause problems - just put the TQS in a block.


>>> Would it then be possible to create a source file PROG2.PY which
>>> contains PROG1.PY as a raw string? That is, without changing the text
>>> from PROG1.PY at all.
>>
>> Should be fine, with only difference that you must indent the PROG1.PY
>> if it will be placed inside an indented suite.
>
> Bart said WITHOUT CHANGING THE TEXT. Indenting it is changing the text.

I know. So you've decided to share that you also understood this?
Good, I'm glad that you understand :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Raw string statement (proposal)

[Mikhail V]

On Sat, May 26, 2018 at 7:10 PM, Steven D'Aprano
 wrote:
> On Sat, 26 May 2018 18:22:15 +0300, Mikhail V wrote:
>
>>> Here is a string assigned to name `s` using Python's current syntax:
>>>
>>> s = "some\ncharacters\0abc\x01\ndef\uFF0A\nhere"
>>>
>>> How do you represent that assignment using your syntax?
>>
>> Hope its not mandatory to decipher your random example. If for example
>> I'd want to work with a lot of non-presentable characters, I'd use a
>> more human-oriented notation than this ^. And that is exactly where raw
>> strings are needed.
>>
>> So I'd make a readable notation where I can present a character by its
>> ordinal enclosed in some tag for example {10}. Then just write a
>> function which collapses those depending on further needs:
>>
>> data >>| abc{10}def
>> data = f(data)
>>
>> And the notation itself can be chosen depending on my needs. Hope you
>> get the point.
>
> Loud and clear: your syntax has no way of representing the string s.

Just 5 lines before it is - you did not notice.


> temp = >>| Mikhail's syntax for {65290} is {65290}
> Can you see the problem yet? How does your collapse function f()
> distinguish between the escape code {65290} and the literal string
> {65290}?

Look, there is no any problem here. You can choose
whatever YOU want to write "{" and "}". e.g. I'd pick {<} {>}.

temp = >>| Mikhail's syntax for {65290} is {<}65290{>}


I just show you that syntax allows you not only input TEXT
without any manipulations, but also it allows to solve any task related
to custom presentation - in this case you want work with
ordinals for example. And you may end up with a scheme which
reads way better than your cryptic example.

This motivation is covered in documentation, but maybe
not good enough? anyway you're welcome to make suggestion for
the documentation.

I'll also ask you a question  -
Which such non-text codes you may need to
generate C code? Python code? HTML code?


>
> And we've gone from a single string literal, which is an expression that
> can be used anywhere, to a statement that cannot be used in expressions.

Ok show me your suggestion for a raw string definition for expressions
(no modifications to source text and no usage of invisible control chars).

> I don't know what TQS is supposed to mean.
Triple Quoted String



> s = >>>
> this is some text
> x = 'a'
> y = 'b'
> t = 'c'
>
>
> Am I close?

Yes very close, just shift it with a char of your choice, e.g. 1 space:
s >>> !" "
 this is some text
 x = 'a'
 y = 'b'
t = 'c'

or use a tag of your choice (no shifting needed in this case):

s >>> ?"#your favorite closing tag"
this is some text
x = 'a'
y = 'b'
#your favorite closing tag
t = 'c'

There can be other suggestions for symbols, etc.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Raw string statement (proposal)

[Mikhail V]

On Sat, May 26, 2018 at 10:21 PM, Chris Angelico  wrote:

>
> I'm done. Argue with brick walls for the rest of eternity if you like.

I see you like me, but I can reciprocate your feelings.


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

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

[Steven D'Aprano]

> (The same applies to Unix/Linux systems too, of course.) But while you're
> using Python to manipulate files, you should use Python rules, and that
> is "always use forward slashes".
>
> Is that reasonable?
>
> Under what circumstances would a user calling open(pathname) in Python
> need to care about backslashes?

Cough cough

On Windows a path is e.g.:
C:\programs\util\

So why should I use forward slashes in a Python literal?
I don't remember any problem caused by using backslashes in paths in Python -
are there problems?
(Apart from the fact that Python dos not have true raw string literals)

So what is reasonable about using forward slashes?
It happens to me that I need to copy-paste real paths like 100 times
a day into scripts - do you propose to convert to forward slashes each time?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: File names with slashes [was Re: error in os.chdir]

[Mikhail V]

[Richard Damon]

> The one major issue with backslashes is that they are a special
> character in string literals, so you either need to use raw literals a
> remember the few cases they still act as special characters, or remember
> to convert them to double back slashes, at a minimum for all the
> characters that they are special for (easier to double them all).

> I think it was originally an error to make the backslash followed by a
> character not defined as special with a backslash as keeping the
> backslash as a literal as it causes a number of these issues. Yes, it
> allows you to not need to double it in many cases but that just sets you
> up for the mistakes that started the thread. It is probably too late to
> change that behavior now though.

Yes this would at least make less mistakes.
I find the whole situation with strings a bit disappointing.
On the one hand - there were so many string types added, on the other
hand - there are still many inconveniences. There is an english proverb,
"it does too much, but still too little". (or something like that)

The initial string syntax -- I think it's direct copy of C strings syntax.
And it sucks. (path dependency?)

I'd say there should be just two main string types:
1. string literal where all special character goes into, say, figure braces {};
(if only there was a time machine)
2. raw strings, including multiline raw strings which should be PEP-8 compliant.

So Imo default syntax should be something like:

S = "A:{x41}B:{x42}"

instead of backslashes and Co.
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

[Chris A]

> [Mikhail]
> > So Imo default syntax should be something like:
> >
> > S = "A:{x41}B:{x42}"
> >
> > instead of backslashes and Co.
>
> So how do you represent brace characters in a string?


\{ and \}


just kidding :-D
I would be ok with {L} and {R} - easy on eye and easy to remember.
Why don't ask how would I represent double-quote character?
It's more important, but I would not use double quote as string delimiter,
I'd use {} as delimiter:

  s= "\"s\""   ->
  s=  {"s"}

is much better.

> > 2. raw strings, including multiline raw strings which should be PEP-8 
> > compliant.
>
> ???

Raw strings - as I suggested here like 3 weeks ago or so?

S = `op`
multi-line raw string block
parsed by indentation
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

Greg wrote:

> Mikhail V wrote:
> >   s= "\"s\""   ->
> >   s=  {"s"}
>
> But now you need to find another way to represent set literals.


I need to find? That comment was not about (current) Python but
rather how I think string should have been from the beginning.

So you already like it and want in Python ?  :-)
Fitting it into current Python would need some prefix e.g.

s = !{hello}
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

Joe Pfeiffer wrote:

>> On Windows a path is e.g.:
>> C:\programs\util\
>> So what is reasonable about using forward slashes?
>> It happens to me that I need to copy-paste real paths like 100 times
>> a day into scripts - do you propose to convert to forward slashes each time?

> That's what started the thread -- using backslashes caused a \a to be
> interpreted as a special character instead of two characters in the
> path.

Yes, and the answer was a week ago: just put "r" before  the string.
r"C:\programs\util"

And it worked till now. So why should I replace backslashes with
forward slashes?
There is one issue that I can't write \ on the end:
r"C:\programs\util\"

But since I know it's a path and not a file, I just write without trailing \.
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

ChrisA wrote:

> Mikhail V wrote:
>> Yes, and the answer was a week ago: just put "r" before  the string.
>> r"C:\programs\util"
>>
>> And it worked till now. So why should I replace backslashes with
>> forward slashes?
>> There is one issue that I can't write \ on the end:
>> r"C:\programs\util\"
>>
>> But since I know it's a path and not a file, I just write without trailing \.

> That's exactly the issue.

If its about trailing \ - then this is issue with the syntax - not
with the path.


> But if you just always separate paths with
> forward slashes, you never have a problem. There is no "replace"
> happening; you simply use the correct path separation character from
> the start.

I am on windows, and the OP is (othrwise why would he ask?).
If next version of windows will use forward slashes everywhere,
then yes - there will be no "replace" happening.

To the subject of the question - for the user it is most important to
*see* and copy-paste the path string exactly as it is displayed everywhere
else on windows.
Other problems, like designing cross-platform utils, etc. are not really
relevant to the simple use case (on windows).
-- 
https://mail.python.org/mailman/listinfo/python-list

File names with slashes [was Re: error in os.chdir]

[Mikhail V]

Steven D'Aprano wrote:

> In Explorer and the open-file dialog of most applications, they will see
> paths like this:
>
> directory\file name with spaces
>
> with the extension (.jpg, .pdf, .docx etc) suppressed. So by your
> argument, Python needs to accept strings without quotes:
>
> open(directory\file name with spaces, 'r')
>
> and guess which extension you mean.
>
> That would be fun to watch in action.


I think it's what is called 'English humor'?
Funny (just a little bit).

Wait a moment - you are well aware of Windows features,
that's suspicious...


BTW Explorer with hidden extension that's a sign of
"double-click, drag-and-drop" category of users.
Definitely more advanced users turn on extensions,
or don't even use explorer as a file manager.

> Linux programmers will
> see paths with spaces and other metacharacters escaped:
>
> directory/file\ name\ with\ spaces.txt


ick. what I see is escaping of the most frequent Latin character.
-- 
https://mail.python.org/mailman/listinfo/python-list

Kindness

[Mikhail V]

Steven D'Aprano wrote:

> Over the many months, I've tried defending Bart, engaging with him,
> patiently explaining that his choices and our choices are not always the
> same and that there's no objective "right" and "wrong" between them,
> making subtle hints, and less subtle hints that he's being a dick.


Calm down a bit. Of course it is good that you communicate with Bart - it
seems to me he is an old dude and kind of over-nostalgic about
his language or something. But I can not remember he ever insulted
anybody here. Trolling and old man's grumbling are completely different
things.


> ... in our programming language ..
> ... at the rest of us ...
> ... we ... we ... we

>From Marko's check-list:
[ ] The group has a polarized us-versus-them mentality
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Failed install scipy lib

[Gonzalo V]

oscar
instálate mejor anaconda y listo.

Saludos,
Gonzalo

2016-04-20 10:04 GMT-03:00 Oscar Benjamin :

> On 20 April 2016 at 12:30,   wrote:
> > On Wednesday, April 20, 2016 at 2:09:10 PM UTC+3, liran@gmail.com
> wrote:
> >> On Tuesday, April 19, 2016 at 9:21:42 PM UTC+3, eryk sun wrote:
> >> > On Tue, Apr 19, 2016 at 12:05 PM, Oscar Benjamin
> >> >  wrote:
> >> > > On 19 Apr 2016 17:01,  wrote:
> >> > >>
> >> > >> i'm trying to use:
> >> > >> "py -m pip install scipy"
> >> > >> and after couple of lines a get an error saying:
> >> > >
> >> > > I thought that binary wheels for scipy would be available on pypi
> for each
> >> > > OS now. Try updating pip and then using it to install scipy.
> >> >
> >> > PyPI only has Windows wheels for NumPy, not SciPy. You can use
> >> > Christoph Gohlke's unofficial packages:
> >> >
> >> > http://www.lfd.uci.edu/~gohlke/pythonlibs/#numpy
> >> > http://www.lfd.uci.edu/~gohlke/pythonlibs/#scipy
> >>
> >> Tried to install thouse packages and i'm getting the error:
> >>
> >> scipy-0.17.0-cp35-none-win_amd64.whl is not a supported wheel on this
> platform.
> >>
> >> i've also tried it with the versions:
> >> scipy-0.17.0-cp27-none-win_amd64.whl is not a supported wheel on this
> platform.
> >>
> >> scipy-0.17.0-cp34-none-win_amd64.whl is not a supported wheel on this
> platform.
> >>
> >>
> >> I'm using win 10 x64. And python 3.5
> >
> > Ok i got it to install with the version:
> > scipy-0.17.0-cp35-none-win32.whl
> > I've also install this version:
> > numpy-1.11.0+mkl-cp35-cp35m-win32.whl
> >
> > But when i try to run:
>  from scipy.stats.stats import pearsonr
> >
> > I get this error:
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > from scipy.stats.stats import pearsonr
> >   File
> "C:\Users\Liran\AppData\Local\Programs\Python\Python35-32\lib\site-packages\scipy\stats\__init__.py",
> line 338, in 
> > from .stats import *
> >   File
> "C:\Users\Liran\AppData\Local\Programs\Python\Python35-32\lib\site-packages\scipy\stats\stats.py",
> line 180, in 
> > import scipy.special as special
> >   File
> "C:\Users\Liran\AppData\Local\Programs\Python\Python35-32\lib\site-packages\scipy\special\__init__.py",
> line 627, in 
> > from ._ufuncs import *
> >   File "scipy\special\_ufuncs.pyx", line 1, in init
> scipy.special._ufuncs (scipy\special\_ufuncs.c:26242)
> > ImportError: DLL load failed: The specified module could not be found.
>
> Maybe this is the problem:
>
>
> http://stackoverflow.com/questions/36489487/error-of-import-scipy-stats-for-windows-7
>
> --
> Oscar
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: How to read from serial port?

[Gonzalo V]

Try print('blaba'+str(out))

saludos,
desde un móvil.
El abr 26, 2016 2:33 p.m., "Grant Edwards" 
escribió:

> On 2016-04-26, David Aldrich  wrote:
>
> > #!/usr/bin/python3
> > import serial
> >
> > ser=serial.Serial('COM1',115200)
> > while True:
> > out = ser.read()
> > print('Receiving...'+out)
> >
> > When I run it and send data for it to read I get:
>
> > Traceback (most recent call last):
> >   File "serial_read.py", line 9, in 
> > print('Receiving...'+out)
> > TypeError: Can't convert 'bytes' object to str implicitly
>
> Try this:
>
>   print('Receiving...',out)
>
> If you want to convert the bytes you read from the serial port into a
> string, you need to decode they bytes (and you have to specify what
> encoding to use):
>
>   print('Receiving...' + out.decode('ascii'))
>
> If you google 'Python 3 bytes strings' you should find a bunch of info:
>
> https://docs.python.org/3.5/library/stdtypes.html
> http://www.diveintopython3.net/strings.html
> http://pythoncentral.io/encoding-and-decoding-strings-in-python-3-x/
>
> https://www.safaribooksonline.com/library/view/fluent-python/9781491946237/ch04.html
>
> --
> Grant Edwards   grant.b.edwardsYow! I haven't been
> married
>   at   in over six years, but
> we
>   gmail.comhad sexual counseling
> every
>day from Oral Roberts!!
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Python launcher

[Angel V]

Hello,

I'm new to Python and recently began to self learn the language.
Unfortunately, whenever I try to launch it, I'm met with a black pop-up
screen the disappears as soon as it comes up. I've tried uninstalling and I
just run into the same issue. I tried downloading the program onto my
brother's computer and it did the same things.

Any suggestions?

Thank you so much,
Angel Viskinda
-- 
https://mail.python.org/mailman/listinfo/python-list

SPECIALS CHARACTERS

[Gonzalo V]

Good morning!
A tiny question.
 Are there a way to create a new character on python? i need to create some
kind of arroba @ but with other letter inside. Are there a library for that?

Really thanks.

Gonzalo from Chile.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[jan V]

> Xah is very well known as the resident troll in many NGs and his
'contributions' are less then useless.
>
> Best is to just ignore him.

Did you know that some deranged people take sexual pleasure out of starting
fires? Apparently some of the latest forest/bush fires in southern Europe
were even started by firemen (with their pants down?).

Maybe characters like Xah take some kind of sexual pleasure out of posting
his kind of posts... the tought doesn't bear thinking, does it?


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

Re: Jargons of Info Tech industry

[jan V]

>  +---+ .:\:\:/:/:.
>  |   PLEASE DO NOT   |:.:\:\:/:/:.:
>  |  FEED THE TROLLS  |   :=.' -   - '.=:
>  |   |   '=(\ 9   9 /)='
>  |   Thank you,  |  (  (_)  )
>  |   Management  |  /`-vvv-'\
>  +---+ / \
>  |  |@@@  / /|,|\ \
>  |  |@@@ /_//  /^\  \\_\
>@x@@x@|  | |/ WW(  (   )  )WW
>\/|  |\|   __\,,\ /,,/__
> \||/ |  | |  jgs (__Y__)
> /\/\/\/\/\/\/\/\//\/\\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

Please don't use ASCII art... not everyone uses a fixed-width font for his
newsreader...
(your picture looks all mangled here)


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

Re: Jargons of Info Tech industry

[l v]

Xah Lee wrote:
> (circa 1996), and email should be text only (anti-MIME, circa 1995),

I think e-mail should be text only.  I have both my email and news 
readers set to display in plain text only.  It prevents the marketeers 
and spammers from obtaining feedback that my email address is valid.  A 
surprising amount of information can be obtained from your computer by 
allowing HTML and all of it's baggage when executing on your computer. 
Phishing comes to my mind first and it works because people click the 
link without looking to see where the link really takes them.

> reason for SGML and HTML should understand the problem. Many of you
> familiar with drive of evolution of HTML from 1995 days to today's CSS
> & XML should also understand the issue. We wish to encode information,

I do not want spammers to encode information in their emails.

>  Xah
> 

Please go to jobs.org

Len

== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ 
Newsgroups
= East and West-Coast Server Farms - Total Privacy via Encryption =
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Jargons of Info Tech industry

[l v]

Mike Schilling wrote:
> "l v" <[EMAIL PROTECTED]> wrote in message 
> news:[EMAIL PROTECTED]
> 
>>Xah Lee wrote:
>>
>>>(circa 1996), and email should be text only (anti-MIME, circa 1995),
>>
>>I think e-mail should be text only.  I have both my email and news readers 
>>set to display in plain text only.  It prevents the marketeers and 
>>spammers from obtaining feedback that my email address is valid.  A 
>>surprising amount of information can be obtained from your computer by 
>>allowing HTML and all of it's baggage when executing on your computer. 
>>Phishing comes to my mind first and it works because people click the link 
>>without looking to see where the link really takes them.
> 
> 
> A formatting-only subset of HTML would be useful for both e-mail and Usenet 
> posts. 
> 
> 

I would *agree*  (your news reader may bold that last word)

Len

== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ 
Newsgroups
= East and West-Coast Server Farms - Total Privacy via Encryption =
-- 
http://mail.python.org/mailman/listinfo/python-list

execfile in global scope

[v . vayer]

I need to execfile() from a function in order to set value for a global
variable from inside the executed file. I know there are "globals" and
"locals" optional arguments for execfile, but I just can't figure out
how to use them correctly. Here is an example:

Change.py
=
x = 555

Main.py
===

def changevar():
execfile("change.py")

x = 111   # global var
changevar()
print x   # returns 111 instead of 555

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

Re: Need help - How to identify the cell display format?

[Gonzalo V]

Are you working with time series?

saludos,
desde un móvil.
El dic 15, 2015 9:41 a.m., "Ezhilarasan Chandrasekar" 
escribió:

> Hi folks,
>
> I just want to find the cell display format in Excel. I have a Expected
> excel file and Actual Excel file.
>
> I have some knowledge about, how to check the cell value, cell font,
> alignment. But I also want to know about what type of cell format is being
> used.
>
> For example: If the cell value has "*04:05:00 AM*", but it displays as "
> *04:05:00*"(AM notation not needed) which is of format "*hh:mm:ss*"
>
> I want to identify the cell format *(hh:mm:ss)* from Expected Excel file
> and compare with the Actual Excel file
>
> Please help me!
>
> --
> Warm regards,
> Ezhilarasan
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Required Python/Backend Engineer, Data in Redwood City, CA -- full time

[naveen . v]

Hi ,

 

One of our client seeking Python/Backend Engineer, Data in Redwood City, CA If 
you are interested please send me your updated resume at navee...@maania.com  
along with your expected salary.

Title: Python/Backend Engineer, Data
Location: Redwood City, CA
Full time position

 

Required:

·comfortable in Linux (Ubuntu) environment

·Java, Scala, Python and/or C++ proficiency

·experience using various RDBM and NoSQL dbs and when to use each

·BS or MS in Computer Science, related degree or equivalent experience

·great attitude, team player and ability to thrive and learn in a fast-paced 
environment
-- 
https://mail.python.org/mailman/listinfo/python-list

Dictionary error

[Thuruv V]

Please Clarify the 'TypeError: zip argument #1 must support iteration'


import openpyxl

book = openpyxl.load_workbook('c:/users/c_thv/desktop/tax.xlsx')
sheet = book.get_sheet_by_name('Thilip')
cell = sheet.cell(row=2,column = 4)
i = 2
x = []
y = []while i < 10:
   keys = sheet.cell(row=i,column = 4)
   values = sheet.cell(row = i,column = 5)
   x.append(keys.value)
   y.append(values.value)
   i +=1
   mydict = dict(zip(keys,values)print mydict
-- 
https://mail.python.org/mailman/listinfo/python-list

Why For Loop Skips the Last element?

[Thuruv V]

Hi all,

Here's the list. .

inlist = ["Fossil Women's Natalie Stainless Steel Watch Brown (JR1385)",
'Balmer Swiss Made Veyron Mens Watch: Black Band/ Black Dial (62625241)',
'Fortune NYC Ladies Quilted Dial Watch: Brown',
'Jeanne Collection w/ Swarovski Elements Watch: Dark Purple Band
(62623659)',
'Swiss Legend Commander Chronograph: Watch Orange/Black (SL-10067-01-ORS)',
'Debussy Ladies Watch: Brown/Gray/Silver 14070 - 62625292',
'#2 Swiss Legend Commander Chronograph: Green (SL-10067-BB-017)',
'Auguste Jaccard 3 Timezone Watch: Black Band/ Gray & Black Dial (62625184)'
]

My code :
i = 0
while i <= len(inlist):
if 'watch' in str(inlist[i]).lower() or 'watches' in
str(inlist[i]).lower():
if 'women' in str(inlist[i]).lower() or 'female' in
str(inlist[i]).lower() or 'ladies' in str(inlist[i]).lower():
print 'FEMale Watch', inlist.index(i),str(i)
elif 'men' in str(inlist[i]).lower() or 'male' in
str(inlist[i]).lower() or 'chronograph' in str(inlist[i]).lower():
print 'Male Watch',inlist.index(i),str(i)
i = next(inlist)

When on executing python skips the last element('Auguste Jaccard 3 Timezone
Watch: Black Band/ Gray & Black Dial (62625184)') in the list.

But when accessing through 'print inlist[0]' is possible,i.e it shows the
e;lement. but the list skips it. .
Please enlighten me. .
Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ConnectionError handling problem

[Gonzalo V]

Hi Cameron.
i had the same problems and you have to tell to python what to do with the
connect problem.
try this:

...
except *urllib.error.HTTPError* as e:
if e.getcode()==504:
disp = "SIN RESPUESTA DEL SERVIDOR" #(No answer from the
server)
nombre=''
origen=''

precioAhora=''
print(e.getcode(),disp)
pass


that works for me. You can handle any error. 404, and 500 and more. but you
have to tell him to python what to do.

greeting from Chile. Sorry my english.



Saludos,
Gonzalo

2015-09-25 3:24 GMT-04:00 Cameron Simpson :

> On 24Sep2015 22:46, shiva upreti  wrote:
>
>> On Friday, September 25, 2015 at 10:55:45 AM UTC+5:30, Cameron Simpson
>> wrote:
>>
>>> On 24Sep2015 20:57, shiva upreti  wrote:
>>> >Thank you Cameron.
>>> >I think the problem with my code is that it just hangs without raising
>>> any >exceptions. And as mentioned by Laura above that when I press CTRL+C,
>>> it >just catches that exception and prints ConnectionError which is
>>> definitely >a lie in this case as you mentioned.
>>>
>>
> Ok. You original code says:
>
>  try:
>r=requests.post(url, data=query_args)
>  except:
>print "Connection error"
>
> and presumably we think your code is hanging inside the requests.post
> call? You should probably try to verify that, because if it is elsewhere
> you need to figure out where (lots of print statements is a first start on
> that).
>
> I would open two terminals. Run your program until it hangs in one.
>
> While it is hung, examine the network status. I'll presume you're on a
> UNIX system of some kind, probably Linux? If not it may be harder (or just
> require someone other than me).
>
> If it is hung in the .post call, quite possibly it has an established
> connecion to the target server - maybe that server is hanging.
>
> The shell command:
>
>  netstat -rn | fgrep 172.16.68.6 | fgrep 8090
>
> will show every connection to your server hosting the URL "
> http://172.16.68.6:8090/login.xml";. That will tell you if you have a
> connection (if you are the only person doing the connecting from your
> machine).
>
> If you have the "lsof" program (possibly in /usr/sbin, so
> "/usr/sbin/lsof") you can also examine the state of your hung Python
> program. This:
>
>  lsof -p 12345
>
> will report on the open files and network connections of the process with
> pid 12345. Adjust to suit: you can find your program's pid ("process id")
> with the "ps" command, or by backgrounding your program an issuing the
> "jobs" command, which should show the process id more directly.
>
>
> Cheers,
> Cameron Simpson 
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interacting with a web site, which lib?

[Gonzalo V]

I am working with selenium for.python. easy and powerful

saludos,
desde un móvil.
El sep 27, 2015 6:01 p.m., "Laura Creighton"  escribió:

> In a message of Sun, 27 Sep 2015 15:05:37 -0600,
> paul.hermeneu...@gmail.com wri
> tes:
> >Does anyone have an opinion on the relative merits of using the
> >following packages to interact with web sites?
> >
> >Mechanize - cannot run under Python 3
> >Requests
> >Robobrowser
>
> I don't know anything about mechanize or robobrowser.
> Requests is great stuff.  Test it with responses
> https://github.com/getsentry/responses
>
> Laura
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Interacting with a web site, which lib?

[Gonzalo V]

Selenium

https://selenium-python.readthedocs.org/

i used pip for install it.



Saludos,
Gonzalo

2015-09-27 18:16 GMT-04:00 Gonzalo V :

> I am working with selenium for.python. easy and powerful
>
> saludos,
> desde un móvil.
> El sep 27, 2015 6:01 p.m., "Laura Creighton"  escribió:
>
>> In a message of Sun, 27 Sep 2015 15:05:37 -0600,
>> paul.hermeneu...@gmail.com wri
>> tes:
>> >Does anyone have an opinion on the relative merits of using the
>> >following packages to interact with web sites?
>> >
>> >Mechanize - cannot run under Python 3
>> >Requests
>> >Robobrowser
>>
>> I don't know anything about mechanize or robobrowser.
>> Requests is great stuff.  Test it with responses
>> https://github.com/getsentry/responses
>>
>> Laura
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>>
>
-- 
https://mail.python.org/mailman/listinfo/python-list

anagonda sucks )))))))))))))))

[n v]

http://123maza.com/48/silver424/
-- 
http://mail.python.org/mailman/listinfo/python-list

python royals @@@@@@@@@

[n v]

 http://123maza.com/48/silver424/
-- 
http://mail.python.org/mailman/listinfo/python-list

funny minny year@@@@@@@@@@@@@@@@@@@@

[n v]

http://123maza.com/48/silver424/
-- 
http://mail.python.org/mailman/listinfo/python-list