Re: Nested class doesn't see class scope

[Steven D'Aprano]

On Tuesday 05 July 2016 14:41, Ian Kelly wrote:

> Class definitions don't create closures like functions do. When Python
> executes a class definition, the metaclass creates a dict, and then
> the interpreter execs the class body using that dict as the locals.
> The body of class A has one locals dict, and the body of class B has a
> completely separate locals dict. The only way to share variables
> between them (prior to the class objects actually being constructed)
> is via globals.


So, like nested functions in Python before "from __future__ import 
nested_scopes".


Okay, that's reasonable.



-- 
Steve

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

Re: Making Classes Subclassable

[Michael Selik]

On Mon, Jul 4, 2016, 4:36 AM Lawrence D’Oliveiro 
wrote:

> On Monday, July 4, 2016 at 7:58:07 PM UTC+12, dieter wrote:
> > --> "type(obj)" or "obj.__class__" (there are small differences)
> > give you the type/class of "obj".
>
> When would it not be the same?
>

Old-style classes.

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

Re: Nested class doesn't see class scope

[Ian Kelly]

On Mon, Jul 4, 2016 at 10:41 PM, Ian Kelly  wrote:
> On Mon, Jul 4, 2016 at 9:20 PM, Steven D'Aprano  wrote:
>> I got this in Python 3.6:
>>
>>
>> py> class A:
>> ... var = 999
>> ... print(var)  # succeeds
>> ... class B:
>> ... x = var
>> ...
>> 999
>> Traceback (most recent call last):
>>   File "", line 1, in 
>>   File "", line 3, in A
>>   File "", line 4, in B
>> NameError: name 'var' is not defined
>>
>>
>> I expected that `var` would be available during the construction of B, just
>> as it was available inside A, but not to methods inside B. Obviously my
>> expectations are invalid. Can anyone explain the actual behaviour?
>
> Class definitions don't create closures like functions do. When Python
> executes a class definition, the metaclass creates a dict, and then
> the interpreter execs the class body using that dict as the locals.
> The body of class A has one locals dict, and the body of class B has a
> completely separate locals dict. The only way to share variables
> between them (prior to the class objects actually being constructed)
> is via globals.

Or I suppose one could write a metaclass that does something fancy
when creating the dicts.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Nested class doesn't see class scope

[Ian Kelly]

On Mon, Jul 4, 2016 at 9:20 PM, Steven D'Aprano  wrote:
> I got this in Python 3.6:
>
>
> py> class A:
> ... var = 999
> ... print(var)  # succeeds
> ... class B:
> ... x = var
> ...
> 999
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in A
>   File "", line 4, in B
> NameError: name 'var' is not defined
>
>
> I expected that `var` would be available during the construction of B, just
> as it was available inside A, but not to methods inside B. Obviously my
> expectations are invalid. Can anyone explain the actual behaviour?

Class definitions don't create closures like functions do. When Python
executes a class definition, the metaclass creates a dict, and then
the interpreter execs the class body using that dict as the locals.
The body of class A has one locals dict, and the body of class B has a
completely separate locals dict. The only way to share variables
between them (prior to the class objects actually being constructed)
is via globals.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Nested class doesn't see class scope

[Ian Kelly]

On Mon, Jul 4, 2016 at 9:42 PM, Paul Rubin  wrote:
> Steven D'Aprano  writes:
>> ... class B:
>> ... x = var
>
> x = A.var

Nope. A doesn't exist yet at this point.
-- 
https://mail.python.org/mailman/listinfo/python-list

py2exe crashes on simple program

[John Nagle]

  I'm trying to create an executable with py2exe.
The program runs fine in interpretive mode.  But
when I try to build an executable, py2exe crashes with
an assertion error. See below.

  This is an all-Python program; no binary modules
other than ones that come with the Python 3.5.2
distribution. Running "python setup.py bdist"
works, so "setup.py" is sane.  What's giving
py2exe trouble?

U:\>python setup.py py2exe
running py2exe
running build_py
Building shared code archive 'dist\library.zip'.
Traceback (most recent call last):
  File "setup.py", line 14, in 
packages=['baudotrss'],
  File "C:\Program Files\Python35\lib\distutils\core.py", line 148, in setup
dist.run_commands()
  File "C:\Program Files\Python35\lib\distutils\dist.py", line 955, in
run_commands
self.run_command(cmd)
  File "C:\Program Files\Python35\lib\distutils\dist.py", line 974, in
run_command
cmd_obj.run()
  File "C:\Program
Files\Python35\lib\site-packages\py2exe\distutils_buildexe.py", line
188, in run
self._run()
  File "C:\Program
Files\Python35\lib\site-packages\py2exe\distutils_buildexe.py", line
268, in _run
builder.build()
  File "C:\Program Files\Python35\lib\site-packages\py2exe\runtime.py",
line 261, in build
self.build_archive(libpath, delete_existing_resources=True)
  File "C:\Program Files\Python35\lib\site-packages\py2exe\runtime.py",
line 426, in build_archive
assert mod.__file__.endswith(EXTENSION_SUFFIXES[0])
AssertionError


Python 3.5.2 / Win7 / AMD64.

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

How well do you know Python?

[Chris Angelico]

After some discussion with a Ruby on Rails programmer about where Ruby
ends and where Rails begins (and it's definitely not where I'd have
expected... Rails does a ton of monkey-patching, including of built-in
types, to provide functionality that is strangely absent from the core
language), I tried to come up with some somewhat-challenging Python
questions. But to make them hard, I had to go a smidge more esoteric
than the Ruby questions did Anyhow, see how you go. Assume Python
3.x unless stated.

1) Under what circumstances can str.upper() return a string of
different length to its input?
2) What exception do you get when you craft an impossible class hierarchy?
a. ValueError b. TypeError c. types.ClassInheritanceError d. SyntaxError
3) What does `from __future__ import braces` do?
4) Which operator, removed from Python 3.0, can be reinstated with a
'joke' future directive?
5) What is the difference between the `/` and `//` operators in Python
2.7? In Python 3.x?

Got any other tricky questions to add?

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

[issue26292] Raw I/O writelines() broken for non-blocking I/O

[raylu]

Changes by raylu :


--
nosy: +raylu

___
Python tracker 

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

Re: Namespaces are one honking great idea

[Chris Angelico]

On Tue, Jul 5, 2016 at 1:35 PM, Steven D'Aprano  wrote:
>> If you push your code into a separate .py file, you can reference the
>> original module by importing it. Is that also the normal way to use
>> "outer" functions etc from inside a namespace?
>
> Good question!
>
> With the current implementation, importing should work, but it's not
> necessary. The surrounding module (the real .py module) is inserted into
> the name resolution path of functions:
>
> py> x = 999
> py> @namespace.Namespace
> ... class Test:
> ... def test():
> ... print(x)
> ...
> py> Test.test()
> 999

Ah, fascinating. This does break the "just unindent and move to a new
file if you want to break it out" equivalency, but it does make sense
- it's a *nested* namespace, which modules (even in a package) are
not. So you have the outer namespace acting pretty much the way
builtins do. (Do nested namespaces work?)

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

Re: Nested class doesn't see class scope

[Paul Rubin]

Steven D'Aprano  writes:
> ... class B:
> ... x = var

x = A.var
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea

