Re: Python added to PATH, cannot be directly accessed, cannot install pip

[Eryk Sun]

On 9/27/21, Mats Wichmann  wrote:
>
> pip, meanwhile, is not in the same directory as the python executable,
> so even "adding python to PATH" doesn't solve the problem of running
> pip.  Invoke it like this instead:

The installer's option to add Python to PATH adds both the
installation directory and the scripts directory. The latter has
"pip.exe", assuming pip was installed.

> py -m pip install foo

If the `pip` command is on PATH, for an installation or active virtual
environment, it's usually fine to use it instead of `py -m pip` or
`python -m pip`. But there's one caveat. The `pip` command can't be
used to upgrade pip itself. For that you have to run the module via
`'py -m pip` or `python -m pip`.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Package conflicts trying to install jpegdupes package

[2QdxY4RzWzUUiLuE]

On 2021-09-28 at 10:44:02 +1000,
Chris Angelico  wrote:

> On Tue, Sep 28, 2021 at 10:40 AM Skip Montanaro
>  wrote:
> >
> > Woo hoo! It's installed. The ultimate error was a missing turbojpeg.h
> > file. Thank goodness for the apt-file command. I was able to track
> > that down to the libturbojpeg0-dev package, install that, and after a
> > bit more fussing around now have jpegdupes installed.
> >
> > Thanks for the help,
> >
> 
> Sweet! I like stories that have happy endings.
> 
> (No compilers were harmed in the making of this.)

Nor compiler authors/vendors/maintainers.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: XML Considered Harmful

[Avi Gross via Python-list]

Michael,

Given your further explanation, indeed reading varying numbers of points in
using a CSV is not valid, albeit someone might just make N columns (maybe a
few more than 7) to handle a hopefully worst case. Definitely it makes more
sense to read in a list or other data structure.

You keep talking about generators, though. If the generators are outside of
your program, then yes, you need to read in whatever they produce. But if
your data generator is within your own program, that opens up other
possibilities. I am not saying you necessarily would want to use the usual
numpy/pandas modules and have some kind of data.frame. I do know other
languages (like R) where I have used columns that are lists.

My impression is you may not be using your set of data points for any other
purposes except when ready to draw a spline. Again, in some languages this
opens up many possibilities. A fairly trivial one is if you store your
points as something like "1.2:3.86:12:83.2" meaning a character string with
some divider. When ready to use that, it is fairly straightforward to
convert it to a list to use for your purpose.

Can I just ask if by a generator, you do NOT mean the more typical use of
"generator" as used in python in which some code sort of runs as needed to
keep generating the next item to work on. Do you mean something that creates
realistic test cases to simulate a real-word scenario? These often can
create everything at once and often based on random numbers. Again, if you
have or build such code, it is not clear it needs to be written to disk and
then read back. You may of course want to save it, perhaps as a log, to show
what your program was working on. 



-Original Message-
From: Python-list  On
Behalf Of Michael F. Stemper
Sent: Monday, September 27, 2021 11:40 AM
To: python-list@python.org
Subject: Re: XML Considered Harmful

On 25/09/2021 16.39, Avi Gross wrote:
> Michael,
> 
> I don't care what you choose. Whatever works is fine for an internal use.

Maybe I should have taken the provoking article with a few more grains of
salt. At this point, I'm not seeing any issues that are applicable to my use
case.

> But is the data scheme you share representative of your actual
application?
> 
>>From what I see below, unless the number of "point" variables is not 
>>always
> exactly four, the application might be handled well by any format that 
> handles rectangular data, perhaps even CSV.
> 
> You show a I mean anything like a data.frame can contain data columns 
> like
> p1,p2,p3,p4 and a categorical one like IHRcurve_name.
> 
> Or do you have a need for more variability such as an undetermined 
> number of similar units in ways that might require more flexibility or 
> be more efficient done another way?

As far as the number of points per IHR curve, the only requirement is that
there must be at least two. It's hard to define a line segment with only
one. The mock data that I have so far has curves ranging from two to five
points. I didn't notice that the snippet that I posted had two curves with
the same number of breakpoints, which was misleading.

My former employer's systems had, IIRC, space for seven points per curve in
the database structures. Of all the sizing changes made over a long career,
I don't recall any customer ever requiring more than that. But, it's
cleanest to use python lists (with no inherent sizing limitations) to
represent the IHR (and incremental cost) curves.


> MOST of the discussion I am seeing here seems peripheral to getting 
> you what you need for your situation and may require a learning curve 
> to learn to use properly. Are you planning on worrying about how to 
> ship your data encrypted, for example? Any file format you use for 
> storage can presumably be encrypted and send and decrypted if that
matters.

This work is intended to look at the feasability of relaxing some
constraints normally required for the solution of Economic Dispatch.
So all of my data are hypothetical. Once I have stuff up and running, I'll
be making up data for lots of different generators.