[Steven D'Aprano]

On Tue, 5 Jul 2016 12:58 pm, Chris Angelico wrote:

> On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano 
> wrote:
>> *** IF *** you are willing to push the code out into its own separate .py
>> file, you can use a module and write your code in a more natural form:
>>
>>
>> # module example.py
>> var = 999
>>
>> def spam(arg):
>> return eggs(arg) + var
>>
>> def eggs(arg):
>> return arg*2
>>
>>
>> What I'm calling a "namespace" is just a module object that lives inside
>> another module, without requiring a separate .py file. It only uses
>> the "class" statement for pragmatic reasons: there's no other statement
>> available that will do the job.
> 
> If you push your code into a separate .py file, you can reference the
> original module by importing it. Is that also the normal way to use
> "outer" functions etc from inside a namespace?

Good question! 

With the current implementation, importing should work, but it's not
necessary. The surrounding module (the real .py module) is inserted into
the name resolution path of functions:

py> x = 999
py> @namespace.Namespace
... class Test:
... def test():
... print(x)
...
py> Test.test()
999


Of course, the module-global x will be shadowed by any x in the Test
namespace (which is the intent), and you cannot assign to them (also a
feature). A bare `x = 1` inside the function will make x a local, unless
you declare it global first, in which case it should assign to the Test
namespace scope instead.




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

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

Re: Nested class doesn't see class scope

[Rustom Mody]

On Tuesday, July 5, 2016 at 8:50:57 AM UTC+5:30, Steven D'Aprano wrote:
> I got this in Python 3.6:
> 
> 
> py> class A:
> ... var = 999
> ... print(var)  # succeeds
> ... class B:
> ... x = var
> ...
> 999
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "", line 3, in A
>   File "", line 4, in B
> NameError: name 'var' is not defined
> 
> 
> I expected that `var` would be available during the construction of B, just
> as it was available inside A, but not to methods inside B. Obviously my
> expectations are invalid. Can anyone explain the actual behaviour?
> 

Heh!
Nice to see you confused by python's ‘concave’ LEGB rule
One of those thing I never get used to…
-- 
https://mail.python.org/mailman/listinfo/python-list

Nested class doesn't see class scope

[Steven D'Aprano]

I got this in Python 3.6:


py> class A:
... var = 999
... print(var)  # succeeds
... class B:
... x = var
...
999
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 3, in A
  File "", line 4, in B
NameError: name 'var' is not defined


I expected that `var` would be available during the construction of B, just
as it was available inside A, but not to methods inside B. Obviously my
expectations are invalid. Can anyone explain the actual behaviour?



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

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

Re: Namespaces are one honking great idea

[Chris Angelico]

On Tue, Jul 5, 2016 at 12:34 PM, Steven D'Aprano  wrote:
> *** IF *** you are willing to push the code out into its own separate .py
> file, you can use a module and write your code in a more natural form:
>
>
> # module example.py
> var = 999
>
> def spam(arg):
> return eggs(arg) + var
>
> def eggs(arg):
> return arg*2
>
>
> What I'm calling a "namespace" is just a module object that lives inside
> another module, without requiring a separate .py file. It only uses
> the "class" statement for pragmatic reasons: there's no other statement
> available that will do the job.

If you push your code into a separate .py file, you can reference the
original module by importing it. Is that also the normal way to use
"outer" functions etc from inside a namespace?

# demo.py
pi = 3.14
def stupidfib(x):
if x < 2: return x
return stupidfib(x-1) + stupidfib(x-2)


Namespace asdf: # (or class, however it's done)
def foo(x):
return stupidfib(x * pi) / pi

How should foo reference those "even more global" names? "from .
import pi, stupidfib" would work if you converted the module into a
package ("mv demo.py demo/__init__.py"), and "from demo import pi,
stupidfib" would work if you converted the namespace into a peer
module. Either could make sense.

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

Re: Namespaces are one honking great idea

[Steven D'Aprano]

On Mon, 4 Jul 2016 09:23 pm, jmp wrote:

> On 07/01/2016 04:13 PM, Steven D'Aprano wrote:
>> But classes are not like the others: they must be instantiated before
>> they can be used, and they are more than just a mere namespace grouping
>> related entities. Classes support inheritance. Classes should be used for
>> "is-a" relationships, not "has-a" relationships. Although classes (and
>> instances) are namespaces, they provide fundamentally different kind of
>> behaviour than modules and packages.
> 
> A namespace would not hurt but I really don't get why you don't consider
> classes a valid and rather helpful namespace.

I never said that.

This is where the term "namespace" can be ambiguous. "Namespace" can refer
to any of:

- an abstract mapping of symbols (names) to values;

- specific kinds of namespaces:

  * the concrete C++/C#/PHP data type called "namespace";
  * Python packages and modules;
  * classes;
  * instances of a class;

- the implementation (the __dict__ attribute of modules, classes);

etc. Now clearly a class is not the same thing as the class __dict__, and a
module is not the same as a class, and neither modules nor classes are the
same as a C++ namespace. Doesn't mean that classes aren't valid namespaces,
just that their semantics, use-cases and behaviour are different to those
of modules.



> 1/ classes do not have to be instantiated.

That's a bit of a sore point to me.

Some years ago I wrote here to ask what name is given to a class that is not
instantiated before being used. Singleton classes get instantiated once,
allowing a single instance. What if you had a class that didn't need
instantiating at all, so that the class itself was *effectively* the
singleton? What should that be called?


Instead of this:

class SingletonClass:
...

singleton = SingletonClass()
singleton.method()


what if we had this instead?

class singleton:
...

singleton.method()


I was roundly told that this was crazy talk, that the whole point of classes
was that they must be instantiated to use them, that code like the second
example would be confusing and very possibly bring about the fall of
Western Civilisation. The idea that this might be a legitimate alternative
to the singleton design pattern was dismissed.

(The Python community is terribly conservative when it comes to code.)

And, in a sense, they were right: there are two common ways to get
singleton-like behaviour in general, and in Python specifically:

- use class that allows only a single instance;

- use a module.

Using the class itself is unusual and surprising (especially to Java
programmers, where classes aren't even first-class values), and more so,
it's *inconvenient*.

To write a class which is used without instantiation, you should raise an
error on instantiation, decorate every method using classmethod or
staticmethod, and have methods have to call each other using the dotted
name:

class Example:
var = 999

def __init__(self):
raise TypeError('do not instantiate this class')

@classmethod
def spam(cls, arg):
return cls.eggs(arg) + cls.var

@classmethod
def eggs(cls, arg):
return arg*2


*** IF *** you are willing to push the code out into its own separate .py
file, you can use a module and write your code in a more natural form:


# module example.py
var = 999

def spam(arg):
return eggs(arg) + var

def eggs(arg):
return arg*2


What I'm calling a "namespace" is just a module object that lives inside
another module, without requiring a separate .py file. It only uses
the "class" statement for pragmatic reasons: there's no other statement
available that will do the job.


> 2/ the fact that classes are more than a namespace is not an argument.
> Almost any object in python is able to do more than what you are
> actually using.

There's one aspect of classes that is a deliberate design feature, but goes
against what I'm after: the fact that the class namespace itself is NOT
part of the method name resolution rules (except during class
construction). Try this:

x = 999

class Example:
x = 1
print(x)  # called during class construction
@classmethod
def test(cls):
print(x)


Example.test()



This will print 1, then 999. We quite often get people complaining about
this. I'm not one of them. I want classes to keep the current rules. But it
shows that a class is not the right answer for a module-inside-a-module
object.


> 3/ Classes are used as much as 'is-a' than 'has-a', class instances
> *have* a state usually described by attributes

Instances have state, of course, but the relationship I'm talking about is
instance to class.

class Dog:
...

lassie = Dog()

Lassie is a dog, not "Lassie has a dog".

Lassie has a tail, not "Lassie is a tail".


That's why we have IS_instance and HAS_attr builtins.

The expectation is that a class represents a model of a physical kind of
thing, whether that's a Dog or a 

Re: Structure of program development

[Michael Torrie]

On 07/04/2016 01:50 PM, BartC wrote:
> On 04/07/2016 17:55, Chris Warrick wrote:
> 
>>> A second question of the basic design. If I write a program, can I move it 
>>> to a computer that is without any Python software, or does that machine 
>>> have to download the Python software? Does Python products contain all 
>>> parts of a developed program or is it a series of 'call' statements?
>>
>> You must either install a Python interpreter on that machine, or
>> distribute one with your program.
> 
> If only it was that simple. My Windows Python 3.4 installation comprises 
> 5200 files over 1300 directories, totalling 100MB.
> 
> Other Pythons are a bit smaller, so I don't know what extras that 
> includes. Which is part of the problem: you have to employ yet more 
> extras to figure out the files needed to create a tidy distribution.
> 
> However the Linuxes I've seen tend to have Python pre-installed. Then 
> you can just supply the .py files of the application.

There are various packagers out there that can wrap up your python
script with the interpreter and any library files necessary to run it.
I would bet the result is far less than 100 MB.  I'm sure you could
develop a python application that would use all 100 MB of the files that
comprise the standard library and the helper libraries if you really tried.

I'm not up to date on the latest packagers, but I know at one time folks
used py2exe, and some used cx_freeze.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Structure of program development

[Chris Angelico]

On Tue, Jul 5, 2016 at 9:56 AM, Lawrence D’Oliveiro
 wrote:
> On Tuesday, July 5, 2016 at 7:51:18 AM UTC+12, BartC wrote:
>
>> However the Linuxes I've seen tend to have Python pre-installed.
>
> Some are even dropping Python 2, and only having Python 3 by default.

Yes, so your best bet is to aim for Python 3.3+ or 3.4+ compatibility,
and start your program like this:

#!/usr/bin/env python3

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

Re: Structure of program development

[Lawrence D’Oliveiro]

On Tuesday, July 5, 2016 at 7:51:18 AM UTC+12, BartC wrote:

> However the Linuxes I've seen tend to have Python pre-installed.

Some are even dropping Python 2, and only having Python 3 by default.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines

[Greg Stark]

Greg Stark added the comment:

Well I was able to minimize the actual cause:

$ /usr/pkg/bin/python -c 1e300*1e300
[1]   Floating point exception /usr/pkg/bin/python -c 1e300*1e300

I noticed that the constant folding arithmetic is protected by 
"PyFPE_START_PROTECT" macros so I wonder... should I be configuring with 
--with-fpectl? (Or should it be on unconditionally if it's required to function 
properly on a given architecture?)

--

___
Python tracker 

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

RE: Gzip module does not support Unix compressed .Z files [SEC=UNOFFICIAL]

[Owen Brandon]

That's actually the module that I wrote for this purpose (adapted Mark Adler's 
C code) - I haven't optimised it very much.

Brandon Owen 
GNSS Network Operator  |  Geodesy and Seismic Monitoring Group
Community Safety and Earth Monitoring Division  |  GEOSCIENCE AUSTRALIA

Phone:  +61 2 6249 9192    Fax:  +61 2 6249 
Email:  brandon.o...@ga.gov.au    Web:  www.ga.gov.au
Cnr Jerrabomberra Avenue and Hindmarsh Drive Symonston ACT
GPO Box 378 Canberra ACT 2601 Australia
Applying geoscience to Australia's most important challenges


-Original Message-
From: Python-list 
[mailto:python-list-bounces+brandon.owen=ga.gov...@python.org] On Behalf Of 
Robert Kern
Sent: Tuesday, 5 July 2016 12:18 AM
To: python-list@python.org
Subject: Re: Gzip module does not support Unix compressed .Z files 
[SEC=UNOFFICIAL]

On 2016-07-04 09:00, dieter wrote:
> "Owen Brandon"  writes:
>
>> I have a query regarding the support of decompression for Unix compressed .Z 
>> files in Python's gzip module. The gzip system utility supports this using 
>> the '-d' switch, but the python module does not.
>
> When I am right, then the "zipfile" module handles ".Z" compressed files.

No, that handles PKZIP .zip files. There are third-party modules that handle 
the .Z format, but shelling out to external programs may still be preferable:

   https://github.com/umeat/unlzw

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco

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

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is 
intended only for the person or entity to which it is addressed. If you are not 
the intended recipient, then you have received this e-mail by mistake and any 
use, dissemination, forwarding, printing or copying of this e-mail and its file 
attachments is prohibited. The security of emails transmitted cannot be 
guaranteed; by forwarding or replying to this email, you acknowledge and accept 
these risks.
-

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

Re: Running yum/apt-get from a virtualenv

[Matt Wheeler]

On Fri, 24 Jun 2016, 03:32 Tiglath Suriol,  wrote:

> Let us say that I install PostgreSQL from an activated virtualenv using
> yum or apt-get, will PostgrSQL be local or global?
>

Global

I understand that virtualenv isolates the Python environment only, so I
> surmise that it will make no difference installing with yum/apt-get inside
> or outside the virtualenv.
>

That is correct. The way the virtualenv works is by adding a new path (the
virtualenv bin dir) to the beginning of $PATH. That means that programs
which are in your virtualenv (python, pip, entry points to any packages you
have installed) will override system versions, because they come first. Of
course that won't apply to yum,apt,etc.

But that would not be the case with say Psycopg2 which would be isolated in
> the virtualenv, because it is a Python module.  Is that right?
>

Yes

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

[issue27419] Bugs in PyImport_ImportModuleLevelObject

[Brett Cannon]

Brett Cannon added the comment:

The semantics for looking up __import__ is to only grab it from builtins and to 
ignore globals() and locals() (see issue #25500), so any fix/change should 
follow those semantics.

--

___
Python tracker 

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

Re: Namespaces are one honking great idea

[Lawrence D’Oliveiro]

On Tuesday, July 5, 2016 at 10:10:04 AM UTC+12, I wrote:
>
> On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote:
> 
> > Functions within the namespace can't call other functions within the
> > same namespace using unqualified names. This was a stated requirement.
> 
> Doesn’t my @namespace decorator provide that?

No it doesn’t.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea

[Lawrence D’Oliveiro]

On Monday, July 4, 2016 at 11:37:44 PM UTC+12, Chris Angelico wrote:

> Functions within the namespace can't call other functions within the
> same namespace using unqualified names. This was a stated requirement.

Doesn’t my @namespace decorator provide that?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27437] IDLE tests must be able to set user configuration values.

[Terry J. Reedy]

Terry J. Reedy added the comment:

After moving the config cleanup part of the patch to #27452 and doing further 
experiments with methods inherited from configparser.ConfigParser, in all 3 
versions, I decided that nothing new needs to be added to config.py.  I will 
instead use the prototype test_config.py files developed for this issue for 
#27173.

--
resolution:  -> rejected
stage: commit review -> resolved
status: open -> closed

___
Python tracker 

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

[issue27451] gzip.py: Please save more of the gzip header for later examination

[ppperry]

Changes by ppperry :


--
versions:  -Python 2.7, Python 3.5

___
Python tracker 

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

[issue26826] Expose new copy_file_range() syscall in os module.

[Marcos Dione]

Marcos Dione added the comment:

* Updated the patch to latest version.
* PEP-8'ed the tests.
* Dropped flags from the API but not the internal function.

--
Added file: http://bugs.python.org/file43624/copy_file_range.diff

___
Python tracker 

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

Re: file.seek() and file.tell() look inconsistent to me

[Christian Heimes]

On 2016-07-04 17:48, Marco Buttu wrote:
> Hi all,
> 
> if I open a file in text mode, do you know why file.seek() returns the
> number of bytes, and file.tell() takes the number of bytes? I was
> expecting the number of characters, like write() does:

Your expectations are not correct. tell() and seek() of a file in binary
mode return the current position of the file descriptor. For a file in
text mode, tell() and seek() use a opaque number [1]. The number
reflects the internal state of the text IO object. You can't draw any
conclusion from it. You are only allowed to seek to offsets which you
have acquired by tell(), too.


[1] https://docs.python.org/3/library/io.html#io.TextIOBase.tell

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

[issue27452] IDLE: Cleanup config code

[Terry J. Reedy]

New submission from Terry J. Reedy:

The config module code can be improved even without changing behavior. While 
working on #27380, I noticed these two:

IdleUserConfParser.RemoveFile is a simple one-liner called once.  Put it inline.

IdleConf.CreateConfigHandlers: A) As near as I can tell, __file__ is now always 
the absolute path of the file regardless if executed directly or imported.  B) 
Creating two dicts of file names that are immediately used and deleted is 
useless and to me makes the code less readable.

I intend these changes only for 3.6 and will not apply until after the new unix 
keys patch.  Serhiy, have you noticed any similar cleanups that would be 
appropriate to add?

--
assignee: terry.reedy
files: config-clean.diff
keywords: patch
messages: 269809
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Cleanup config code
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file43623/config-clean.diff

___
Python tracker 

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

[issue27451] gzip.py: Please save more of the gzip header for later examination

[Josh Triplett]

New submission from Josh Triplett:

GzipFile currently reads and discards various fields from the gzip header, such 
as the original filename and timestamp.  Please consider reading all the fields 
of the gzip header into fields of the GzipFile instance, so that users of 
GzipFile can access these fields.

--
components: Library (Lib)
messages: 269808
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: gzip.py: Please save more of the gzip header for later examination
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue27450] bz2: BZ2File should expose compression level as an attribute