Being retired, I don't have access to any proprietary information about any
specific generators, so all of the data is made up out of my head. I still
need a way to get it into my programs, of course.

> So, yes, from an abstract standpoint we can discuss the merits of 
> various approaches. If it matters that humans can deal with your data 
> in a file or that it be able to be imported into a program like EXCEL, 
> those are considerations. But if not, there are quite a few relatively 
> binary formats where your program can save a snapshot of the data into 
> a file and read it back in next time.

Not needed here. I'm strictly interested in getting the models of
(generic) generating fleets in. Output of significant results will probably
be in CSV, which nicely replicates tabular displays that I used through most
of my career.

> Or, did I miss something and others have already produced the dat

Re: Package conflicts trying to install jpegdupes package

[Chris Angelico]

On Tue, Sep 28, 2021 at 10:40 AM Skip Montanaro
 wrote:
>
> Woo hoo! It's installed. The ultimate error was a missing turbojpeg.h
> file. Thank goodness for the apt-file command. I was able to track
> that down to the libturbojpeg0-dev package, install that, and after a
> bit more fussing around now have jpegdupes installed.
>
> Thanks for the help,
>

Sweet! I like stories that have happy endings.

(No compilers were harmed in the making of this.)

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

Re: Package conflicts trying to install jpegdupes package

[Skip Montanaro]

Woo hoo! It's installed. The ultimate error was a missing turbojpeg.h
file. Thank goodness for the apt-file command. I was able to track
that down to the libturbojpeg0-dev package, install that, and after a
bit more fussing around now have jpegdupes installed.

Thanks for the help,

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

Re: Package conflicts trying to install jpegdupes package

[Chris Angelico]

On Tue, Sep 28, 2021 at 8:09 AM Skip Montanaro  wrote:
>>
>> For the most part, a proper colorizing compiler can make the
>> errors stand out among the spam of warnings, but it's hard when people
>> copy and paste just the text.
>
>
> In my defense, the entire traceback was red. :-) It's quite possible that GCC 
> colorized its error/warning messages, but colorizing might have been 
> suppressed by stderr being fed into a pipe, or by distutils tossing it out.
>

Ah, yeah, that's a nuisance. Honestly, most release systems should be
configured with fewer warnings, but maybe people don't distinguish
between dev and release.

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

Re: Package conflicts trying to install jpegdupes package

[Skip Montanaro]

>
> For the most part, a proper colorizing compiler can make the
> errors stand out among the spam of warnings, but it's hard when people
> copy and paste just the text.
>

In my defense, the entire traceback was red. :-) It's quite possible that
GCC colorized its error/warning messages, but colorizing might have been
suppressed by stderr being fed into a pipe, or by distutils tossing it out.

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

Re: Python added to PATH, cannot be directly accessed, cannot install pip

[Mats Wichmann]

On 9/27/21 08:00, Will wrote:

Hello team at python.org,



I've asked this question on a forum and tried to figure it out myself, but
I'm at a dead end. I don't know if you guys answer questions like this but
I have no where else to turn to.



I am using a Lenovo Laptop using Windows. I'm trying to install
get-pip.py, and when I enter "python get-pip.py" into the Command Prompt,
it says "Python was not found; run without arguments to install from the
Microsoft Store, or disable this shortcut from Settings > Manage App
Execution Aliases."



So for a week, I've been trying to add Python to PATH, so I can install
get-pip.py to Python.



I've added the exact file location for Python to Path in both User
Variables and System Variables. I've executed Manage App Execution
Aliases, turned off both App Installer python.exe and App Installer
python3.exe. Still can't install pip, Python was still not found. I've
tried different keywords ("py get-pip.py", python3 get-pip.py", etc.).
Still doesn't work.



Python is added to PATH and I can still run Python scripts, but I can't
find Python directly through the Command Prompt, and I cannot install
get-pip.py to Python.



For reference, I have Python version 3.9.6 and I installed Python directly
from the site (I did not use Anaconda).



Can you guys help me with this? Or do I need to delete Python and
reinstall it?


In addition to Eryk's comments...

Try invoking Python from a command prompt by typing "py" (I think you 
knew this).  For a python.org installation, as long as you didn't 
deselect the installation of the Python Launcher, that's the way to 
launch it.  Meanwhile, you can also install from the Microsoft Store - 
and the message you're getting is from the little stub that tries to be 
helpful about telling you this when you try as "python" - that's not 
Python itself that's running, it's the Windows helper.


pip, meanwhile, is not in the same directory as the python executable, 
so even "adding python to PATH" doesn't solve the problem of running 
pip.  Invoke it like this instead:


py -m pip install foo


you _can_ add the scripts subdirectory of the python install location to 
PATH as well, but it's better to get in the habit of running pip as a 
module, because it works way better once you have multiple pythons 
installed (which happens a lot).


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

Re: Package conflicts trying to install jpegdupes package

[Chris Angelico]

On Tue, Sep 28, 2021 at 4:46 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> I agree that the standard shouldn't regulate warnings.  I'm also saying
> that sometimes, it's a pain that it doesn't, and that not every warning
> is the package maintainer's fault.  :-)

Agreed. For the most part, a proper colorizing compiler can make the
errors stand out among the spam of warnings, but it's hard when people
copy and paste just the text. There's a skill to skimming compiler
output to find what's relevant (for instance, just before an error,
there might be a related warning, which actually is highlighting the
real problem).

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

Re: Package conflicts trying to install jpegdupes package

[2QdxY4RzWzUUiLuE]

On 2021-09-28 at 04:16:58 +1000,
Chris Angelico  wrote:

> On Tue, Sep 28, 2021 at 4:04 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
> >
> > On 2021-09-28 at 03:23:53 +1000,
> > Chris Angelico  wrote:
> >
> > > On Tue, Sep 28, 2021 at 3:11 AM Skip Montanaro  
> > > wrote:
> > > >>
> > > >> Those are all warnings. Are there any errors that follow them?
> > > >
> > > >
> > > > Maybe I just missed the actual errors, but the compiler exit status was 
> > > > 1, so there must have been. I'll give it another try.
> > >
> > > Yeah, one of the annoying things of building large C packages is when
> > > the maintainers don't care about warnings, and then legit errors get
> > > lost in the spam.
> >
> > It's also possible that the compiler is running in a "warnings are
> > errors" mode.  Hack the Makefile (or equivalent) at your own peril.
> >
> > One of the annoying things about warnings is that they're not standard,
> > so squelching them under one compiler makes another compiler (or a
> > different version of the same compiler) whine.  IIRC, a compliant C
> > compiler can issue a warning for anything it wants, including "this
> > variable name contains too many vowels" or "this is a computer, and
> > today may be Tuesday."
> >
> > In many ways, the engineering pieces of software engineering remain in
> > their infancy.  *sigh*
> 
> But that's kinda the point of having different compilers. Warnings
> that we consider fairly standard today didn't exist in the past, and
> someone had to be the first to add them. If the C language had to
> mandate every warning, it'd take forever to make changes.

That is indeed one benefit of having different compilers and compilers
that improve over time.  It's also a nuisance when the compiler in your
development/unit test environment produces different warnings than
either cross compiler for your target environments (plural).

In Python, it's more likely that MSVC, MinGW, LLVM, and gcc choose
different warnings, and that no collection of settings supresses them
all.  Present C projects contain oodles of conditional compilation,
often controlled by the preprocessor; achieving ideal results can be,
well, "tricky."  It's not a matter of not caring.

At some point, it comes down to a question of ignoring a warning vs.
cluttering up your code (preprocessor or otherwise) with extra
conditionals.  Or being stuck with a warning about unneeded defensive
programming vs. being stuck with a warning about possible arithmetic
overflow on your 32-bit target.

I agree that the standard shouldn't regulate warnings.  I'm also saying
that sometimes, it's a pain that it doesn't, and that not every warning
is the package maintainer's fault.  :-)

> I don't think that warnings-are-errors mode is a good thing though.
> They should remain just as warnings. (And with the most popular
> compilers, using the compilation options as specified in their own
> makefile, maintainers should ideally try to ensure that there are as
> few warnings as possible.)

Ideally, yes.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Package conflicts trying to install jpegdupes package

[Chris Angelico]

On Tue, Sep 28, 2021 at 4:04 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-09-28 at 03:23:53 +1000,
> Chris Angelico  wrote:
>
> > On Tue, Sep 28, 2021 at 3:11 AM Skip Montanaro  
> > wrote:
> > >>
> > >> Those are all warnings. Are there any errors that follow them?
> > >
> > >
> > > Maybe I just missed the actual errors, but the compiler exit status was 
> > > 1, so there must have been. I'll give it another try.
> >
> > Yeah, one of the annoying things of building large C packages is when
> > the maintainers don't care about warnings, and then legit errors get
> > lost in the spam.
>
> It's also possible that the compiler is running in a "warnings are
> errors" mode.  Hack the Makefile (or equivalent) at your own peril.
>
> One of the annoying things about warnings is that they're not standard,
> so squelching them under one compiler makes another compiler (or a
> different version of the same compiler) whine.  IIRC, a compliant C
> compiler can issue a warning for anything it wants, including "this
> variable name contains too many vowels" or "this is a computer, and
> today may be Tuesday."
>
> In many ways, the engineering pieces of software engineering remain in
> their infancy.  *sigh*