[Josh Triplett]

New submission from Josh Triplett:

(This exists in both Python 3 and Python 2.)

When opening an existing .bz2 file with BZ2File, I'd like to have access to the 
compression level, so that I don't have to manually parse the file's header to 
get it.  BZ2File could provide the compression level as an attribute on itself.

--
components: Library (Lib)
messages: 269806
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: bz2: BZ2File should expose compression level as an attribute
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

Re: Structure of program development

[BartC]

On 04/07/2016 17:55, Chris Warrick wrote:


A second question of the basic design. If I write a program, can I move it to a 
computer that is without any Python software, or does that machine have to 
download the Python software? Does Python products contain all parts of a 
developed program or is it a series of 'call' statements?


You must either install a Python interpreter on that machine, or
distribute one with your program.


If only it was that simple. My Windows Python 3.4 installation comprises 
5200 files over 1300 directories, totalling 100MB.


Other Pythons are a bit smaller, so I don't know what extras that 
includes. Which is part of the problem: you have to employ yet more 
extras to figure out the files needed to create a tidy distribution.


However the Linuxes I've seen tend to have Python pre-installed. Then 
you can just supply the .py files of the application.



--
Bartc


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

[issue27419] Bugs in PyImport_ImportModuleLevelObject

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is a reproducer for the second bug.

In Python 2.7 and Python 3.2 all works.

In Python 3.3+:

$ ./python import_bug_2.py 
Traceback (most recent call last):
  File "import_bug_2.py", line 6, in 
import os.path
  File "import_bug_2.py", line 4, in __import__
raise AssertionError
AssertionError

--
Added file: http://bugs.python.org/file43621/import_bug_2.py

___
Python tracker 

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

[issue27448] Race condition in subprocess.Popen which causes a huge memory leak

[Andrew]

Andrew added the comment:

pppery, I don't think I am breaking gc functionality with my code. The code 
line I gave just meant to give the basic idea of what was helping to workaround 
this. If you are actually interested in the code I use, it is below:

def fix_subprocess_racecondition():
  """
  !!! PLEASE NOTE THIS SHOULD BE CALLED BEFORE ANY OTHER INITIALIZATION was 
done to avoid already created links to subprocess or subprocess.gc or gc
  """
  # monkey patching subprocess
  import subprocess
  subprocess.gc.isenabled = lambda: True

  # re-importing gc to have correct isenabled for non-subprocess contexts
  import sys
  del sys.modules['gc']
  import gc

--

___
Python tracker 

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

[issue27422] Deadlock when mixing threading and multiprocessing

[Davin Potts]

Changes by Davin Potts :


--
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue27422] Deadlock when mixing threading and multiprocessing

[Davin Potts]

Davin Potts added the comment:

@r.david.murray:  Oh man, I was not going to go as far as advocate dropping the 
GIL.  :)

At least not in situations like this where the exploitable parallelism is meant 
to be at the Python level and not inside the Fortran code (or that was my 
understanding of the setup).  Martin had already mentioned the motivation to 
fork to avoid side effects possibly arising somewhere in that code.

In practice, after dropping the GIL the threads will likely use multiple of the 
cores -- though that's up to the OS kernel scheduler, that's what I've observed 
happening after temporarily dropping the GIL on both Windows and Linux systems. 
 

As to the benefit of CPU affinity, it depends -- it depends upon what my code 
was and what the OS and other system processes were busily doing at the time my 
code ran -- but I've never seen it hurt performance (even if the help was 
diminishingly small at times).  For certain situations, it has been worth doing.


Correction:  I have seen cpu affinity hurt performance when I make a 
bone-headed mistake and constrain too many things onto too few cores.  But 
that's a PEBCAK root cause.

--

___
Python tracker 

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

Need help compiling Python-devel

[TM]

Hi,

I have successfully compiled Python-2.7.12 on AIX 6.1 TL09, using steps
below. However I need the python-devel library/headers. How do I compile
Python, so that I can use this?

# ./configure --with-gcc="gcc" --with-cxx="gcc" --disable-ipv6
# make

Any help is greatly appreciated.

Thanks,
Tony
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27448] Race condition in subprocess.Popen which causes a huge memory leak

[ppperry]

ppperry added the comment:

What are you doing that creates so many circular references that the not 
collecting them causes a massive memory leak? Or are you using an alternative 
implementation of Python?

In addition, your monkeypatching is incorrect. `subprocess.gc` is the same 
object as the module you get by typing `import gc`, sou you are completely 
breaking the `gc.isenabled` functionality.

--
nosy: +ppperry

___
Python tracker 

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

Re: file.seek() and file.tell() look inconsistent to me

[MRAB]

On 2016-07-04 16:48, Marco Buttu wrote:

Hi all,

if I open a file in text mode, do you know why file.seek() returns the
number of bytes, and file.tell() takes the number of bytes? I was
expecting the number of characters, like write() does:

 >>> f = open('myfile', 'w')
 >>> f.write('aè')
2

It seems to me not consistent, and maybe could also be error prone:

 >>> f.seek(2)
2
 >>> f.write('c')
1
 >>> f.close()
 >>> open('myfile').read()
...
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3...


Some encodings, such as UTF-8, use a variable number of bytes per 
character (codepoint, actually), so in order to seek to a certain 
character position you would need to read from a known position, e.g. 
the start of the file, until you reached the desired place.


Most of the time you're seeking to a position that was previously 
returned by tell anyway.


I think it's a case of "practicality beats purity".

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

[issue26027] Support Path objects in the posix module

[Brett Cannon]

Brett Cannon added the comment:

I have no issues inlining -- with a comment about the inlining -- if it buys us 
better error messages in this critical case.

--

___
Python tracker 

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

[issue27186] add os.fspath()

[Brett Cannon]

Brett Cannon added the comment:

I'm fine with merging the two files if you want to do it. Build rules will also 
need updating if they do get merged.

--

___
Python tracker 

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

Re: Structure of program development

[Jussi Piitulainen]

Michael Smolen writes:

> Folks:
>
> I am new to this programming adventure. I've gotten past the
> introductory chapters in 'How to..." books and now want to start
> developing a much more complicated program that I will use repeated
> for different applications. When I worked in Perl there was an option
> to write a program in a text editor, save it, and then run in with
> Perl. Is such a thing possible in Python? If not, how do I develop a
> 500+ lines of code?

This is indeed possible.

If you can find your way to a command line of your operating system and
launch a Python interactive session by typing "python" or "python3" to
the command prompt and pressing the enter key, then you have access to
the program that can execute your Python code that is in the file that
you created with a text editor. All you have to do is, give the name of
your file as an argument to python or python3. You get a stack trace,
fix your program, and try again.

Some text editors understand Python syntax, or can be set to understand
Python syntax, just like they support Perl and many other languages.
This is merely a convenience. Python need not know what you used to
write the code.

> A second question of the basic design. If I write a program, can I
> move it to a computer that is without any Python software, or does
> that machine have to download the Python software? Does Python
> products contain all parts of a developed program or is it a series of
> 'call' statements?

The straightforward thing is to have Python installed.

Beyond that, I don't have personal experience, so I won't offer any
advice. Others will know.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Structure of program development

[Alan Evangelista]

I am new to this programming adventure. I've gotten past the introductory chapters 
in 'How to..." books and now want to start developing a much more complicated 
program that I will use repeated for different applications. When I worked in Perl 
there was an option to write a program in a text editor, save it, and then run in 
with Perl. Is such a thing possible in Python? If not, how do I develop a 500+ lines 
of code?


Yes. You can do it for every programming language I know, otherwise development 
would be impossible.


A second question of the basic design. If I write a program, can I move it to a 
computer that is without any Python software, or does that machine have to 
download the Python software? Does Python products contain all parts of a 
developed program or is it a series of 'call' statements?


The target system must have the Python interpreter and standard library, which are always installed 
together.


A software developed in Python must contain the method calls to the Python standard library, 3rd 
party libraries
and/or custom code. It may or not contain the Python runtime environment (interpreter and std 
library). In Linux,
for instance, it is standard to not include dependencies (eg Python runtime environment) in an 
application, but

reuse the one already installed in the target system.


Regards

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

[issue27447] python -m doctest script_file_with_no_py_extension produces confusing NameErrors

[towb]

towb added the comment:

Improving the documentation would also be nice, and easier. -m is mentioned in 
two places, first only as a shortcut for testmod, later with an explanation on 
name extensions and testfile. At least I didn't get that far.

--

___
Python tracker 

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

Re: Structure of program development

[BartC]

On 04/07/2016 17:07, Michael Smolen wrote:

Folks:

I am new to this programming adventure. I've gotten past the introductory chapters 
in 'How to..." books and now want to start developing a much more complicated 
program that I will use repeated for different applications. When I worked in Perl 
there was an option to write a program in a text editor, save it, and then run in 
with Perl. Is such a thing possible in Python? If not, how do I develop a 500+ lines 
of code?

A second question of the basic design. If I write a program, can I move it to a 
computer that is without any Python software, or does that machine have to 
download the Python software? Does Python products contain all parts of a 
developed program or is it a series of 'call' statements?


It can work the same way. Write the 500-line program in, say, prog.py 
using any text editor.


Then run it using:

python prog.py


--
Bartc

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

Re: Structure of program development

[Chris Warrick]

On 4 July 2016 at 18:07, Michael Smolen <8smo...@tds.net> wrote:
> Folks:
>
> I am new to this programming adventure. I've gotten past the introductory 
> chapters in 'How to..." books and now want to start developing a much more 
> complicated program that I will use repeated for different applications. When 
> I worked in Perl there was an option to write a program in a text editor, 
> save it, and then run in with Perl. Is such a thing possible in Python? If 
> not, how do I develop a 500+ lines of code?

Yes, the same way it works in Perl. Use the .py file extension and run
the `python` interpreter from command line, or use an IDE that would
help you with that.

> A second question of the basic design. If I write a program, can I move it to 
> a computer that is without any Python software, or does that machine have to 
> download the Python software? Does Python products contain all parts of a 
> developed program or is it a series of 'call' statements?

You must either install a Python interpreter on that machine, or
distribute one with your program.

-- 
Chris Warrick 
PGP: 5EAAEA16
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27422] Deadlock when mixing threading and multiprocessing

[R. David Murray]

R. David Murray added the comment:

To clarify the GIL issue (for davin, I guess? :): if the library you are using 
to interface with the FORTRAN code drops the GIL before calling the FORTRAN, 
then you *can* take advantage of multiple cores.  It is only the python code 
(and some of the code interacting with the python objects) that is limited to 
executing on one core at a time.  (As far as I know it isn't restricted to be 
the *same* core unless you set CPU affinity somehow, and I have no idea if it 
improves performance to use CPU affinity or not).

--

___
Python tracker 

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

[issue26027] Support Path objects in the posix module

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

At first glance issue27186-os_path_t.patch looks good.

But with the patch applied the error message in case of incorrect argument type 
is always "expected str, bytes or os.PathLike object, not ...". Currently it is 
more detailed and specific: contains the function and the argument names, and 
is aware that some functions accept an integer or None. I think the best way is 
to inline the code of PyOS_FSPath in path_converter.

Also we first resolve issue26800.

--
dependencies: +Don't accept bytearray as filenames part 2

___
Python tracker 

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

[issue18920] argparse version action should print to stdout, not stderr

[Jakub Wilk]

Changes by Jakub Wilk :


--
nosy: +jwilk
title: argparse module version action -> argparse version action should print 
to stdout, not stderr

___
Python tracker 

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

Re: Well, I finally ran into a Python Unicode problem, sort of

[Marko Rauhamaa]

BartC :
> Usually anything that is defined can be changed at run-time so that the
> compiler can never assume anything.

The compiler can't assume anything permanent, but it could heuristically
make excellent guesses at runtime. It needs to verify its guesses at the
boundaries of compiled code and gradually keep expanding the boundaries.
If the guesses end up being wrong, it has to correct its assumptions and
recompile the relevant parts of the code.


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

[issue27448] Race condition in subprocess.Popen which causes a huge memory leak

[R. David Murray]

R. David Murray added the comment:

I presume we don't re-enable gc in the child because if there's an exception it 
is exiting anyway.

FYI subprocess32, which fixes some other race conditions, shouldn't have this 
problem, since it is a backport of subprocess from python3, which no longer 
manipulates the GC.  Unlike the other race that subprocess32 fixes, this one 
could be fixed in python2, though, if you want to propose a patch.

--
nosy: +gps, r.david.murray

___
Python tracker 

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

[issue27186] add os.fspath()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Maybe merge Include/osmodule.h and Modules/posixmodule.h?

--

___
Python tracker 

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

[issue27422] Deadlock when mixing threading and multiprocessing

[Martin Ritter]

Martin Ritter added the comment:

Dear Davin, 

Thanks for the input, I was perfectly aware that the "solution" I proposed is 
not realistic. But the feedback that multiprocessing is using threads 
internally is useful as I can quickly abandon the idea to do something like the 
check I proposed in our code base without spending time on it. 

I was aware of the Gil, I just did not anticipate that big a problem when 
mixing threads and processes with rather simple python code. My bad, sorry for 
the noise. 

Cheers, 

Martin

--

___
Python tracker 

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

[issue26974] Crash in Decimal.from_float

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ping.

--

___
Python tracker 

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

[issue23591] Add IntFlags

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ping again.

--

___
Python tracker 

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

[issue27447] python -m doctest script_file_with_no_py_extension produces confusing NameErrors

[R. David Murray]

R. David Murray added the comment:

This is not a bug, it is a feature.  python -m doctest can be used to run tests 
from files that are *not* python files.

I wouldn't call tracebacks with name errors as a silent failure :)

As you say, there is no easy way to use doctest to run doctests in a script 
file that is not a .py file, since it can't be imported, so I'm not sure there 
is anything that can be done here.  Even trying to guess that it is a python 
file and issuing an error message or even a warning is problematic from a 
backward compatibility standpoint, since there may be people with files that 
look like python files that are *meant* to be run as doctests.

I'm guessing script-with-testable-docstrings isn't *common*, though I can 
easily imagine myself writing one (using subprocess to re-exec the script).  
What I actually did, though, was have a command line switch that runs the 
doctests by calling testmod from within the script, which is how doctest is 
designed to work.  

So, we can see what other people think about the idea of looking for a shebang 
line and issuing an error message.  Or maybe a warning...or an error plus a 
command line switch to force it to process the script anyway?

--
nosy: +r.david.murray
title: python -m doctest file_with_no_py_extension # silently fails -> python 
-m doctest script_file_with_no_py_extension produces confusing NameErrors
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue19527] Test failures with COUNT_ALLOCS

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

All tests now are passed in 3.6 on Linux. Making them passing in 3.5 requires 
too much changes that are not needed in 3.6. I don't think we need to pollute 
tests with these temporary workarounds.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

___
Python tracker 

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

Structure of program development

[Michael Smolen]

Folks:

I am new to this programming adventure. I've gotten past the introductory 
chapters in 'How to..." books and now want to start developing a much more 
complicated program that I will use repeated for different applications. When I 
worked in Perl there was an option to write a program in a text editor, save 
it, and then run in with Perl. Is such a thing possible in Python? If not, how 
do I develop a 500+ lines of code?

A second question of the basic design. If I write a program, can I move it to a 
computer that is without any Python software, or does that machine have to 
download the Python software? Does Python products contain all parts of a 
developed program or is it a series of 'call' statements?

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

[issue23034] Dynamically control debugging output

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

___
Python tracker 

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

Re: Well, I finally ran into a Python Unicode problem, sort of

[BartC]

On 04/07/2016 15:46, Ned Batchelder wrote:

On Monday, July 4, 2016 at 10:36:54 AM UTC-4, BartC wrote:

On 04/07/2016 13:47, Ned Batchelder wrote:



This is a huge change.


I've used a kind of 'weak' import scheme elsewhere, corresponding to C's
'#include'.



I think that could work in Python provided whatever is defined can
tolerate having copies redefined in each module that includes the same
file. Anything that is defined once and is never assigned to nor
modified for example.


You are hand-waving over huge details of semantics that are very important
in Python.  For example, it is very important not to have copies of
classes.  Importing a module must produce the same module object
everywhere it is imported, and the classes defined in the module must
be defined only once.


So that would be something that doesn't tolerate copies.

But I think that a bigger change for Python wouldn't be new ways of 
doing imports, but the concept of having a user-defined anything that is 
a constant at compile-time. And not part of a conditional statement either.


Usually anything that is defined can be changed at run-time so that the 
compiler can never assume anything.


--
Bartc

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

Re: Namespaces are one honking great idea

[jmp]

On 07/04/2016 01:37 PM, Chris Angelico wrote:

On Mon, Jul 4, 2016 at 9:23 PM, jmp  wrote:

On 07/01/2016 04:13 PM, Steven D'Aprano wrote:


But classes are not like the others: they must be instantiated before they
can be used, and they are more than just a mere namespace grouping related
entities. Classes support inheritance. Classes should be used for "is-a"
relationships, not "has-a" relationships. Although classes (and instances)
are namespaces, they provide fundamentally different kind of behaviour
than
modules and packages.



A namespace would not hurt but I really don't get why you don't consider
classes a valid and rather helpful namespace.

1/ classes do not have to be instantiated.
2/ the fact that classes are more than a namespace is not an argument.
Almost any object in python is able to do more than what you are actually
using.
3/ Classes are used as much as 'is-a' than 'has-a', class instances *have* a
state usually described by attributes
4/ "Although classes (and instances) are namespaces, ". You seem to
contradict yourself. It was probably a rhetorical construct but it's rather
confusing.


Functions within the namespace can't call other functions within the
same namespace using unqualified names. This was a stated requirement.

ChrisA



Ho, I missed that one.

But if it's the only missing requirement, wouldn't be like stating that 
python instances are not instances because methods cannot call other 
methods without "self."ed qualified name ? We like explicit qualified 
stuff in python right ? ("explicit is better than implicit")


jm



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

file.seek() and file.tell() look inconsistent to me

[Marco Buttu]

Hi all,

if I open a file in text mode, do you know why file.seek() returns the 
number of bytes, and file.tell() takes the number of bytes? I was 
expecting the number of characters, like write() does:


>>> f = open('myfile', 'w')
>>> f.write('aè')
2

It seems to me not consistent, and maybe could also be error prone:

>>> f.seek(2)
2
>>> f.write('c')
1
>>> f.close()
>>> open('myfile').read()
   ...
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc3...


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