But that's kinda the point of having different compilers. Warnings
that we consider fairly standard today didn't exist in the past, and
someone had to be the first to add them. If the C language had to
mandate every warning, it'd take forever to make changes.

I don't think that warnings-are-errors mode is a good thing though.
They should remain just as warnings. (And with the most popular
compilers, using the compilation options as specified in their own
makefile, maintainers should ideally try to ensure that there are as
few warnings as possible.)

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

Re: Package conflicts trying to install jpegdupes package

[2QdxY4RzWzUUiLuE]

On 2021-09-28 at 03:23:53 +1000,
Chris Angelico  wrote:

> On Tue, Sep 28, 2021 at 3:11 AM Skip Montanaro  
> wrote:
> >>
> >> Those are all warnings. Are there any errors that follow them?
> >
> >
> > Maybe I just missed the actual errors, but the compiler exit status was 1, 
> > so there must have been. I'll give it another try.
> 
> Yeah, one of the annoying things of building large C packages is when
> the maintainers don't care about warnings, and then legit errors get
> lost in the spam.

It's also possible that the compiler is running in a "warnings are
errors" mode.  Hack the Makefile (or equivalent) at your own peril.

One of the annoying things about warnings is that they're not standard,
so squelching them under one compiler makes another compiler (or a
different version of the same compiler) whine.  IIRC, a compliant C
compiler can issue a warning for anything it wants, including "this
variable name contains too many vowels" or "this is a computer, and
today may be Tuesday."

In many ways, the engineering pieces of software engineering remain in
their infancy.  *sigh*
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Posts from gmane no longer allowed?

[Grant Edwards]

On 2021-09-27, 황병희  wrote:
> Grant Edwards  writes:
>
>> I've been reading (and posting to) this list for many years by
>> pointing an NNTP client
>> at news://gmane.comp.python.general. Sometime in the past few days posts 
>> started
>> being refused:
>>
>> You have tried posting to gmane.comp.python.general, which is a
>> unidirectional
>> mailing list. Gmane can therefore not send this message to that
>> mailing list.
>>
>> Was this a change made by the mailing list admins?
>>
>> If so, is it permanent?
>>
>> [Trying to send a plaintext e-mail via Gmail, but not sure if it's working.]
>
> Oh this is unhappy news. Because i also using Gmane with
> gmane.emacs.help and gmane.linux.debian.user.

Posting to other lists in gmane still works fine for me. It's only the
python list that turned into read-only.

> Only i use Usenet (eternal september) with comp.lang.python.

I've switched back and forth between Usenet and gmane a couple times
trying to figure out which one had the least breakage in references:
headers. I acually wrote a Python program that acted as an NNTP client
and counted thread breakage. The last time I ran that test gmane had a
slight advantage in thread integrity and fewer posters in need of
plonking.

--
Grant

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

Re: Package conflicts trying to install jpegdupes package

[Dieter Maurer]

Skip Montanaro wrote at 2021-9-27 07:48 -0500:
>I'd like to use the jpegdupes package  but
>can't seem to get past compilation issued related to jpegtrans-cffi.
>Attempts to install any available versions on my XUbuntu system crap out
>with this C compiler error message:
>
> In file included from
>jpegtran/__pycache__/_cffi__xd2d84bdexcdb1023.c:267:
>src/epeg_private.h:71:17: warning: ‘_jpeg_init_source’ declared
>‘static’ but never defined [-Wunused-function]
>   71 | METHODDEF(void) _jpeg_init_source(j_decompress_ptr cinfo);
>  | ^
> ...

You list only warnings (which usually can be ignored).
If the compilation fails, you should see error messages, too.

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

Re: Package conflicts trying to install jpegdupes package

[Chris Angelico]

On Tue, Sep 28, 2021 at 3:11 AM Skip Montanaro  wrote:
>>
>> Those are all warnings. Are there any errors that follow them?
>
>
> Maybe I just missed the actual errors, but the compiler exit status was 1, so 
> there must have been. I'll give it another try.

Yeah, one of the annoying things of building large C packages is when
the maintainers don't care about warnings, and then legit errors get
lost in the spam.

>> The package doesn't seem to have had a release since 2018, but the
>> GitHub repository has had changes as recently as a month ago. You
>> might have better luck cloning the repo and building that.
>
>
> Thanks, good suggestion.
>
> FWIW, I'm trying to whittle down at least 12,000 images to a more manageable 
> number for the sister of a good friend who recently passed away. I've got a 
> straightforward dedupe program, but need something which can compare just the 
> data chunk of JPEGs, ignoring the metadata. This program apparently does 
> that. Is like to avoid reinventing that wheel.
>

Makes sense! Though if you're just doing a bitwise comparison of the
data chunks, it shouldn't be TOO hard to reinvent. JFIF is a
reasonably easy format to understand (although the mathematics of
image encoding and decoding are a bit less so).

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

Re: Package conflicts trying to install jpegdupes package

[Skip Montanaro]

>
> Those are all warnings. Are there any errors that follow them?
>

Maybe I just missed the actual errors, but the compiler exit status was 1,
so there must have been. I'll give it another try.


The package doesn't seem to have had a release since 2018, but the
> GitHub repository has had changes as recently as a month ago. You
> might have better luck cloning the repo and building that.
>

Thanks, good suggestion.

FWIW, I'm trying to whittle down at least 12,000 images to a more
manageable number for the sister of a good friend who recently passed away.
I've got a straightforward dedupe program, but need something which can
compare just the data chunk of JPEGs, ignoring the metadata. This program
apparently does that. Is like to avoid reinventing that wheel.

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

Re: Python added to PATH, cannot be directly accessed, cannot install pip

[Eryk Sun]

On 9/27/21, Will  wrote:
>
>I am using a Lenovo Laptop using Windows. I'm trying to install
>get-pip.py

The installer includes pip by default and has an option to update PATH
for you, though the latter isn't enabled by default.

Latest 64-bit release:
https://www.python.org/ftp/python/3.9.7/python-3.9.7-amd64.exe
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Chris Angelico]