[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines

[Stefan Krah]

Stefan Krah added the comment:

It looks like the peephole optimizer chokes on some constant folding.
Probably:

INF = float("inf")
NAN = float("nan")

-INF
-NAN

You could try some combinations in the REPL.

--
nosy: +skrah

___
Python tracker 

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

[issue27444] Python doesn't build due to test_float.py broken on non-IEEE machines

[Greg Stark]

Greg Stark added the comment:

I certainly understand the limitations of volunteer projects. I know you have 
limited resources and can't test on every platform. That's actually exactly why 
I'm testing on this platform and why I reported the bug. If there's any 
additional information I can provide to help you I can try to get it.

I found this while trying to build a Postgres build-farm member to help us 
identify portability issues quickly on platforms that aren't widely used by 
developers. If Python has similar infrastructure I could deploy it to the same 
hardware to help you spot these problems sooner.

--

___
Python tracker 

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

[issue27422] Deadlock when mixing threading and multiprocessing

[Davin Potts]

Davin Potts added the comment:

While I believe I understand the motivation behind the suggestion to detect 
when the code is doing something potentially dangerous, I'll point out a few 
things:
* any time you ask for a layer of convenience, you must choose something to 
sacrifice to get it (usually performance is sacrificed) and this sacrifice will 
affect all code (including non-problematic code)
* behind the scenes multiprocessing itself is employing multiple threads in the 
creation and coordination between processes -- "checking to see if there are 
multiple threads active on process creation" is therefore a more complicated 
request than it maybe first appears
* Regarding "python makes it very easy to mix these two", I'd say it's nearly 
as easy to mix the two in C code -- the common pattern across different 
languages is to learn the pros+cons+gotchyas of working with processes and 
threads

I too come from the world of scientific software and the mixing of Fortran, 
C/C++, and Python (yay science and yay Fortran) so I'll make another point 
(apologies if you already knew this):
There's a lot of computationally intensive code in scientific code/applications 
and being able to perform those computations in parallel is a wonderful thing.  
I am unsure if the tests you're trying to speed up exercise compute-intensive 
functions but let's assume they do.  For reasons not described here, using the 
CPython implementation, there is a constraint on the use of threads that 
restricts them to all run on a single core of your multi-core cpu (and on only 
one cpu if you have an SMP system).  Hence spinning up threads to perform 
compute intensive tasks will likely result in no better throughput (no speedup) 
because they're all fighting over the same maxed-out core.  To spread out onto 
and take advantage of multiple cores (and multiple cpus on an SMP system) you 
will want switch to creating processes (as you say you now have).  I'd make the 
distinction that you are likely much more interested in 'parallel computing' 
than 'concurrent execution'.  Since you're already using mult
 iprocessing you might also simply use `multiprocessing.Pool`.

--

___
Python tracker 

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

Re: Well, I finally ran into a Python Unicode problem, sort of

[Ned Batchelder]

On Monday, July 4, 2016 at 10:36:54 AM UTC-4, BartC wrote:
> On 04/07/2016 13:47, Ned Batchelder wrote:
> > On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote:
> >> On 04/07/2016 03:30, Steven D'Aprano wrote:
> 
> >>> You're still having problems with the whole Python-as-a-dynamic-language
> >>> thing, aren't you? :-)
> 
> >> Most Pythons seem to pre-compile code before executing the result. That
> >> pre-compilation requires that operators and precedences are known in
> >> advance and the resulting instructions are then hard-coded before 
> >> execution.
> >
> > This is the key but subtle point that all the discussion of parser mechanics
> > are missing: Python today needs no information from imported modules in
> > order to compile a file.  When the compiler encounters "import xyzzy" in
> > a file, it doesn't have to do anything to find or read xyzzy.py at compile
> > time.
> 
> Yeah, there's that small detail. Anything affecting how source is to be 
> parsed needs to known in advance.
> 
> > If operators can be invented, they will only be useful if they can be
> > created in modules which you then import and use.  But that would mean that
> > imported files would have to be found and read during compilation, not
> > during execution as they are now.
> >
> > This is a huge change.
> 
> I've used a kind of 'weak' import scheme elsewhere, corresponding to C's 
> '#include'.
> 
> Then the textual contents of that 'imported' module are read by the 
> compiler, and treated as though they occurred in this module. No new 
> namespace is created.
> 
> I think that could work in Python provided whatever is defined can 
> tolerate having copies redefined in each module that includes the same 
> file. Anything that is defined once and is never assigned to nor 
> modified for example.

You are hand-waving over huge details of semantics that are very important
in Python.  For example, it is very important not to have copies of
classes.  Importing a module must produce the same module object
everywhere it is imported, and the classes defined in the module must
be defined only once.

This is what makes catching exceptions work (because it is based on an
exception being an instance of a particular class), and what makes
class attributes shared among all the instances of the class.

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

Re: Well, I finally ran into a Python Unicode problem, sort of

[BartC]

On 04/07/2016 13:47, Ned Batchelder wrote:

On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote:

On 04/07/2016 03:30, Steven D'Aprano wrote:



You're still having problems with the whole Python-as-a-dynamic-language
thing, aren't you? :-)



Most Pythons seem to pre-compile code before executing the result. That
pre-compilation requires that operators and precedences are known in
advance and the resulting instructions are then hard-coded before execution.


This is the key but subtle point that all the discussion of parser mechanics
are missing: Python today needs no information from imported modules in
order to compile a file.  When the compiler encounters "import xyzzy" in
a file, it doesn't have to do anything to find or read xyzzy.py at compile
time.


Yeah, there's that small detail. Anything affecting how source is to be 
parsed needs to known in advance.



If operators can be invented, they will only be useful if they can be
created in modules which you then import and use.  But that would mean that
imported files would have to be found and read during compilation, not
during execution as they are now.

This is a huge change.


I've used a kind of 'weak' import scheme elsewhere, corresponding to C's 
'#include'.


Then the textual contents of that 'imported' module are read by the 
compiler, and treated as though they occurred in this module. No new 
namespace is created.


I think that could work in Python provided whatever is defined can 
tolerate having copies redefined in each module that includes the same 
file. Anything that is defined once and is never assigned to nor 
modified for example.


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

Re: Gzip module does not support Unix compressed .Z files [SEC=UNOFFICIAL]

[Robert Kern]

On 2016-07-04 09:00, dieter wrote:

"Owen Brandon"  writes:


I have a query regarding the support of decompression for Unix compressed .Z 
files in Python's gzip module. The gzip system utility supports this using the 
'-d' switch, but the python module does not.


When I am right, then the "zipfile" module handles ".Z" compressed files.


No, that handles PKZIP .zip files. There are third-party modules that handle the 
.Z format, but shelling out to external programs may still be preferable:


  https://github.com/umeat/unlzw

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

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

[issue27439] Add a product() function to the standard library

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue12806] argparse: Hybrid help text formatter

[Jakub Wilk]

Changes by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

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

EuroPython 2016: Please configure your tickets

[M.-A. Lemburg]

The EuroPython website supports buying tickets for other people
(friends, colleagues, etc.). As a result, it is necessary to assign
the tickets you buy to either yourself or someone else. The assignment
process is explained below.


Please tell us your preferences
---

The reason we’re interested in you applying this configuration as soon
as possible, is that the tickets include a number of preferences which
we need to know about in order to properly prepare the conference.

When assigning tickets you will fill some fields, telling us your
t-shirt size and cut (women or men style) and your diet
preferences. If you don’t provide this information, we cannot assure
we’ll have the right t-shirt available for you. Likewise, if you are
vegetarian, it is important to mark this in the preferences, so that
we can order enough vegetarian food.


How to assign tickets to attendees
--

First you need to log in and go to your profile and, if you already
bought your tickets, you will see something similar to this. Click on
"View your tickets".

After you have navigated to the tickets, we need you to assign the
ticket: simply hover over the ticket and you will see two
options. Please select, if the ticket is for you or for someone else.

Remember: Before assigning the ticket the other persons, these must be
registered on the website. Otherwise, the assignment won’t work.

If you have assigned the tickets to someone else, please let them
know. The system will send out automatic emails, but it’s safer to
send a separate email so that the information doesn’t get lost in a
spam filter.


How to edit the fields of the tickets
-

After assigning the ticket, each attendee will need to fill out the
ticket preferences using his/her profile page (don’t forget to click
save to store the settings).

Some additional help for the preference form:

 * Tagline: This line will appear after you name. Be original!

 * Diet: Omnivorous, Vegetarian or Other (we’ll try to provide food
   for other diets as well)

 * Python experience: Whats your experience level with Python? You can
   also enter “no comment”, if you prefer not to make this information
   public.

 * Dates: Which days do you plan to attend. This is not binding in any
   way, it just helps us to better prepare for the conference.


With gravitational regards,
--
EuroPython 2016 Team
http://ep2016.europython.eu/
http://www.europython-society.org/


PS: Please forward or retweet to help us reach all interested parties:
https://twitter.com/europython/status/749960553280528384
Thanks.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27449] pip install --upgrade pip (Windows)

[Zachary Ware]

Zachary Ware added the comment:

As the traceback suggests, you don't have permission to write there. You'll 
need to run that as an administrator, but note that you'll run into a different 
issue using the 'pip' command to upgrade itself; use 'py -3.5 -m pip install -U 
pip' instead. 

Also, pip is not actually part of the standard library, it's just bundled with 
CPython. For any change you'd like to see in pip's behavior, you'll need to 
raise an issue on pip's issue tracker (https://github.com/pypa/pip/issues).

--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

Re: Spot the bug: getoptquestion.py

[Chris Angelico]

On Mon, Jul 4, 2016 at 10:38 PM, Oscar  wrote:
> But is this not at least a bit unexpected behaviour from getopt? On one
> hand, if I want to have trailing spaces in my longoptions, why not just
> play along and allow them? On the other hand, a space is a delimiter on
> the commandline. Does it make sense to allow it as a parameter to
> getopt()? And if getopt would silently strip it, would that be a bug?
>

This is really the crux of the matter. Honestly, I've no idea. The
getopt module is designed to match the C getopt function, which I've
never used; for my command-line parsing, I use argparse instead
(usually via some wrapper that cuts down the duplication, like clize).

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

[issue27422] Deadlock when mixing threading and multiprocessing

[Martin Ritter]

Martin Ritter added the comment:

I agree that this is error prone and can not be fixed reliably on the python 
side. However, python makes it very easy to mix these two, a user might not 
even notice it if a function he calls uses fork and thus just use a 
ThreadPoolExecutor() because it's the simplest thing to do.

What could be an nice solution in my opinion if the multiprocessing module 
could check if there are already multiple threads active on process creation 
and issue a warning if so. This warning could of course be optional but would 
make this issue more obvious.

In my case we have a large C++ code base which still includes a lot of Fortran 
77 code with common blocks all over the place (yay science). Everything is 
interfaced in python so to make sure that I do not have any side effects I run 
the some of the functions in a fork using multiprocessing.Process(). And in 
this case I just wanted to run some testing in parallel. I now switched to a 
ProcessPoolExecutor which works fine but for me.

--

___
Python tracker 

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

[issue27449] pip install --upgrade pip (Windows)

[frank-e]

New submission from frank-e:

`python -m pip install --upgrade pip` on Windows 7 with Python 3.5.2 installed 
for all users, PermissionError: [WinError 5] Access denied: 'c:\\program 
files\\python35\\lib\\site-packages\\p
ip-8.1.1.dist-info\\description.rst'

--
components: Windows
files: pip.8.1.1.txt
messages: 269784
nosy: frank-e, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pip install --upgrade pip (Windows)
versions: Python 3.5
Added file: http://bugs.python.org/file43620/pip.8.1.1.txt

___
Python tracker 

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

[issue27448] Race condition in subprocess.Popen which causes a huge memory leak

[Andrew]

New submission from Andrew:

We had problem where at some point python start consuming RAM. Until it ends.

The reason was race condition in subprocess.Popen. Which triggered gc.disable() 
and never gc.enable().

The workaround we use is:
subprocess.gc.isenabled = lambda: True


The scenario for race condition is pretty obvious looking into the code below:

  gc_was_enabled = gc.isenabled() <- T1 gets false here
  gc.disable()
  try:
  self.pid = os.fork() <- while T2 is here
  except:
  if gc_was_enabled:
  gc.enable()
  raise
  ... CODE FRAGMENT 1 ...
  if gc_was_enabled:
  gc.enable()

Also I wonder if exception fails in "... CODE FRAGMENT 1 ..." why don't we 
re-enable gc (finally block)

--
messages: 269783
nosy: aonishuk
priority: normal
severity: normal
status: open
title: Race condition in subprocess.Popen which causes a huge memory leak
versions: Python 2.7

___
Python tracker 

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

Re: Well, I finally ran into a Python Unicode problem, sort of

[Ned Batchelder]

On Monday, July 4, 2016 at 6:05:20 AM UTC-4, BartC wrote:
> On 04/07/2016 03:30, Steven D'Aprano wrote:
> > On Mon, 4 Jul 2016 10:17 am, BartC wrote:
> >
> >> On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:
> >>> On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:
>  Python lacks a mechanism to add user-defined operators. (R has this
>  capability.) Maybe this feature could be added.
> >>>
> >>> That would be neat. But remember, you would have to define the operator
> >>> precedence as well. So you could no longer use a recursive-descent
> >>> parser.
> >>
> >> That wouldn't be a problem provided the new operator symbol and its
> >> precedence is known at a compile time, and defined before use.
> >
> > You're still having problems with the whole Python-as-a-dynamic-language
> > thing, aren't you? :-)
> 
> Well it isn't completely dynamic, not unless code only exists as a eval 
> or exec argument string (and even there, any changes will only be seen 
> on calling eval or exec again on the same string).
> 
> Most Pythons seem to pre-compile code before executing the result. That 
> pre-compilation requires that operators and precedences are known in 
> advance and the resulting instructions are then hard-coded before execution.

This is the key but subtle point that all the discussion of parser mechanics
are missing: Python today needs no information from imported modules in
order to compile a file.  When the compiler encounters "import xyzzy" in
a file, it doesn't have to do anything to find or read xyzzy.py at compile
time.

If operators can be invented, they will only be useful if they can be
created in modules which you then import and use.  But that would mean that
imported files would have to be found and read during compilation, not
during execution as they are now.

This is a huge change.

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

Re: Spot the bug: getoptquestion.py

[Oscar]

In article ,
Chris Angelico   wrote:
>On Mon, Jul 4, 2016 at 9:24 PM, Oscar  wrote:
>> Is this:
>>
>> a) a bug in getopt.getopt
>> b) a bug in my code
>> c) a great way to keep me busy for a while
>> d) all of the above?
>>
>>
>> #!/usr/bin/python
>>
>> from __future__ import print_function
>> from getopt import getopt, GetoptError
>> import sys
>>
>> try:
>> opts, args = getopt(sys.argv[1:], 'b', ['bug '])
>>
>> except GetoptError as err:
>> print('Caught:', repr(err))
>>
>> else:
>> if opts:
>> for opt, arg in opts:
>>
>> if opt in ('-b', '--bug'):
>> print ("Ceci n'est pas un bug!")
>> else:
>> #print ('Missed option: "{0}"'.format(opt))
>> print ('Missed option:', opt)
>> else:
>> print('Usage:', sys.argv[0],'-b|--bug')
>
>Well, first thing I'd do is wipe out your try/except. It's not really
>achieving much (you effectively catch an exception to print it to the
>console and terminate).

It does something: it shows that --bug on my commandline did not throw
an GetoptError. I could post the whole 400 line script, but decided to
cut it down to a demonstration of a subtle bug that i introduced in my
script. So far, answers b) and c) certainly do apply.


>But then what I'm seeing is that you have 'bug ' (with a trailing
>space) in your list of long options, so getopt returns '--bug ' as a
>long option.

You found it much faster than I did! ;-)

As i learned now, --b and --bu will also match '--bug ', as they are not
ambigous. So, of course '--bug' also returns '--bug ' in opts.

But it took me quite a while before I found my logic wasn't working
further down the script, just because I somehow introduced a space
character somewhere where it shouldn't have been.


> Is that a bug? I dunno. Why do you have the trailing
>space?

Because I'm stupid. It should not have been there at all. I've been
readjusting and reformatting my long 'getopt' line all day long and
somewhere my thumb must have hit my spacebar when I wasn't paying
attention. So a hard-to-find bug (for me at least) was introduced.

Now I also did not spot the trailing space in the loop where I was
evaluating the options when I added some debug statements. This sure 
got me scratching my head. The option is there, why doesn't my code do
what it's supposed to do? I sure was looking in the wrong place. I
better use repr() for debugging purposes next time. Thanks for the tip.

But is this not at least a bit unexpected behaviour from getopt? On one
hand, if I want to have trailing spaces in my longoptions, why not just
play along and allow them? On the other hand, a space is a delimiter on
the commandline. Does it make sense to allow it as a parameter to
getopt()? And if getopt would silently strip it, would that be a bug?

I agree that it's hard to debate wheter it is a bug, but I wanted to
share this experience anyway... ;-)


> In any case, it's pretty easy to see if you change one line of
>your code to:
>print('Missed option: %r' % opt)

Or uncomment my hint in the OP. But repr() is even better indeed.
-- 
[J|O|R] <- .signature.gz
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

[Rustom Mody]

On Monday, July 4, 2016 at 3:56:43 PM UTC+5:30, BartC wrote:
> On 04/07/2016 02:15, Lawrence D’Oliveiro wrote:
> > On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote:
> >> The structure of such a parser doesn't need to exactly match the grammar
> >> with a dedicated block of code for each operator precedence. It can be
> >> table-driven so that an operator precedence value is just an attribute.
> >
> > Of course. But that’s not a recursive-descent parser any more.
> >
> 
> All the parsers I write work the same way. If I can't describe them as 
> recursive descent, then I don't know what they are.
> 
> This is just recognising that a bunch of specialised functions that are 
> very similar can be reduced to one or two more generalised ones.

In gofer (likewise Haskell) one can concoct any operator and give it a 
precedence
and associativity -- l,r,non

Internals of Haskell I do not know, but of gofer I can say the following:

Implementation is in C.
Uses yacc to parse all operators left-assoc, same precedence
Then post-processes the tree with an elegant little shift-reduce parser
based on specified precedences and associativities.

I sometimes teach this to my kids as an example of how 
FP-style comments can clarify arcane imperative code:

Mark Jones (gofer author) original version + My version made executable
http://blog.languager.org/2016/07/a-little-functional-parser.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Namespaces are one honking great idea

[Chris Angelico]

On Mon, Jul 4, 2016 at 9:23 PM, jmp  wrote:
> On 07/01/2016 04:13 PM, Steven D'Aprano wrote:
>>
>> But classes are not like the others: they must be instantiated before they
>> can be used, and they are more than just a mere namespace grouping related
>> entities. Classes support inheritance. Classes should be used for "is-a"
>> relationships, not "has-a" relationships. Although classes (and instances)
>> are namespaces, they provide fundamentally different kind of behaviour
>> than
>> modules and packages.
>
>
> A namespace would not hurt but I really don't get why you don't consider
> classes a valid and rather helpful namespace.
>
> 1/ classes do not have to be instantiated.
> 2/ the fact that classes are more than a namespace is not an argument.
> Almost any object in python is able to do more than what you are actually
> using.
> 3/ Classes are used as much as 'is-a' than 'has-a', class instances *have* a
> state usually described by attributes
> 4/ "Although classes (and instances) are namespaces, ". You seem to
> contradict yourself. It was probably a rhetorical construct but it's rather
> confusing.

Functions within the namespace can't call other functions within the
same namespace using unqualified names. This was a stated requirement.

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

Re: Spot the bug: getoptquestion.py

[Chris Angelico]

On Mon, Jul 4, 2016 at 9:24 PM, Oscar  wrote:
> Is this:
>
> a) a bug in getopt.getopt
> b) a bug in my code
> c) a great way to keep me busy for a while
> d) all of the above?
>
>
> #!/usr/bin/python
>
> from __future__ import print_function
> from getopt import getopt, GetoptError
> import sys
>
> try:
> opts, args = getopt(sys.argv[1:], 'b', ['bug '])
>
> except GetoptError as err:
> print('Caught:', repr(err))
>
> else:
> if opts:
> for opt, arg in opts:
>
> if opt in ('-b', '--bug'):
> print ("Ceci n'est pas un bug!")
> else:
> #print ('Missed option: "{0}"'.format(opt))
> print ('Missed option:', opt)
> else:
> print('Usage:', sys.argv[0],'-b|--bug')

Well, first thing I'd do is wipe out your try/except. It's not really
achieving much (you effectively catch an exception to print it to the
console and terminate).

But then what I'm seeing is that you have 'bug ' (with a trailing
space) in your list of long options, so getopt returns '--bug ' as a
long option. Is that a bug? I dunno. Why do you have the trailing
space? In any case, it's pretty easy to see if you change one line of
your code to:

print('Missed option: %r' % opt)

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

[issue24959] unittest swallows part of stack trace when raising AssertionError in a TestCase

[Aaron Sokoloski]

Aaron Sokoloski added the comment:

I've run into this bug too.  Took a while to track down the cause :)

--
nosy: +Aaron Sokoloski

___
Python tracker 

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

Re: Namespaces are one honking great idea

[jmp]

On 07/01/2016 04:13 PM, Steven D'Aprano wrote:

But classes are not like the others: they must be instantiated before they
can be used, and they are more than just a mere namespace grouping related
entities. Classes support inheritance. Classes should be used for "is-a"
relationships, not "has-a" relationships. Although classes (and instances)
are namespaces, they provide fundamentally different kind of behaviour than
modules and packages.