On Tue, Sep 28, 2021 at 2:30 AM Michael F. Stemper
 wrote:
> As far as power is concerned, this is utility-level generating fleets,
> so it's always going to be MW -- even in the US, where we still use
> BTUs for heat.
>

It's easy for *you* to know, and therefore assume, that it's always
MW. But someone else coming along will appreciate some sort of
indication that it's MW and not (say) KW or GW.

I've spent a long time decoding other people's file formats, trying to
figure out what unit something is in. "Huh. The date seems to be
stored in hours?!?"

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

Re: Package conflicts trying to install jpegdupes package

[Chris Angelico]

On Mon, Sep 27, 2021 at 10:49 PM Skip Montanaro
 wrote:
>
> I'd like to use the jpegdupes package  
> but
> can't seem to get past compilation issued related to jpegtrans-cffi.
> Attempts to install any available versions on my XUbuntu system crap out
> with this C compiler error message:
>
>  In file included from
> jpegtran/__pycache__/_cffi__xd2d84bdexcdb1023.c:267:
> src/epeg_private.h:71:17: warning: ‘_jpeg_init_source’ declared
> ‘static’ but never defined [-Wunused-function]
>71 | METHODDEF(void) _jpeg_init_source(j_decompress_ptr cinfo);
>   | ^
> src/epeg_private.h:72:20: warning: ‘_jpeg_fill_input_buffer’ declared
> ‘static’ but never defined [-Wunused-function]
>72 | METHODDEF(boolean) _jpeg_fill_input_buffer(j_decompress_ptr
> cinfo);
>   |^~~
> src/epeg_private.h:73:17: warning: ‘_jpeg_skip_input_data’ declared
> ‘static’ but never defined [-Wunused-function]
>73 | METHODDEF(void) _jpeg_skip_input_data(j_decompress_ptr cinfo,
> long num_bytes);
>   | ^
> src/epeg_private.h:74:17: warning: ‘_jpeg_term_source’ declared
> ‘static’ but never defined [-Wunused-function]
>74 | METHODDEF(void) _jpeg_term_source(j_decompress_ptr cinfo);
>   | ^
> src/epeg_private.h:76:17: warning: ‘_jpeg_init_destination’ declared
> ‘static’ but never defined [-Wunused-function]
>76 | METHODDEF(void) _jpeg_init_destination(j_compress_ptr cinfo);
>   | ^~
> src/epeg_private.h:77:20: warning: ‘_jpeg_empty_output_buffer’ declared
> ‘static’ but never defined [-Wunused-function]
>77 | METHODDEF(boolean) _jpeg_empty_output_buffer (j_compress_ptr
> cinfo);
>   |^
> src/epeg_private.h:78:17: warning: ‘_jpeg_term_destination’ declared
> ‘static’ but never defined [-Wunused-function]
>78 | METHODDEF(void) _jpeg_term_destination (j_compress_ptr cinfo);
>   | ^~

Those are all warnings. Are there any errors that follow them?

> ...
> This seems like a rather odd error message for a presumably sort-of-stable
> PyPI package. Looking at the version dependencies I see 2.6, 2.7, 3.3 or
> PyPy. I thought nmybe I needed to try with Python2... Create a Conda
> environment, attempt to install jpegdupes, only to discover it's Python 3
> only.
>
> So, I'm kind of stuck. Maybe I need to install Python 3.3 and try that? Any
> other ideas?
>

The package doesn't seem to have had a release since 2018, but the
GitHub repository has had changes as recently as a month ago. You
might have better luck cloning the repo and building that.

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

Re: XML Considered Harmful

[Michael F. Stemper]

On 25/09/2021 16.48, 2qdxy4rzwzuui...@potatochowder.com wrote:

On 2021-09-25 at 15:20:19 -0500,
"Michael F. Stemper"  wrote:


... For instance, if
I modeled a fuel like this:

   
 ton
 21.96
 18.2
   

and a generating unit like this:

   
 
   
   
   
   
 
 
   
   
   
   
 
   

why would the fact that I could have chosen, instead, to model
the unit of measure as an attribute of the fuel, or its name
as a sub-element matter? Once the modeling decision has been
made, all of the decisions that might have been would seem to
be irrelevant.


Disclaimer:  I am not a big XML fan, for a number of reasons
already stated in this thread.

That said, please do include units in elements like heat_content,
whether or not it's Joules/kilogram/K, and price, even if is the
local currency in the only country to which your data applies.


Since the units (dimensions) don't matter as long as they're consistent
between heat_content and the IHR value (MBTU and MBTU/MWh or GJ and
GJ/MWh), I was initially going to ignore this suggestion. However, it
seems that if I added attributes for the unit of measure of heat, that
would allow checking that the data provided are indeed consistent.

Thanks for the suggestion.

With respect to currency, I've had customers (back when I had to work
for a living) use dollars, pesetas, Euros, and pounds. In of Wood and
Wollenberg[1], the authors use \cancel{R} to represent a generic
currency. But I might even add a currency attribute to the price
element.


If there's a standard for your industry, or your company, or on
some other level, then at least document what it is and that
you're using it, so that the next person (which may be you a
year from now) doesn't have to guess.


As far as power is concerned, this is utility-level generating fleets,
so it's always going to be MW -- even in the US, where we still use
BTUs for heat.



[1] _Power Generation, Operation, and Control; Allen J. Wood and Bruce
F. Wollenberg; (c) 1984, John Wiley & Sons.
--
Michael F. Stemper
The FAQ for rec.arts.sf.written is at

Please read it before posting.
--
https://mail.python.org/mailman/listinfo/python-list

Re: XML Considered Harmful

[Michael F. Stemper]

On 25/09/2021 16.39, Avi Gross wrote:

Michael,

I don't care what you choose. Whatever works is fine for an internal use.


Maybe I should have taken the provoking article with a few more grains
of salt. At this point, I'm not seeing any issues that are applicable to
my use case.


But is the data scheme you share representative of your actual application?


From what I see below, unless the number of "point" variables is not always

exactly four, the application might be handled well by any format that
handles rectangular data, perhaps even CSV.

You show a I mean anything like a data.frame can contain data columns like
p1,p2,p3,p4 and a categorical one like IHRcurve_name.

Or do you have a need for more variability such as an undetermined number of
similar units in ways that might require more flexibility or be more
efficient done another way?


As far as the number of points per IHR curve, the only requirement
is that there must be at least two. It's hard to define a line segment
with only one. The mock data that I have so far has curves ranging
from two to five points. I didn't notice that the snippet that I
posted had two curves with the same number of breakpoints, which was
misleading.

My former employer's systems had, IIRC, space for seven points per curve
in the database structures. Of all the sizing changes made over a long
career, I don't recall any customer ever requiring more than that. But,
it's cleanest to use python lists (with no inherent sizing limitations)
to represent the IHR (and incremental cost) curves.



MOST of the discussion I am seeing here seems peripheral to getting you what
you need for your situation and may require a learning curve to learn to use
properly. Are you planning on worrying about how to ship your data
encrypted, for example? Any file format you use for storage can presumably
be encrypted and send and decrypted if that matters.


This work is intended to look at the feasability of relaxing some
constraints normally required for the solution of Economic Dispatch.
So all of my data are hypothetical. Once I have stuff up and running,
I'll be making up data for lots of different generators.

Being retired, I don't have access to any proprietary information
about any specific generators, so all of the data is made up out
of my head. I still need a way to get it into my programs, of course.


So, yes, from an abstract standpoint we can discuss the merits of various
approaches. If it matters that humans can deal with your data in a file or
that it be able to be imported into a program like EXCEL, those are
considerations. But if not, there are quite a few relatively binary formats
where your program can save a snapshot of the data into a file and read it
back in next time.


Not needed here. I'm strictly interested in getting the models of
(generic) generating fleets in. Output of significant results will
probably be in CSV, which nicely replicates tabular displays that
I used through most of my career.


Or, did I miss something and others have already produced the data using
other tools, in which case you have to read it in at least once/


Well, the "tool" is vi, but this is a good description of what I'm
doing.

--
Michael F. Stemper
The FAQ for rec.arts.sf.written is at