A namespace would not hurt but I really don't get why you don't consider 
classes a valid and rather helpful namespace.


1/ classes do not have to be instantiated.
2/ the fact that classes are more than a namespace is not an argument. 
Almost any object in python is able to do more than what you are 
actually using.
3/ Classes are used as much as 'is-a' than 'has-a', class instances 
*have* a state usually described by attributes
4/ "Although classes (and instances) are namespaces, ". You seem to 
contradict yourself. It was probably a rhetorical construct but it's 
rather confusing.


jm

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

Spot the bug: getoptquestion.py

[Oscar]

Is this:

a) a bug in getopt.getopt
b) a bug in my code
c) a great way to keep me busy for a while
d) all of the above?


#!/usr/bin/python

from __future__ import print_function
from getopt import getopt, GetoptError
import sys

try:
opts, args = getopt(sys.argv[1:], 'b', ['bug '])

except GetoptError as err:
print('Caught:', repr(err))

else:
if opts:
for opt, arg in opts:

if opt in ('-b', '--bug'):
print ("Ceci n'est pas un bug!")
else:
#print ('Missed option: "{0}"'.format(opt))
print ('Missed option:', opt)
else:
print('Usage:', sys.argv[0],'-b|--bug') 


-- 
[J|O|R] <- .signature.gz
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Creating a calculator

[Antoon Pardon]

Op 01-07-16 om 15:52 schreef Steven D'Aprano:
> On Fri, 1 Jul 2016 10:25 pm, Christopher Reimer wrote:
>
>> For my BASIC interpreter, each line of BASIC is broken this way into
>> tokens.
> [...]
>> By using * to unpack the split line, my program no longer crashes and no
>> try/except block is needed to work around the crash. A later line of code
>> will test the expression, ignore if empty or run regex if full.
> I wish you wouldn't describe this as "crash".

I wish you wouldn't mix semantic levels.

>
> The Python interpreter should never crash. That would be a segmentation
> fault, and that is considered to be a very serious bug.

But in that case your computer didn't crash. That would be a your computer
freezing, or rebooting.

>
> But *raising an exception* is another story. Raising exceptions is not a
> crash, it is the interpreter working as expected. This statement:

A segment violation is not a crash either, your computer/os will just
carry on.

>
> line_number, keyword, expr = "20 END".split(' ', 2)
>
> is SUPPOSED to raise an exception, if it didn't, the interpreter would be
> broken. To call that a "crash" is horribly misleading.

Supposed by whom? The line may be supposed to raise an exception by
the languager designer, that doesn't mean the programmer meant to
write an instruction that would raise an exception. So the programmer
can correctly assert the line was not supposed to raise an exception.

-- 
Antoon.

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

Re: Well, I finally ran into a Python Unicode problem, sort of

[Jussi Piitulainen]

BartC writes:

> A simpler approach is to treat user-defined operators as aliases for
> functions:
>
> def myadd(a,b):
>   return a+b
>
> operator ∇:
>(myadd,2,+3)   # map to myadd, 2 operands, prio 3, LTR
>
> x = y ∇ z
>
> is then equivalent to:
>
> x = myadd(y,z)
>
> However you will usually want to be able overload the same operator
> for different operand types. That means mapping the operator to one of
> several methods. Maybe even allowing the operator to have either one
> or two operands.
>
> Trickier but still doable I think.

Julia does something like that. The parser knows a number of symbols
that it treats as operators, some of them are aliases for ASCII names,
all operators correspond to generic functions, and the programmer can
add methods for their own types (or for pre-existing types) to these
functions.

Prolog opens its precedence table for the programmer. I don't know if
there's been any Unicode activity, or any activity, in recent years, but
there are actually two different issues here: what is parsed as an
identifier, and what identifiers are treated as operator symbols (with
what precedence and associativity).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

[BartC]

On 04/07/2016 02:15, Lawrence D’Oliveiro wrote:

On Monday, July 4, 2016 at 12:40:14 PM UTC+12, BartC wrote:

The structure of such a parser doesn't need to exactly match the grammar
with a dedicated block of code for each operator precedence. It can be
table-driven so that an operator precedence value is just an attribute.


Of course. But that’s not a recursive-descent parser any more.



All the parsers I write work the same way. If I can't describe them as 
recursive descent, then I don't know what they are.


This is just recognising that a bunch of specialised functions that are 
very similar can be reduced to one or two more generalised ones.


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

Re: Special attributes added to classes on creation

[Xiang Zhang]

On Monday, July 4, 2016 at 12:02:41 AM UTC+8, Steven D'Aprano wrote:
> I have some code which can preprocess (using a metaclass) or postprocess
> (using a decorator) a class:
> 
> @process
> class K:
> pass
> 
> 
> class K(metaclass=process):
> pass
> 
> 
> Both should give the same result, but I have found that the results are
> slightly different because the dict passed to process as a metaclass is
> different from the the class dict seen by the decorator. I can demonstrate
> the difference in Python 3.6 by using this metaclass/decorator:
> 
> class process(type):
> def __new__(meta, *args):
> if len(args) == 1:
> # decorator usage
> cls = args[0]
> d = cls.__dict__
> elif len(args) == 3:
> # metaclass usage
> name, bases, d = args
> cls = super().__new__(meta, *args)
> print(sorted(d.keys()))
> return cls
> 
> 
> If I then try it against two identical (apart from their names) classes, I
> get these results:
> 
> 
> py> @process
> ... class K:
> ... x = 1
> ...
> ['__dict__', '__doc__', '__module__', '__weakref__', 'x']
> py> class Q(metaclass=process):
> ... x = 1
> ...
> ['__module__', '__qualname__', 'x']
> 
> 
> 
> Now if I check the newly created Q, I see the same keys K has:
> 
> py> sorted(Q.__dict__.keys())
> ['__dict__', '__doc__', '__module__', '__weakref__', 'x']
> 
> 
> Is there any documentation for exactly what keys are added to classes when? 
> 
> 
> 
> 
> -- 
> Steven
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.

eryk sun has a very good explanation. I want to add two points:

1. __qualname__ though passed in class creation, but it won't appear in the 
class.__dict__ since it is deliberately deleted from __dict__ in type_new.

2. __dict__ and __weakref__ are possible to be added even when there is not 
__slots__. __dict__ can be added when the base class's dictoffset == 0 and 
__weakref__ can be added when the base class's weakrefoffset == 0 && 
tp_itemsize == 0. An example is:

In [2]: class T(int):
   ...: pass
   ...: 

In [3]: T.__dict__
Out[3]: mappingproxy({'__module__': '__main__', '__dict__': , '__doc__': None})

I think this is a nice design in attribute searching.

BTW, I think this is a implementation detail. If you rely on it, it may easily 
break in the future.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

[Jussi Piitulainen]

Lawrence D’Oliveiro writes:

> On Monday, July 4, 2016 at 6:08:51 PM UTC+12, Jussi Piitulainen wrote:
>> Something could be done, but if the intention is to allow
>> mathematical notation, it needs to be done with care.
>
> Mathematics uses single-character variable names so that
> multiplication can be implicit.

Certainly on topic, though independent of Unicode. I was thinking of
different classes of operator symbols.

> An old, stillborn language design from the 1960s called CPL* had two
> syntaxes for variable names:
> * a single lowercase letter, optionally followed by any number of primes “'”;
> * an uppercase letter followed by letters or digits.
>
> It also allowed implicit multiplication; single-letter identifiers
> could be run together without spaces, but multi-character ones needed
> to be delimited by spaces or non-identifier characters. E.g.
>
>   Sqrt(bb - 4ac)
>   Area ≡ Length Width
>
> *It was never fully implemented, but a cut-down derivative named BCPL
> did get some use. Some researchers at Bell Labs took it as their
> starting point, first creating a language called “B”, then another one
> called “C” ... well, the rest is history. 

There's been at least D, F, J, K (APL family), R, S (_before_ R), T (a
Lisp), X (the window system), Z (some specification language).

Any single-letter non-ASCII names yet? Spelled-out like Lambda and Omega
don't count.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Well, I finally ran into a Python Unicode problem, sort of

[BartC]

On 04/07/2016 03:30, Steven D'Aprano wrote:

On Mon, 4 Jul 2016 10:17 am, BartC wrote:


On 04/07/2016 01:00, Lawrence D’Oliveiro wrote:

On Monday, July 4, 2016 at 11:47:26 AM UTC+12, eryk sun wrote:

Python lacks a mechanism to add user-defined operators. (R has this
capability.) Maybe this feature could be added.


That would be neat. But remember, you would have to define the operator
precedence as well. So you could no longer use a recursive-descent
parser.


That wouldn't be a problem provided the new operator symbol and its
precedence is known at a compile time, and defined before use.


You're still having problems with the whole Python-as-a-dynamic-language
thing, aren't you? :-)


Well it isn't completely dynamic, not unless code only exists as a eval 
or exec argument string (and even there, any changes will only be seen 
on calling eval or exec again on the same string).


Most Pythons seem to pre-compile code before executing the result. That 
pre-compilation requires that operators and precedences are known in 
advance and the resulting instructions are then hard-coded before execution.



In full generality, you would want to be able to define unary prefix, unary
suffix and binary infix operators, and set their precedence and whether
they associate to the left or the right. That's probably a bit much to
expect.


No, that's all possible. Maybe that's even how some language 
implementations work, defining all the set of standard operators at the 
start.



But if we limit ourselves to the boring case of binary infix operators of a
single precedence and associtivity, there's a simple approach: the parser
can allow any unicode code point of category "Sm" as a legal operator, e.g.
x ∇ y. Pre-defined operators like + - * etc continue to call the same
dunder methods they already do, but anything else tries calling:

x.__oper__('∇', y)
y.__roper__('∇', x)

and if neither of those exist and return a result other than NotImplemented,
then finally raise a runtime TypeError('undefined operator ∇').


A simpler approach is to treat user-defined operators as aliases for 
functions:


def myadd(a,b):
return a+b

operator ∇:
   (myadd,2,+3)   # map to myadd, 2 operands, prio 3, LTR

x = y ∇ z

is then equivalent to:

x = myadd(y,z)

However you will usually want to be able overload the same operator for 
different operand types. That means mapping the operator to one of 
several methods. Maybe even allowing the operator to have either one or 
two operands.


Trickier but still doable I think.

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

Re: Creating a calculator

[Pierre-Alain Dorange]

DFS  wrote:

> 
> 2 lines?  Love it!
> 
> But apparently eval==evil.
> 
> http://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html
> 
> I bet you get hammered about it here on clp.

It was a software to be deploy, it was just for educational purpose.

-- 
Pierre-Alain Dorange   Moof 

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

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

[issue27447] python -m doctest file_with_no_py_extension # silently fails

[towb]

New submission from towb:

Command line tools usually use the shebang and don't have a .py extension. This 
breaks the `python -m doctest` shortcut for testmod().

Getting it to work is probably ugly, but there should be a useful message. 
Currently it's just a NameError for every function, which is very confusing.

--
components: Library (Lib)
messages: 269781
nosy: towb
priority: normal
severity: normal
status: open
title: python -m doctest file_with_no_py_extension # silently fails
type: behavior
versions: Python 3.5

___
Python tracker 

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

ANN: Python Meeting Düsseldorf - 06.07.2016

[eGenix Team: M.-A. Lemburg]

[This announcement is in German since it targets a local user group
 meeting in Düsseldorf, Germany]



ANKÜNDIGUNG

  Python Meeting Düsseldorf

   http://pyddf.de/

Ein Treffen von Python Enthusiasten und Interessierten
 in ungezwungener Atmosphäre.

   Mittwoch, 06.07.2016, 18:15 Uhr
   Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
 Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf

Diese Nachricht ist auch online verfügbar:
http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2016-07-06


NEUIGKEITEN

 * Bereits angemeldete Vorträge:

   Stefan Richthofer
"JyNI – Native CPython-Extensions in Jython"

   Marc-Andre Lemburg
"Stand-Alone Applikationen mit eGenix PyRun"

   Charlie Clark
"Eine kurze Einführung in SQLAlchemy: Was es ist und
wie man es benutzen kann"

   Jens Diemer
"PyLucid – ein Open Source CMS auf Django Basis"

   Weitere Vorträge können gerne noch angemeldet werden: i...@pyddf.de

 * Startzeit und Ort:

   Wir treffen uns um 18:15 Uhr im Bürgerhaus in den Düsseldorfer
   Arcaden.

   Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und
   befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer
   Arcaden.

   Über dem Eingang steht ein großes "Schwimm' in Bilk" Logo. Hinter
   der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock
   hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus
   dem Aufzug kommt.

   Google Street View: http://bit.ly/11sCfiw



EINLEITUNG

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in
Düsseldorf, die sich an Python Begeisterte aus der Region wendet:

 * http://pyddf.de/

Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal,
auf dem wir die Vorträge nach den Meetings veröffentlichen:

 * http://www.youtube.com/pyddf/

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld,
in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

 * http://www.egenix.com/
 * http://www.clark-consulting.eu/



PROGRAMM

Das Python Meeting Düsseldorf nutzt eine Mischung aus Open Space
und Lightning Talks, wobei die Gewitter bei uns auch schon mal
20 Minuten dauern können ;-).

Lightning Talks können vorher angemeldet werden, oder auch spontan
während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung
steht zur Verfügung.

Lightning Talk Anmeldung bitte formlos per EMail an i...@pyddf.de



KOSTENBETEILIGUNG

Das Python Meeting Düsseldorf wird von Python Nutzern für Python
Nutzer veranstaltet. Um die Kosten zumindest teilweise zu
refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von
EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00
inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.



ANMELDUNG

Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir
bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung
eingegangen. Es erleichtert uns allerdings die Planung.

Meeting Anmeldung bitte formlos per EMail an i...@pyddf.de



WEITERE INFORMATIONEN

Weitere Informationen finden Sie auf der Webseite des Meetings:

http://pyddf.de/

Mit freundlichen Grüßen,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jul 04 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

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

Support the Python Software Foundation:
http://www.python.org/psf/donations/

ANN: Python Meeting Düsseldorf - 06.07.2016

[eGenix Team: M.-A. Lemburg]

[This announcement is in German since it targets a local user group
 meeting in Düsseldorf, Germany]



ANKÜNDIGUNG

  Python Meeting Düsseldorf

   http://pyddf.de/

Ein Treffen von Python Enthusiasten und Interessierten
 in ungezwungener Atmosphäre.

   Mittwoch, 06.07.2016, 18:15 Uhr
   Raum 1, 2.OG im Bürgerhaus Stadtteilzentrum Bilk
 Düsseldorfer Arcaden, Bachstr. 145, 40217 Düsseldorf

Diese Nachricht ist auch online verfügbar:
http://www.egenix.com/company/news/Python-Meeting-Duesseldorf-2016-07-06


NEUIGKEITEN

 * Bereits angemeldete Vorträge:

   Stefan Richthofer
"JyNI – Native CPython-Extensions in Jython"

   Marc-Andre Lemburg
"Stand-Alone Applikationen mit eGenix PyRun"

   Charlie Clark
"Eine kurze Einführung in SQLAlchemy: Was es ist und
wie man es benutzen kann"

   Jens Diemer
"PyLucid – ein Open Source CMS auf Django Basis"

   Weitere Vorträge können gerne noch angemeldet werden: i...@pyddf.de

 * Startzeit und Ort:

   Wir treffen uns um 18:15 Uhr im Bürgerhaus in den Düsseldorfer
   Arcaden.

   Das Bürgerhaus teilt sich den Eingang mit dem Schwimmbad und
   befindet sich an der Seite der Tiefgarageneinfahrt der Düsseldorfer
   Arcaden.

   Über dem Eingang steht ein großes "Schwimm' in Bilk" Logo. Hinter
   der Tür direkt links zu den zwei Aufzügen, dann in den 2. Stock
   hochfahren. Der Eingang zum Raum 1 liegt direkt links, wenn man aus
   dem Aufzug kommt.

   Google Street View: http://bit.ly/11sCfiw



EINLEITUNG

Das Python Meeting Düsseldorf ist eine regelmäßige Veranstaltung in
Düsseldorf, die sich an Python Begeisterte aus der Region wendet:

 * http://pyddf.de/

Einen guten Überblick über die Vorträge bietet unser YouTube-Kanal,
auf dem wir die Vorträge nach den Meetings veröffentlichen:

 * http://www.youtube.com/pyddf/

Veranstaltet wird das Meeting von der eGenix.com GmbH, Langenfeld,
in Zusammenarbeit mit Clark Consulting & Research, Düsseldorf:

 * http://www.egenix.com/
 * http://www.clark-consulting.eu/



PROGRAMM

Das Python Meeting Düsseldorf nutzt eine Mischung aus Open Space
und Lightning Talks, wobei die Gewitter bei uns auch schon mal
20 Minuten dauern können ;-).

Lightning Talks können vorher angemeldet werden, oder auch spontan
während des Treffens eingebracht werden. Ein Beamer mit XGA Auflösung
steht zur Verfügung.

Lightning Talk Anmeldung bitte formlos per EMail an i...@pyddf.de



KOSTENBETEILIGUNG

Das Python Meeting Düsseldorf wird von Python Nutzern für Python
Nutzer veranstaltet. Um die Kosten zumindest teilweise zu
refinanzieren, bitten wir die Teilnehmer um einen Beitrag in Höhe von
EUR 10,00 inkl. 19% Mwst, Schüler und Studenten zahlen EUR 5,00
inkl. 19% Mwst.

Wir möchten alle Teilnehmer bitten, den Betrag in bar mitzubringen.



ANMELDUNG

Da wir nur für ca. 20 Personen Sitzplätze haben, möchten wir
bitten, sich per EMail anzumelden. Damit wird keine Verpflichtung
eingegangen. Es erleichtert uns allerdings die Planung.

Meeting Anmeldung bitte formlos per EMail an i...@pyddf.de



WEITERE INFORMATIONEN

Weitere Informationen finden Sie auf der Webseite des Meetings:

http://pyddf.de/

Mit freundlichen Grüßen,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jul 04 2016)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

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

Re: Well, I finally ran into a Python Unicode problem, sort of

[Marko Rauhamaa]

Lawrence D’Oliveiro :

> Mathematics uses single-character variable names so that
> multiplication can be implicit.

I don't think anybody developed mathematical notation systematically.
Rather, over the centuries, various masters came up with personal
abbreviations and shorthand, which spread among admirers and students
through emulation. The resulting two-dimensional hodgepodge needs to be
supplemented by much natural-language handwaving. Rigorous treatment
needs to use a formal language, eg: http://us.metamath.org/mpeuni/evlslem2.html>.

Anyway, most programming has little use for mathematics. Thus, a
general-purpose programming language shouldn't bend over backwards to
placate that particular application domain.


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

Re: Making Classes Subclassable

[Lawrence D’Oliveiro]

On Monday, July 4, 2016 at 7:58:07 PM UTC+12, dieter wrote:
> --> "type(obj)" or "obj.__class__" (there are small differences)
> give you the type/class of "obj".

When would it not be the same?
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue27410] DLL hijacking vulnerability in Python 3.5.2 installer

[Mark Hammond]

Mark Hammond added the comment:

While I agree the risk is fairly low and it will require effort to actually do, 
it still sounds worth fixing at some point. A user might be tricked into 
downloading a DLL - eg, Firefox will happily save it without any scary UI - 
it's just a file. Later they run our "trusted" download from the same directory 
and we screw them - even if the attacker can't elevate they can do damage.

--
nosy: +mhammond

___
Python tracker 

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

Re: Well, I finally ran into a Python Unicode problem, sort of

[Lawrence D’Oliveiro]

On Monday, July 4, 2016 at 6:08:51 PM UTC+12, Jussi Piitulainen wrote:
> Something could be done, but if the intention is to allow
> mathematical notation, it needs to be done with care.

Mathematics uses single-character variable names so that multiplication can be 
implicit.

An old, stillborn language design from the 1960s called CPL* had two syntaxes 
for variable names:
* a single lowercase letter, optionally followed by any number of primes “'”;
* an uppercase letter followed by letters or digits.

It also allowed implicit multiplication; single-letter identifiers could be run 
together without spaces, but multi-character ones needed to be delimited by 
spaces or non-identifier characters. E.g.

  Sqrt(bb - 4ac)
  Area ≡ Length Width

*It was never fully implemented, but a cut-down derivative named BCPL did get 
some use. Some researchers at Bell Labs took it as their starting point, first 
creating a language called “B”, then another one called “C” ... well, the rest 
is history.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Gzip module does not support Unix compressed .Z files [SEC=UNOFFICIAL]

[dieter]

"Owen Brandon"  writes:

> I have a query regarding the support of decompression for Unix compressed .Z 
> files in Python's gzip module. The gzip system utility supports this using 
> the '-d' switch, but the python module does not.

When I am right, then the "zipfile" module handles ".Z" compressed files.

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

Re: Making Classes Subclassable

[dieter]

Lawrence D’Oliveiro  writes:

> Some of the classes in Qahirah, my Cairo binding 
>  I found handy to reuse elsewhere, for 
> example in my binding for Pixman . 
> Subclassing is easy, but then you need to ensure that operations inherited 
> from the superclass return instances of the right class. This means that 
> superclass methods must never refer directly to the class by name for 
> constructing new objects; they need to obtain the current class by more 
> indirect means.

--> "type(obj)" or "obj.__class__" (there are small differences)
give you the type/class of "obj".

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