Please read it before posting.
--
https://mail.python.org/mailman/listinfo/python-list

Re: count consecutive elements

[Bischoop]

I'd wish to have this challenge posted on my blog but because I suck in
IT english, could you guys help me with decribing the task of what the
code supposed to do? 

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

Re: Posts from gmane no longer allowed?

[황병희]

Grant Edwards  writes:

> I've been reading (and posting to) this list for many years by
> pointing an NNTP client
> at news://gmane.comp.python.general. Sometime in the past few days posts 
> started
> being refused:
>
> You have tried posting to gmane.comp.python.general, which is a
> unidirectional
> mailing list. Gmane can therefore not send this message to that
> mailing list.
>
> Was this a change made by the mailing list admins?
>
> If so, is it permanent?
>
> [Trying to send a plaintext e-mail via Gmail, but not sure if it's working.]

Oh this is unhappy news. Because i also using Gmane with
gmane.emacs.help and gmane.linux.debian.user. Only i use Usenet (eternal
september) with comp.lang.python.

Sincerely, Byung-Hee
-- 
https://mail.python.org/mailman/listinfo/python-list

Python added to PATH, cannot be directly accessed, cannot install pip

[Will]

   Hello team at python.org,



   I've asked this question on a forum and tried to figure it out myself, but
   I'm at a dead end. I don't know if you guys answer questions like this but
   I have no where else to turn to.



   I am using a Lenovo Laptop using Windows. I'm trying to install
   get-pip.py, and when I enter "python get-pip.py" into the Command Prompt,
   it says "Python was not found; run without arguments to install from the
   Microsoft Store, or disable this shortcut from Settings > Manage App
   Execution Aliases."



   So for a week, I've been trying to add Python to PATH, so I can install
   get-pip.py to Python.



   I've added the exact file location for Python to Path in both User
   Variables and System Variables. I've executed Manage App Execution
   Aliases, turned off both App Installer python.exe and App Installer
   python3.exe. Still can't install pip, Python was still not found. I've
   tried different keywords ("py get-pip.py", python3 get-pip.py", etc.).
   Still doesn't work.



   Python is added to PATH and I can still run Python scripts, but I can't
   find Python directly through the Command Prompt, and I cannot install
   get-pip.py to Python.



   For reference, I have Python version 3.9.6 and I installed Python directly
   from the site (I did not use Anaconda).



   Can you guys help me with this? Or do I need to delete Python and
   reinstall it?



   Sincerely, Will






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

EuroPython 2021: Edited videos of the first day available

[Marc-Andre Lemburg]

We’re happy to release the first 42 cut videos of EuroPython 2021
covering the first day sessions of the conference. You can watch them on
our YouTube channel:

 * EuroPython 2021 Playlist *

https://www.youtube.com/playlist?list=PL8uoeex94UhHgMD9GOCbEHWku7pEPx9fW

Over the next few weeks, we’ll continue releasing the videos for the
second and third day of the conference. In total, we will have more than
115 videos with lots of valuable and interesting content for you, so
please stop by and check the playlist for more videos, or subscribe to
our YouTube channel.

http://europython.tv/


Help spread the word


Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !

Link to the blog post:

https://blog.europython.eu/europython-2021-edited-videos-of-the-first-day-available/

Tweet:

https://twitter.com/europython/status/1442493825491025924

Enjoy,
--
EuroPython 2021 Team
https://ep2021.europython.eu/
https://www.europython-society.org/

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

Re: Posts from gmane no longer allowed?

[Grant Edwards]

On 2021-09-27, Ned Deily  wrote:

> I have been in touch with the administrator of gmane. It appears that 
> posting from python-list to gmane has been deliberately disabled, at 
> least temporarily, with cause. I'll see if we can resolve the problem.

Thanks. Though I've figured out a solution that allows me to read the
list via gmane using slrn and post "directly" via e-mail, I'm sure
other gmane users will appreciate that.

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

Package conflicts trying to install jpegdupes package

[Skip Montanaro]

I'd like to use the jpegdupes package  but
can't seem to get past compilation issued related to jpegtrans-cffi.
Attempts to install any available versions on my XUbuntu system crap out
with this C compiler error message:

 In file included from
jpegtran/__pycache__/_cffi__xd2d84bdexcdb1023.c:267:
src/epeg_private.h:71:17: warning: ‘_jpeg_init_source’ declared
‘static’ but never defined [-Wunused-function]
   71 | METHODDEF(void) _jpeg_init_source(j_decompress_ptr cinfo);
  | ^
src/epeg_private.h:72:20: warning: ‘_jpeg_fill_input_buffer’ declared
‘static’ but never defined [-Wunused-function]
   72 | METHODDEF(boolean) _jpeg_fill_input_buffer(j_decompress_ptr
cinfo);
  |^~~
src/epeg_private.h:73:17: warning: ‘_jpeg_skip_input_data’ declared
‘static’ but never defined [-Wunused-function]
   73 | METHODDEF(void) _jpeg_skip_input_data(j_decompress_ptr cinfo,
long num_bytes);
  | ^
src/epeg_private.h:74:17: warning: ‘_jpeg_term_source’ declared
‘static’ but never defined [-Wunused-function]
   74 | METHODDEF(void) _jpeg_term_source(j_decompress_ptr cinfo);
  | ^
src/epeg_private.h:76:17: warning: ‘_jpeg_init_destination’ declared
‘static’ but never defined [-Wunused-function]
   76 | METHODDEF(void) _jpeg_init_destination(j_compress_ptr cinfo);
  | ^~
src/epeg_private.h:77:20: warning: ‘_jpeg_empty_output_buffer’ declared
‘static’ but never defined [-Wunused-function]
   77 | METHODDEF(boolean) _jpeg_empty_output_buffer (j_compress_ptr
cinfo);
  |^
src/epeg_private.h:78:17: warning: ‘_jpeg_term_destination’ declared
‘static’ but never defined [-Wunused-function]
   78 | METHODDEF(void) _jpeg_term_destination (j_compress_ptr cinfo);
  | ^~

...
This seems like a rather odd error message for a presumably sort-of-stable
PyPI package. Looking at the version dependencies I see 2.6, 2.7, 3.3 or
PyPy. I thought nmybe I needed to try with Python2... Create a Conda
environment, attempt to install jpegdupes, only to discover it's Python 3
only.

So, I'm kind of stuck. Maybe I need to install Python 3.3 and try that? Any
other ideas?

Thx,

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

Re: c extension finding the module in object initialization

[Robin Becker]

Hi Marc,

Thanks for the suggestion,


On 27/09/2021 09:38, Marc-Andre Lemburg wrote:

Hi Robin,

seeing that no one replied to your question, I'd suggest to ask this
on the Python C-API ML:

https://mail.python.org/mailman3/lists/capi-sig.python.org/

That's where the experts are, including the ones who implemented
the mutli-phase logic.

Cheers,



I think I have this working using ob=PyImport_GetModuleDict() followed by PyDict_GetItemString(ob,"modulename"), but I 
will ask there to see if there's a more direct route.


In Python >=3.7 there's PyImport_GetModule, but that seems more complex than is actually required for this simple case 
and has to wait until 3.6 dies for me :(

--
Robin Becker



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

Re: c extension finding the module in object initialization

[Marc-Andre Lemburg]

Hi Robin,

seeing that no one replied to your question, I'd suggest to ask this
on the Python C-API ML:

https://mail.python.org/mailman3/lists/capi-sig.python.org/

That's where the experts are, including the ones who implemented
the mutli-phase logic.

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Sep 27 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.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
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/


On 21.09.2021 14:08, Robin Becker wrote:
> I have a c extension which is intended to implement a module the looks
> structurally like this
> 
> 
> 
> a = 1
> b = 2
> 
> class T:
>     def __init__(self):
>     self.a = a
>     self.b = b
> 
> 
> so when an object of type T is instantiated it can set up defaults based on 
> the
> current module values of a and b.
> 
> In the past using old style single phase module creation the init function for
> the type could look up the module by using the PyState_FindModule function. In
> the new world where we can implement c extensions which might work with 
> multiple
> interpreters (multi-phase creation). The docs say PyState_FindModule won't 
> work
> for those and indeed it returns NULL so is useless.
> 
> Is there a way I can set the current module onto the type definition during 
> the
> module's exec function? I thought it would be easy to add at the point in the
> exec where I'm doing this to the module, m,
> 
> TType.tp_base = &PyBaseObject_Type;
> if(PyType_Ready(&TType)<0) goto fail;
> if(PyModule_AddObject(m,"T", (PyObject *)&TType)<0) goto fail;
> 
> but I don't see the place in the type where I can add these sorts of dynamic
> attributes. The basic_size is for the created objects.
> 
> The created type does have a __dict__ which is a mappingproxy. I wondered when
> that actually gets instantiated.
> 
> I can see that the type has a __module__ attribute after the module is 
> imported
> and I suppose if I can find the 'current' interpreter I might use the 
> __module__
> to locate the module object via PyImport_GetModuleDict.
> 
> Any expertise or advice gratefully received.
> -- 
> Robin Becker
> 

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

Re: EuroPython Society: General Assembly 2021

[Abdur-Rahmaan Janhangeer]

Greetings Damien,

The mailing list is public and i would have a hard time dealing with 1000s
of people
replying:

`stop mailing me`, maybe a private message to mal would have sufficed.

Kind Regards,

Abdur-Rahmaan Janhangeer
about  | blog

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